[c-nsp] BGP session going down during DDOS

[Mick O'Rourke]

Out of interest, are your transit access interfaces sub-rate?


On 10 March 2014 06:41, redscorpion69 <redscorpion69 at gmail.com> 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 <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/
> >
> >
> _______________________________________________
> 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/
>