YLearn

@PenguinCoder, to rule out any sort of spanning tree issues, the next output I would like to see is the output from sh spanning-tree interface g 1/0/1 as well as Gi1/0/20 from the MDF. Also sh spanning-tree vlan 200 from both switches may be nice.

@PenguinCoder, since you mention the DHCP server is on a different VLAN, does your VLAN 200 L3 interface (i.e. the gateway) have a DHCP helper/relay properly configured?

@MarkMessa I don't want to avoid using frames, I'm just considering to avoid using the MAC header. That is why your request is confusing. You don't seem to understand that without the L2 headers they are no longer Ethernet or 802.11 frames. You would need to write your own L2 protocol to work without the L2 headers present in 802.3 or 802.11.

@MarkMessa, see that is where you lose me. You reference a couple of resources about using "Raw Ethernet" and then out of no where you start asking about not using the MAC headers and I have no idea where you are pulling that "concept" from as the "Raw Ethernet" examples are using the MAC headers. No, without the headers, Ethernet is not Ethernet nor is 802.11 802.11. Would it be possible if you wrote your own L1/L2 protocol? Sure, anything is possible. But asking about using "Raw Ethernet" without the MAC headers just doesn't make any sense.

@MarkMessa, in general I believe so, although 802.11 frames do not make use of padding (padding is only necessary in 802.3 if the payload is too small to allow the frame to reach the minimum size of 64 bytes) and the "mac header" sections are very different.

@MarkMessa, no I don't. For instance, 802.11 frames can have up to four addresses in their headers (see my answer here for more details) and contain other information as well. They are two entirely different frame formats that happen to have some similarities.

@MarkMessa, regarding your first comment, despite Ethernet devices being "smarter," Ethernet still operates as Ethernet. 802.3 never has nor never will require the use of IP. For example, while rare, Ethernet today will still support Appletalk or IPX/SPX just as happily as ever, or without any higher layer protocol at all (many things still use just L2 for communication). As for your second comment, I am not sure what you mean by "is it possible to send/receive such frames." You can't send 802.3 frames over 802.11, but there are 802.11 only communications not involving IP.

Non-IP traffic over Ethernet has been a part of networking for decades so I am not really clear on what you are really trying to get answered and maybe you need to learn a bit more about the basics of networking. There is no such thing as a "Ethernet Wireless card" as 802.3 Ethernet and 802.11 wireless are two entirely different standards. As such, your frame format in the 2nd issue wouldn't apply at all to an 802.11 network, but frames have certain requirements according to the standards which is why many of the components of the frame you list are not configurable.

Can't even count the number of times someone using a microwave within a quarter mile has caused Wi-Fi issues. My favorite was the microwave that bled out enough signal to wipe out the Wi-Fi in half a commercial building when simply plugged into a power source.

Must be wireless only broadband in that village. But I laughed at this, "Earlier this year, UK telecoms regulator Ofcom warned that microwaves could reduce Wi-Fi signals." Thank you for figuring out earlier this year something that we network engineers that largely deal in wireless have known for well over a decade.

As Ron says, rack rentals are a good place to get some hands on experience. You can also use network emulation software to simulate networks to some degree. Depending on the software, these can be limited to the learning environment to nearly fully fledged emulated devices.

Second, if you can justify your need you can get put on a waiting list. Those on the waiting list will get IPs as they become available (typically if an assignment is returned to the RIR or if the RIR revokes an organizations rights to an IP space assignment - often for non-payment) on a first come first served basis.

@aderchox @RonMaupin - just to clarify, you can still get IPv4 addresses from the RIRs, under two conditions. First, if you meet one of the "special needs" that still allow for IPv4 assignment.

But that is a lot more involved and will add to your maintenance overhead for the environment. Additionally, it has to be documented well for future reference and changes (and staff changes, etc).

Depending on the platform, you may be able to use something like EEM to run a script to add/remove the static entry when needed. Never done it myself, but seems like something you could get to work.

@JukEboX as I stated earlier, you can only add a static entry for a MAC if it isn't already in the port-sec address table (do show port-security address to see it). Adding a static entry adds the MAC to the table, so you can't add a second static entry for the same MAC.

You can only add a static entry for a MAC if it isn’t already in the port-sec address table.

Thank god for the Internet. It allows all sorts of "truth" to come to light...as much as I live and breath it, some days I wish it had never been invented and then some forms of lunacy would be limited in their scope to the region they originated.

Getting your own NTP appliances is pretty cheap to actually do. Ppl

NTP off our own GPS based timing sources. All devices and servers use these sources.

