[c-nsp] BGP session going down during DDOS

[Keegan Holley]

This is one of those things that isn’t supposed to happen but often does.  The first thing I’d look at are the log messages.  Are you sure the neighbor went down because of the DDOS attack?  Could have been another type of error or even a scheduled change during the attack.

Next I’d probably look at QOS settings.  BGP packets are marked NC so they are the last to be dropped during periods of congestion.  How are NC packets treated on your network?  Is there anything else in this queue that could have starved out your updates/hello’s?  If BGP updates or packets are being lost the TCP stack will end the BGP session sometimes before the dead timer expires.  

Lastly, I’d look at your filters and determine if anyone from the outside can send packets to your routers.  If CPU was low the routers themselves probably weren’t being attacked, but maybe someone was able to send packets to the BGP port.  This isn’t something commonly left open, but stranger things have happened.

On Mar 6, 2014, at 1:07 PM, redscorpion69 <redscorpion69 at gmail.com> wrote:

> Today we had a couple of dozen Gbps traffic to one of our customer.
> 
> At one point during attack, our PE router where the customer is attached
> had a BGP session to one of our RR go down, only to go up after half a
> minute.
> 
> Our core has juniper/asr9k, our PE router in question is 7600.
> 
> All our traffic is properly classified from RR to 7600 in both directions.
> The CPU stayed fairly low on PE, so if traffic is properly classified, how
> is it possible for router to drop BGP control plane?
> 
> If input queues are an issue, shouldn't default SPD configuration take care
> of that on 7600?
> 
> How to make sure this doesn't happen again?
> 
> Regards
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/