- Test - lists.nanog.org

Re: Time to revise RFC 1771
by Richard A. Steenbergen 27 Jun '01

27 Jun '01

On Tue, Jun 26, 2001 at 09:32:10PM -0700, Sean Donelan wrote: > > I would prefer we try to maintain the BGP sessions. But if you think > your peer's protocol implementation is flawed, cycling the BGP session > is unlikely to fix the software. It just makes things worse as you > announce and withdrawl sections of the route table repeatedly. Shutdown > the session (and keep it down) and wait for human intervention. Well not to play Dr. Obvious, but to quote a spec people claim to be following: If a BGP speaker detects an error, it shuts down the connection and changes its state to Idle. Getting out of the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent BGP errors may result in persistent flapping of the speaker. To avoid such a condition it is recommended that Start events should not be generated immediately for a peer that was previously transitioned to Idle due to an error. For a peer that was previously transitioned to Idle due to an error, the time between consecutive generation of Start events, if such events are generated automatically, shall exponentially increase. The value of the initial timer shall be 60 seconds. The time shall be doubled for each consecutive retry. So if you want to see it used, get on your vendor about it... Also, RFC1771 is pretty out of date, the "least incorrect" reference currently available is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-12.txt -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: RFC 1771, further thoughts
by Marshall Eubanks 27 Jun '01

27 Jun '01

> >In an attempt to return to an argument, rather than simple contradiction >(ok, ok, it's far more polite and reasonable so far than that would imply, >but I couldn't miss the cheap shot; apologies hereby tendered), perhaps we >should consider *what* the RFC should say, if it should be changed? Going >to the WG with a proposal in hand and a rationale to support it would seem >to be the best path. > >So, a summary of my view on it at the moment: > >Assumption #1) Resetting a BGP session is 'costly'. Both in terms of the >time it takes, the stability it removes, and the fact that it flaps all >of your *outgoing* announcements as well as incoming ones. > >Assumption #2) A router that sends a malformed route is clearly doing >something which it Should Not Be Doing (tm) (ok, this might be axiomatic, >but should still be laid out) > >Assumption #3) The current practice has been shown to demonstrably >increase the brittleness of the Internet, by causing severe flapping when >someone only partially follows the RFC (in particular, propagating bad >route data, whether or not the origional source session is reset). > >Assumption #4) Routing errors which are bad data, but *not* malformed >routes, will not generally be caught by normal means in normal operation, >until a case of human intervention to cross-check the data. > >Assumption #5) Any router which breaks so badly as to start spewing large >amounts of validly formed but errorneous data, and is *also* spewing badly >formed data, will spew noticeable amounts of said badly formed data. (This >one is key, and is only a conjecture; field evidence would be of great use >in validating it). > Hello; Can "badly formed data" be reasonably clearly defined ? What tests are there for "validly formed but errorneous data" ? There are several monitoring efforts (including the one done here) which compare sets of (m)bgp routing tables over time. It seems to me that such (m)bgp pollution should be detectable with a monitoring project. BTW, what seems to be the clearest sign here of the recent flap was the dropping of 43 Autonomous Systems by UU.net for the Sat Jun 23 16:37:41 2001 status run. This is not a good enough metric to relieably detect such problems. There do seem to be a lot of weird changes in the routing table in that dump, but a simple test for this is not apparent to me at present. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme(a)on-the-i.com http://www.on-the-i.com >Conclusion: changing the RFC from saying you MUST do a NOTIFY and ditch the >session could be adjusted to stating that you MUST handle the error in one >of two ways: do a NOTIFY and ditch the session (traditional), or send an >ALERT and discard the badly formed route. Additionally, this alternative >handling MUST NOT be enabled by default, and SHOULD have a threshhold >parameter at which the session will undergo a NOTIFY/reset, under the >assumption that the host sending an appreciable amount of badly formed >routes is, in fact, in danger of sending correctly formed but erroneous >data as well. > >Suitable threshold values are left as an excercise to local admins and BCP >documents; I would think this could be negotiated as a capability extension >to BGP4, with the fallback, of course, being to follow the traditional RFC >practice. > >Thoughts? >-- >*************************************************************************** >Joel Baker System Administrator - lightbearer.com >lucifer(a)lightbearer.com http://www.lightbearer.com/~lucifer > Marshall Eubanks tme(a)21rst-century.com

3 2

Re: Time to revise RFC 1771
by Sean Donelan 27 Jun '01

27 Jun '01

On Tue, 26 June 2001, Clayton Fiske wrote: > I don't object to the discussion of changing the RFC (whether I agree > or not), and I accept that Vendor [everyone else except Cisco] having > a knob for this would have prevented some routing disruptions for some > networks. But then again, static routes would have prevented that too. > It doesn't mean they're a good idea. What I object to is that people > are using this particular case as justification for said discussion. This is the third time a BGP protocol error has lead to repeated BGP flapping across the Internet due to implementations aborting the BGP session, restarting it, and aborting it over and over. GATED, Bay Networks and now Vendor X have each had issues internetworking with Cisco. The particular cause varied, but the error handling in all the cases resulted in severe route flaps across a substantial portion of the net at the time. It wasn't Cisco's fault all the time. But what was common was implementations following RFC's 1771 guidance that the proper behaivor is to abort the BGP session. If not now, when? I would prefer we try to maintain the BGP sessions. But if you think your peer's protocol implementation is flawed, cycling the BGP session is unlikely to fix the software. It just makes things worse as you announce and withdrawl sections of the route table repeatedly. Shutdown the session (and keep it down) and wait for human intervention.

