Auto MDI/MDI-X + conference rooms + bored == loop

Anton Kapela tkapela at gmail.com
Fri Mar 26 22:56:15 UTC 2010


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








More information about the NANOG mailing list