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 <[email protected]> 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  [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to