2 1

Re: RFC 1771, further thoughts
by Sean Donelan 27 Jun '01

27 Jun '01

On Tue, 26 June 2001, lucifer(a)lightbearer.com wrote: > In an attempt to return to an argument, rather than simple contradiction > (ok, ok, it's far more polite and reasonable so far than that would imply, > but I couldn't miss the cheap shot; apologies hereby tendered), perhaps we > should consider *what* the RFC should say, if it should be changed? Going > to the WG with a proposal in hand and a rationale to support it would seem > to be the best path. One problem which makes the current practice worse in practice is the cycling of the BGP session. Once you decide a BGP peer is "insane" why start a fresh BGP session with the same peer, only to have them send the same "bad" information again, and again, and again, and again. If folks want to isolate misbehaving peers, do an ADMIN SHUTDOWN on the session.

2 1

Re: Time to revise RFC 1771
by Sean Donelan 27 Jun '01

27 Jun '01

On Tue, 26 June 2001, Clayton Fiske wrote: > Plus, a CRC error can occur between two valid, compliant, bug-free > implementations. A bad route, by definition, can't. We're not talking > about external faults here, but broken implementations. When one side > of a protocol session simply breaks the rules, I don't think it's > reasonable to say that the other side needs to be "fixed" to accept > that breakage. Fix the broken side. Uhm, lets see what you think of this press announcement. "Pardon us, we must shutdown the Internet will we decide whose software needs to be fixed. Don't worry, as soon as it is fixed, the Internet will be rebooted." Yep, somebody's implementation was broken. One part of the response is to fix their implementation. While we waiting to get the fix, the rest of the Internet should not have been flapping.

2 1

RFC 1771, further thoughts
by lucifer＠lightbearer.com 27 Jun '01

27 Jun '01

In an attempt to return to an argument, rather than simple contradiction (ok, ok, it's far more polite and reasonable so far than that would imply, but I couldn't miss the cheap shot; apologies hereby tendered), perhaps we should consider *what* the RFC should say, if it should be changed? Going to the WG with a proposal in hand and a rationale to support it would seem to be the best path. So, a summary of my view on it at the moment: Assumption #1) Resetting a BGP session is 'costly'. Both in terms of the time it takes, the stability it removes, and the fact that it flaps all of your *outgoing* announcements as well as incoming ones. Assumption #2) A router that sends a malformed route is clearly doing something which it Should Not Be Doing (tm) (ok, this might be axiomatic, but should still be laid out) Assumption #3) The current practice has been shown to demonstrably increase the brittleness of the Internet, by causing severe flapping when someone only partially follows the RFC (in particular, propagating bad route data, whether or not the origional source session is reset). Assumption #4) Routing errors which are bad data, but *not* malformed routes, will not generally be caught by normal means in normal operation, until a case of human intervention to cross-check the data. Assumption #5) Any router which breaks so badly as to start spewing large amounts of validly formed but errorneous data, and is *also* spewing badly formed data, will spew noticeable amounts of said badly formed data. (This one is key, and is only a conjecture; field evidence would be of great use in validating it). Conclusion: changing the RFC from saying you MUST do a NOTIFY and ditch the session could be adjusted to stating that you MUST handle the error in one of two ways: do a NOTIFY and ditch the session (traditional), or send an ALERT and discard the badly formed route. Additionally, this alternative handling MUST NOT be enabled by default, and SHOULD have a threshhold parameter at which the session will undergo a NOTIFY/reset, under the assumption that the host sending an appreciable amount of badly formed routes is, in fact, in danger of sending correctly formed but erroneous data as well. Suitable threshold values are left as an excercise to local admins and BCP documents; I would think this could be negotiated as a capability extension to BGP4, with the fallback, of course, being to follow the traditional RFC practice. Thoughts? -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer(a)lightbearer.com http://www.lightbearer.com/~lucifer

1 0

Re: Time to revise RFC 1771
by Sean Donelan 27 Jun '01

27 Jun '01

On Tue, 26 June 2001, Clayton Fiske wrote: > Plus, a CRC error can occur between two valid, compliant, bug-free > implementations. A bad route, by definition, can't. We're not talking > about external faults here, but broken implementations. When one side > of a protocol session simply breaks the rules, I don't think it's > reasonable to say that the other side needs to be "fixed" to accept > that breakage. Fix the broken side. Uhm, lets see what you think of this press announcement. "Pardon us, we must shutdown the Internet will we decide whose software needs to be fixed. Don't worry, as soon as it is fixed, the Internet will be rebooted." Yep, somebody's implementation was broken. One part of the response is to fix their implementation. While we waiting to get the fix, the rest of the Internet should not have been flapping.

