Clarification to note about T3/EGP problem

Mark Knopper mak
Wed Aug 12 02:53:53 UTC 1992


Hi. I received this clarification to the previous note and thought
it would be best to send it out directly.
	Mark



> From:    Curtis Villamizar <curtis at ans.net>
> To:      Jordan Becker <becker at ans.net>
> CC:      Mark Knopper <mak at merit.edu>

> 
> 
> 
> Jordan,
> 
> I would like to propose the following changes to two of your
> paragraphs just to get the facts straight (since it is a large
> audience) without going into the gory details.
> 
> Curtis
> 
> ------------------------------------------------------------------------
> 
> > 	Also, there is a dormant bug in the RS6000 rcp_routed EGP code
> > which involves routes getting imported via IBGP which do not get
> > flushed out of a queue.  When the regional router flaps (misses one
> > message from the peer) due the 8KB+ update described above, the
> > rcp_routed routes derived from EGP sitting in the queue do not get
> > installed and this might indirectly result in a routing inconsistency
> > between the ENSS and its CNSS neighbor.
> 
> 	Also, there is a dormant bug in the RS6000 rcp_routed EGP code
> which involves routes getting transferred internally via IBGP.  If the
> regional router is able to maintain the EGP session but does not send
> it's own updates in a timely fashion due the 8KB+ update described
> above, the rcp_routed IBGP unreachable messages derived from EGP are
> queued but not flushed and do not get installed.  This can result in a
> routing inconsistency between the ENSS and its CNSS neighbor and can
> lead to a period of CPU starvation under heavy packet load.  Under
> some circumstances this can further aggrevate the routing flap.
> 
> ...
> 
> > 	However this fix not solve the problem of the 8KB+ updates
> > causing route flapping on several regional peer routers.  Peer
> > networks that are running BGP should not experience this problem.  We
> > have contacted Cisco, Proteon, and Wellfleet, and have learned the
> > following regarding their suggested software fixes to this problem.
> 
> 	The change made to the T3 routing daemon addresses a secondary
> effect.  However this fix does not solve the problem of the 8KB+
> updates causing failure to reassemble large updates and possible route
> flapping on several regional peer routers.  Peer networks that are
> running BGP should not experience this problem.  We have contacted
> Cisco, Proteon, and Wellfleet, and have learned the following
> regarding their suggested software fixes to this problem.





More information about the NANOG mailing list