Out of interest, are your transit access interfaces sub-rate?
On 10 March 2014 06:41, redscorpion69 <[email protected]> wrote: > The BGP session went down, and stayed down for about 3 min, as if there was > a problem for TCP to establish a session back on. It happened during DDOS, > before and after that this session never dropped. There's nothing in logs > except that notification was sent since the hold timer expired. > > BGP is by default set to dscp 48, none of the intermediate queues which > guaranty bandwidth for this traffic has a single drop... > > Filters don't allow BGP sessions to our PE router. > > Attack was destined to one of out GRT customers /24 network attached to PE > router in question. > > By the way, what IS the best way to defend against this huge amount of > traffic? You can't really place policers at the edge of the network, it's > cumbersome and prone to errors. I think the proper QoS, and high network > capacity links is the only real defense. Apart from this BGP issue, there > were no other big problems... except all our VPN customers which have dscp0 > suffered as well. Probably the most secure way would be to separate > VPN/Voice from Internet architecture, but that would be expensive. > > Anyway, not sure what happened here... > > > > > On Fri, Mar 7, 2014 at 9:31 PM, Keegan Holley <[email protected]> wrote: > > > 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/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
