540 Words. Plan about 3 minute(s) to read this.
So I ran into a task about which I didn’t have a clue. The task was to take 2 workstations in 2 different VLANs on 2 trunked 3550 switches, and make it so that the 2 workstations can communicate with a non-routed, non-IP protocol – NetBIOS in this case. Since I didn’t have a clue, I discovered in the answer-key a feature I don’t think I’d heard of before: fallback bridging.
In a nutshell, fallback bridging puts multiple layer 3 interfaces (either SVIs or routed ports) into a bridge-group, thus making those layer 3 interfaces a part of a common layer 2 domain. Existing VLANs keep their own spanning-tree instances, and the new bridge-group gets its own spanning-tree instance to prevent topology loops. Routed traffic is routed like normal – same as it ever was. Adding the bridge-group doesn’t change the IP forwarding behavior you’d expect. But traffic that is not routed can “fallback” to the bridge-group to get forwarded.
From the fallback bridging cisco.com page:
“An interface (an SVI or routed port) can be a member of only one bridge group.
A maximum of 31 bridge groups can be configured on the switch.
Use a bridge group for each separately bridged (topologically distinct) network connected to the switch.
All protocols except IP (Version 4 and Version 6), Address Resolution Protocol (ARP), reverse ARP (RARP), LOOPBACK, and Frame Relay ARP are fallback bridged.”
All I can think to say in response to this feature is, “Hey, the early 90’s called. They want their LAN back.” Ugh. I guess I should be thankful ISDN isn’t on the lab anymore.
I also ran into a security feature for DHCP called DHCP authorized ARP. The idea is for the DHCP server to track MAC addresses as they are paired with IP addresses through the IOS DHCP server. The IOS DHCP server will then, once a minute, ARP for the IPs he’s leased out, and make sure the same MAC responds (the “update arp” DHCP pool command). This is intended to make it harder for a naughty wireless hacker-type to use an IP address that was leased to someone else in the hotspot.
In effect, the IOS DHCP server will know when the user logged off. Using this feature in conjunction with disabling dynamic ARP learning (ergo, limiting router ARP cache to only that which is in the DHCP database) on appropriate router interfaces, and you’ve got a fairly tight anti-spoofing tool. You did catch “appropriate router interfaces”, right? In other words, you configure “arp authorized” on a per-interface basis…it’s not a global command.
There’s a big catch with this scenario, if you haven’t spotted it already. The router isn’t going to learn the MAC address of anything that isn’t in the DHCP database, on the interface where you cranked up “arp authorized” right? That means if the router needs to talk to something on that segment that isn’t a DHCP client (say, another router you need to unicast to), the router will need a static ARP entry to find that device.
I still have more scenario 1 to go, what with the teething issues present in the rack hardware. Hopefully, the last hurdle will be behind me tomorrow when I load up the new IOS on the 3745s so that I get IPv6.
about | subscribe | @ecbanks