North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Global BGP - 2001-06-23 - Vendor X's statement...

  • From: Matt Levine
  • Date: Tue Jun 26 14:35:17 2001

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<sigh>...  If the RFC jumped off a cliff...



- --
Matt Levine
@Home: [email protected]
@Work: [email protected]
ICQ  : 17080004
PGP  : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0D04CF 

- -----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Chance Whaley
Sent: Tuesday, June 26, 2001 12:36 PM
To: [email protected]; 'Jared Mauch'
Cc: 'Brett Frankenberger'; [email protected]
Subject: RE: Global BGP - 2001-06-23 - Vendor X's statement...




Vendor X released a limited statement to their customers describing
the issue - and their view on it. The large incumbent vendor that we
all know and love has confirmed the issue, and released a "patch" to
some of their customers. Vendor X also went on to state that at no
time did their boxes crash, mis-forward, reset, or have any issue
resulting from the events of the past weekend.

- From Vendor X's statement:

1.	Another vendor's implementation of BGP contained a bug that caused
EBGP peers to leak
	CONFEDERATION information across AS boundaries, interpreted as
malformed AS_PATH
	announcements.

2.	Vendor X's implementation of BGP-4 fully complies with the BGP-4
specification (RFC 1771) and
	accordingly, terminates a BGP session to a BGP peer who forwards
malformed AS_PATH
	announcement.

3.	Unfortunately, this other vendor does not adhere to the standard
in
the same manner and as a result,
	malformed AS_PATH announcements are propagated to other BGP peers.
This is contrary to
	RFC 1771. Vendor X believes that these vendors should modify their
implementation to adhere to
	the guidelines as stated per RFC 1771 (see section 6 - BGP Error
Handling).

4.	In light of the events of the past weekend and with input from a
number of the affected service
	providers (point #1 above), Vendor X has concluded that a review of
our BGP implementation is
	unnecessary at this time.


If you happen to be running Vendor X's software and think you may
have experienced the issue you can use the following to verify.

	[email protected]#sh ip bgp neighbor xxx.xxx.xxx.xx last

	BGP4: 86 bytes hex dump of packet received from neighbor that
contains Error

	ffffffff ffffffff ffffffff ffffffff 00560200
	00003bff ffffffff ffffffff ffffffff ffffff00
	2d0104fd e8005ac0 a8803a10 02060104 00010001
	02028000 02020200 ffffffff ffffffff ffffffff
	ffffffff 001318d0 f20118d0 c10e18d0 f20018d0


.chance
(not speaking for Vendor X in any way shape or form. Just passing
along info that I was sent.)




> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf
> Of  [email protected]
> Sent: Monday, June 25, 2001 9:59 PM
> To: Jared Mauch
> Cc: [email protected]; Brett Frankenberger; [email protected]
> Subject: Re: Global BGP - 2001-06-23
>
>
>
> Jared Mauch wrote:
> >
> > On Mon, Jun 25, 2001 at 02:38:32PM -0700,
> [email protected] wrote:
> > > Can anyone verify whether Cisco still does BGP this way?
> (Propagate, then
> > > kill origionating session). If so, it rather clearly
> answers the question
> > > about how this managed to make it throughout the network...
> >
> > 	I'm fairly sure that is not the case anymore.
> >
> > > (For the record: I'm not trying to Cisco-bash here. All
> vendors have
> > > problems, and when you have a huge market share, your
> problems tend to
> > > show up much more obviously, when they appear. However,
> Cisco does still
> > > have a huge market share, meaning this affected a whole
> lot of people,
> > > if true... so, I'm curious).
> >
> > 	From what I can tell this time it was not ciscos fault.  It
> > appears  that the vendor that had the problem just had an issue
> > with a  specific "valid" announcement that others propogated to
> > it.
>
> All I can say is that the only report I have had about what caused
> the  whole mess to start was a Cisco BugID regarding a mangling
> done by  some IOS versions on a particular sort of route update
> that made it  invalid (or perhaps, "more invalid"). And if Cisco is
> no longer
> propagating routes
> before shutting down the source session, then we're back to
> wondering how
> this particular issue managed to cause flaps at the same time
> across at
> least 5 "big player" networks that I've had reports about
> (including 3 by direct observation), at the same time. This person
> must
> have some pretty
> impressive connectivity, if they managed to get what appears
> to be well
> over a dozen routers at the absolute minimum, and more likely
> in the range
> of "hundreds" if the rumor volume is at all accurate, to each
> display the
> bug (since, if a bad announcement isn't propagated, it will
> never reach
> anything but the direct peers; thus, this person would have
> to be directly
> peered with every router that anyone saw flapping sessions to
> a customer).
>
> Now, I'll grant, it would be possible to do this, but for them to
> have  hit just *our* network, they would have to be on 3 major
> carries in 3  states, including some places that a normal class
> B-type announcer  just isn't terribly likely to have a peering
> session.
>
> > 	What is interesting is one could use this to see what providers
> > are  using vendor "X" at exchange points.
>
> Quite true. Though I suspect that in some cases, this might only
> tell  you what routing code they use. Making too many inferences is
> probably unwise.
> Especially given the number of folks who thought they knew
> who "X" was,
> only to state their guess and come out wrong...
> --
> **************************************************************
> *************
> Joel Baker                           System Administrator -
> lightbearer.com
> [email protected]
> http://www.lightbearer.com/~lucifer


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOzjUksp0j1NsDQTPEQI+2gCgiu1CGp0VZrdDmJhIR7twld+0lg4AoP9O
43Kd24mxIEgcAPj+GEEbqW8Y
=j1IU
-----END PGP SIGNATURE-----