[124234] in North American Network Operators' Group
Re: Auto MDI/MDI-X + conference rooms + bored == loop
daemon@ATHENA.MIT.EDU (Anton Kapela)
Fri Mar 26 18:56:59 2010
From: Anton Kapela <tkapela@gmail.com>
In-Reply-To: <20100326220922.GH12189@angus.ind.WPI.EDU>
Date: Fri, 26 Mar 2010 18:56:15 -0400
To: Chuck Anderson <cra@WPI.EDU>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi Chuck,
> Anyone have suggestions on Ethernet LAN loop-prevention? With the=20
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.=20
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.=20
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.ht=
ml
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.=20=
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=20
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.=20
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.=20
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.=20
-Tk