1 0

Re: Cable Modem [really responsible engineering]
by Wojtek Zlobicki 27 Jun '01

27 Jun '01

----- Original Message ----- From: "Daniel Senie" <dts(a)senie.com> To: "Wojtek Zlobicki" <wojtekz(a)idirect.com> Sent: Tuesday, June 26, 2001 9:51 PM Subject: Re: Cable Modem [really responsible engineering] > At 09:43 PM 6/26/01, Wojtek Zlobicki wrote: > > > >----- Original Message ----- > >From: "Chris Adams" <cmadams(a)hiwaay.net> > >To: <nanog(a)merit.edu> > >Sent: Tuesday, June 26, 2001 9:20 PM > >Subject: Re: Cable Modem [really responsible engineering] > > > > > > > > > > Once upon a time, Miquel van Smoorenburg <miquels(a)cistron-office.nl> said: > > > > When the BRAS requests config info when the circuit goes up (using > > > > radius) or when it acts as a DHCP relay, it includes the VPI/VCI > > > > of the ATM channel in the request. That means that you can assign > > > > IP addresses based on the physical connection rather than the MAC > > > > address, and this is what we do [well, will do soon anyway ;)] > > > > > > Okay, but how do you keep the end user from putting a different IP in > > > their computer? We use PPPoA for our "residential" DSL, but someone > > > that works here lives outside our service area (small local telcos are > > > all over this area), and just got DSL from his local telco/ISP, which > > > uses 1483 bridging. He has multiple computers, so he just picked > > > another address, pinged it to see it wasn't in use at the moment, used > > > it, and it worked just fine. > > > >Access lists are one way to go :) You dont get out unless we say so :) > > > > > > > > Also, how do you prevent the user from trying to forge someone else's > > > IP address or even MAC address in outgoing packets? Without protecting > > > against forged packets, I don't see how to provide accountability when > > > someone attacks. > > > >How would anyone find out anothers MAC. As long as you seperate each > >customer into their own bridge group, there is no way for them to find > >anothers MAC. As for forging IP's not much you can do about that. MAC > >address access list.. do they exists ? > > Broadcast packets... DHCP DISCOVERs if nothing else. > > tcpdump -i eth0 > > on a Linux box attached to my cable modem finds all kinds of broadcast > packets from neighbors' computers (mostly Windows-related packets) as well > as ARP requests. It's possible this is just a poorly configured system, but > I'm not sure how bridge groups are going to isolate you from one another > AND block broadcasts, and still allow users to play interactive games > against one another (i.e. you still have to let them send packets around > the neighborhood). There is not much you can do about broadcast packets. This is not a grave security risk as most of this traffic is benine. It is unicast traffic that I would not want you to see (can you see any of that?). With carefull subnetting, you could prevent these from being seen. Is it plausible (I don't know the cable modem hardware well enough to comment here) to assign IP/32 to virtual interfaces ? Since a subnet in this case is only ony IP, there is no broadcast. How could one filter out MAC layer or IP layer broadcasts ? BTW , if you really want to kill a few weeks of your time, get a copy of TCPTRACE and XLOT. TCPTRACE allows you to take a tcpdump dump file (tcpdump -w dump_file_name ) and plot it. You can track RTT, windows size, throughput. XPLOT is used to display the plots created by TCPTRACE. > > > > > > > > DHCP or RADIUS (how did I know you used RADIUS :-) ) is fine for > > > assigning things, but how do you _enforce_ those assignments? I know > > > how with PPPoA, but not with a bridged network (the same thing applies > > > with cable modems). > > > > > > -- > > > Chris Adams <cmadams(a)hiwaay.net> > > > Systems and Network Administrator - HiWAAY Internet Services > > > I don't speak for anybody but myself - that's enough trouble. > > ----------------------------------------------------------------- > Daniel Senie dts(a)senie.com > Amaranth Networks Inc. http://www.amaranth.com

1 0

SBC forcing new contract on ISPs
by Christopher A. Woodfield 26 Jun '01

26 Jun '01

http://sanfrancisco.bcentral.com/sanfrancisco/stories/2001/06/18/story3.html If I'm reading this correctly, SBC is forcing ISPs that resell SBC's DSL access to go with PPPoE over ATM, thus potentially forcing businesses to buy DSL net access from SBC directly. Am I way off base? Anyone know more about this situation who can comment? -C --------------------------- Christopher A. Woodfield rekoil(a)semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

8 14

RE: Global BGP - 2001-06-23 - Vendor X's statement...
by Sean Donelan 26 Jun '01

26 Jun '01

On Tue, 26 June 2001, "Chance Whaley" wrote: > How would you like Vendor X to liberally handle the situation? There is > a point when being too liberal causes issue - like this one. The idea is > that if the original peer followed the spec it would of been contained > at the source and this would of never happened. Where is the line? > Something about GIGO comes to mind. I would prefer implementations (not vendors) reject the one router which they don't like, and accept the other 100,000+ routes in the global Internet without flapping BGP sessions. Killing 100,000 routes because you don't like one seems a bit excessive.

2 1