[j-nsp] Bgp peer sessions flap in 165k-245k pps/sec DoS

Stefan Fouant sfouant at gmail.com
Sun Feb 15 14:33:02 EST 2009


On Sun, Feb 15, 2009 at 5:49 AM, Samit <janasamit at wlink.com.np> wrote:
> I do have filter in placed to protect the RE. But the attack is not
> targeted or directed to any interfaces of my router. My customer network
> as under DoS attacked , tcpdump snapshot   attached below "x" is source
> and "y" is target.

If the attack was not targetted towards your router, then the traffic
would not have been handled by the RE, unless of course there were IP
Options which caused the packet to be sent to the RE for further
analysis.  The more likely reason, as you suggest, was that the
control plane of your customers routers was affected in some way,
causing them to bounce their BGP sessions.  Take a look at your log
(show log messages) for any BGP bounce events and you might find out
that the Hold Timer expired or something along these lines, which
caused your router to sever the BGP session with your neighbor.

> 04:16:18.226095 IP x.x.x.x.12372 > y.y.y.y.18990: UDP,
> length 36
> 04:16:18.226112 IP x.x.x.x.12372 > y.y.y.y.18990: UDP,
> length 36
> 04:16:18.226115 IP x.x.x.x.12372 > y.y.y.y.18990: UDP,
> length 36
> 04:16:18.226131 IP x.x.x.x.12372 > y.y.y.y.18990: UDP,

Looking at the tcpdump output, this looks like your general
run-of-the-mill UDP DoS flood.  It appears you could filter this
traffic destined for your customers network fairly easily by filtering
on UDP source-port 12372, or UDP destination-port 18990, or using a
match on a packet-length of 36 bytes.

-- 
Stefan Fouant

Yesterday it worked.
Today it is not working.
Windows is like that.


More information about the juniper-nsp mailing list