Hi Antonio, 2010/8/29 Antonio Soares <[email protected]>
> > Did you notice this problem ? > > I did not observe the problem by myself, but there is a long thread about it on NANOG mailing list. You can go through their archives to read what have been said: http://mailman.nanog.org/pipermail/nanog/2010-August/thread.html (Thread is named "Did your BGP crashed today ?") > Now I’m trying to find what bug could be related with that and I found > this: > http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml > > > This is an IOS-XR bug but the customer had the problem with IOS. It seems > there is a relation between the two but I’m not sure. The 12K running IOS > had to be reloaded due to lack of memory. > The following statement in the Security Advisory you refer (the same than the one that was pointed in the NANOG ML), provides a part of the explanation: "Affected devices running Cisco IOS XR Software corrupt the unrecognized attribute before sending to neighboring devices, but neighboring devices may be running operating systems other than Cisco IOS XR Software and may still reset the BGP peering session after receiving the corrupted update. This is per standards defining the operation of BGP." I would then guess that your customer BGP router is connected with another router running IOS-XR, which altered the BGP update with the experimental attribute from the RIPE. According to the Security Advisory, your router should have reset the BGP session, but according to your experience it used all memory and needed to be reloaded. I can't explain this problem. Maybe your customer's 12k IOS has a memory leakage somewhere - probably related with BGP sessions -. If I were you I would start looking into that direction. Yann _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
