[c-nsp] BGP session going down during DDOS

[redscorpion69]

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 <no.spam at comcast.net> 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 <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/
>
>