@JukEboX, ditto. We don't do any sort of consent/proxy on our routers; the use of CPU cycles on the router isn't justifiable in most cases. This is normally handled through a guest solution or other type of registration system (ISE, Clearpass, PacketFence, etc as examples).

@Infra, do you have the IP address (documented, DHCP or default address perhaps)? can you ping it (if so, have you verified the MAC in ARP looks to be a Cisco MAC)? Interact with the switch in any way? Do you get CDP/LLDP from it (either neighboring device or by connecting to it to capture traffic yourself)? We really need to know what you mean by "not able to access it" to be able to help.

Even if you don't take the tests, the study materials available for the tests are solid starting points.

If you are looking for wireless, then CWNA.

Network+ is okay as well. More vendor neutral.

@SamIbraheem, I always recommend the CCNA for those new to networking. Gives a nice basic foundation.

Generally speaking, something has to change somewhere...whether that is config, IPs, equipment, etc.

Never had to merge companies where I wasn't allowed to make any changes or add/replace any hardware.

@Infra, not sure I have one at this point. No adding or replacing equipment, no changes allowed, no mention of network devices other than an unmanaged switch and a SP provided gateway, and I don't know anything more about the situation (single shared space, two spaces, etc)....not much to go on here or work with.

Yup. Heard that reasoning too. But in my mind while whatever protocol it may turn out to be, it will have to co-exist with IP for some time and may even be called/referred to as "IP something or other." But whatever it may be called, regulation that says you need to provide IPv6 doesn't automatically become negated when IPv6 is obsolete unless it explicitly says so (and many tech based regulations in my experience do not plan that far out).

@RonMaupin, I am a bit torn by things like this....while I applaud that IPv6 is getting pushed, government regulation for tech hasn't always had the best track record. For instance, now that this is a law, will it get updated when IPvX comes around or will ISPs still be required to support IPv6?

@RonTrunk - took longer than I expected to find time, but I did finally get that meta post up.

So you should see that soon (probably today or tomorrow if I can squeak it in) with more to follow. Specifically, there were three topics in particular from that discussion that seemed to have fairly wide community approval.

@RonTrunk, funny you should say that....in the past couple of weeks I submitted a draft of the first discussion to the other moderators based on the on/off topic discussion I started about 6 months ago. The last "looks good" was sent last week, but I have personally been a bit tied up.

@mallea, you could also consider RADIUS one such application. Natively it uses UDP, but many implementations have also implemented RadSec, which does RADIUS exchanges over TCP (using TLS).

Almost 8 dozen sites with over 1k+ votes. Even my interests aren't that wide ranging....

I have to say, looking at that list it does appear to be rather suspicious. I know I am not a heavy voter, but to have 10k+ votes (not reputation) on five sites and 5k+ on over a dozen more (not to mention the sheer volume of sites the account voted on) seems a little implausible for legitimate voting.

@NoviceProgrammer Additionally, if they are separated by a L3 device, then even if they use the same VLAN ID/name, they are two different L2 domains.

If they are separated by a L3 device, then you likely cannot do so. You cannot have overlapping L3 address space on the same network.

@serverAdmin123 the 'sh version' does show the IOS version. Most likely it is some version of IOS-XE.

@RonMaupin, Just like Ron T., I don't have the rep to vote down. But I did upvote yours, comment on the "dissenting" answer and threw my own hat in the ring.

On some platforms, when you create an SVI or assign a port to a VLAN, it will also automatically create the VLAN. On others you will have to also create the VLAN.

@JukEboX, a VLAN is a logical division of a LAN into multiple LANs. An SVI is a virtual interface to provide a L3 interface on a configured VLAN.

Each VRF will have it's own mac address table, routing table, etc. Which is why as Ron pointed out, you need to specify the VRF for many commands so the physical device provides you the right information or uses the right resources.

Traffic from one VRF will not get shared with other VRFs unless you provide a connection to do so. We have some devices with multiple VRFs that certainly do have cables connecting right back to the same physical device (on a separate VRF).

You can also assign any and all ports to different VRFs. Think of VRFs as the logical division of devices in the same way that VLANs are logical divisions of the network.

@JukEboX, the other reason for OOBM is security. You can set a device up to only allow access the the management VRF. So there would be no access through the "normal" network.

@JesseP., if it is all part of your answer already, then please clean up your comments.

@Warren, please make sure to edit your question to include all the relevant details from the comments and delete those that are no longer necessary.

With the somewhat rare exception of running into a bug. But often you can determine that if you know how they operate enough to spot when they actually aren't operating as they should.