On 8/27/10 1:07 PM, Mike Gatti wrote:
where's the change management process in all of this. basically now we are going to starting changing things that can potentially have an adverse affect on users without letting anyone know before hand .... Interesting concept.
BGP is transitive, change management is not. you have a change management process, your peer might integrate into that but have their own, your peer's peers almost certainly do not. Every time a wet-behind-the-ears network engineer connects a bgp speaker to the edge of the network it's an experiment in the the stability of the Internet. This on the fact of it seems like a quite reasonable experiment, which should have worked, except that it happened to tickle a bug...
On Aug 27, 2010, at 3:33 PM, Dave Israel wrote:
On 8/27/2010 3:22 PM, Jared Mauch wrote:
When you are processing something, it's sometimes hard to tell if something just was mis-parsed (as I think the case is here with the "missing-2-bytes") vs just getting garbage. Perhaps there should be some way to "re-sync" when you are having this problem, or a parallel "keepalive" path similar to MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is happening.
I know it wasn't there originally, and isn't mandatory now, but there is an MD5 hash that can be added to the packet. If the TCP hash checks out, then you know the packet wasn't garbled, and just contained information you didn't grok. That seems like enough evidence to be able to shrug and toss the packet without dropping the session.
-Dave
=+=+=+=+=+=+=+=+=+=+=+=+= Mike Gatti ekim.ittag@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=