Hi Chuck, > Anyone have suggestions on Ethernet LAN loop-prevention? With the
In general, I avoid the potential for layer2 loops to any user-accesible layer2 ports in a manner that many edge network and broadband providers may find familiar -- vlan per user, tail, port, etc. -- aggregated in a hierarchical manner within the building, metro area, or city. This simple and logical layer2 isolation (real isolation, none of this pvlan-edge stuff) basically solves many problems by simply avoiding the preconditions necessary for loops/etc to pose a problem to the agg/border/etc of a network. Don't worry about users' being entire walled-off from each other -- unicast IP reachability is not broken with this model. Currently, the IOS implementation of unnumbered vlans/subints provides proxy-arp responses for all in-prefix (as defined by loopback/interface pointer-membership) addresses that your end-users may issue who-has's for. This is analogous to docsis and rfc1483 half-bridge as often used on xDSL network edges -- layer3's not broken, but layer2 is nicely walled off per-user. Perhaps you could think of this as dedicated layer2 resources per customer edge (CE), rather, "complaining entity." More here: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtunvlan.html I use this feature on 3550/3560/3750, sup2/sup720 on 6500; several colleagues have verified this works on 4900m an 4500's in 12.2SG trains. Of course, terminating lower-speed subints or QinQ tag'd vlan bundles works on higher-end ports (sip/spa), as well as all cpu-based boxes... 7200/7301 will consume QinQ ip subints for breakfast, and even give populate option 82 info in DHCP transactions auto-magically, if given the chance (by using helder-addrs on subints). The user-facing port config is usually some per-site variation of this following flavor, configured expecting users to land at 10/fdx or hdx: interface FastEthernet0/1 description Unit 201 load-interval 30 speed 10 port security max-mac-count 10 port security aging time 5 port storm-control broadcast action shutdown port storm-control broadcast threshold rising 100 falling 50 port storm-control multicast action shutdown port storm-control multicast threshold rising 100 falling 50 port storm-control unicast action filter port storm-control unicast threshold rising 3000 falling 1000 switchport access vlan 201 spanning-tree portfast spanning-tree bpdufilter enable ...Errdisable autorecover (or having the user call the support desk) are some of the ways out of the down/down access port penalty box; mix and combine these elements to taste. If terminating fast or gig-e, scale things accordingly. After the access ports are setup and trunking per-port layer2 frames up to the l3 edge (could be 3550, 650x, mwr-1941, etc), we have pages of things like: [...] interface FastEthernet0/1.112 encapsulation dot1Q 112 ip unnumbered Loopback0 ! interface FastEthernet0/1.113 encapsulation dot1Q 113 ip unnumbered Loopback0 ! interface FastEthernet0/1.114 encapsulation dot1Q 114 ip unnumbered Loopback0 [...] In my mdu and mtu layer2 edge sites, this approach has saved our posteriors from real problems--year in, year out. A few words on this config: in what you see above, a user simply cannot introduce enough traffic to the network (unicast) to matter (i.e. perhaps they create an unknown unicast dest flood..), and will be shut down if they spew enough bcast/mcast frames (thresholds set appropriate given your expected end-user profiles). Further, only the first 10 mac addresses can ride this bus (sorry, no LAN parties without prior approval), mitigating concerns for CAM or vlan table exhaustion. Lastly, no funky l3/4 acl's are required to prevent users handing out DHCP addresses, leaking RA's, or fronting ARP as your routers MAC address to their vlan-sharin' neighbors--simply because they don't get to send layer2 frames to anyone but the upstream routers control plane. -Tk
