[j-nsp] SRX drops BGP session

[randy.taylor at bell.ca]

Would it no be advisae to either teace it or a tcpdump from the OS you can see what packets are being sent and received on the interface?


--------------------------
Sent using BlackBerry


----- Original Message -----
From: juniper-nsp-bounces at puck.nether.net <juniper-nsp-bounces at puck.nether.net>
To: Jeroen Valcke <jeroen.valcke at belnet.be>
Cc: juniper-nsp at puck.nether.net <juniper-nsp at puck.nether.net>
Sent: Thu Oct 13 18:30:50 2011
Subject: Re: [j-nsp] SRX drops BGP session

> Indeed, when I check the session table on the SRX. I do get an entry for
> the
> BGP session, but it dissapears after only a few seconds. That seems wrong
> to
> me.
>

You mean a firewall session in "show security flow session"? If so, let me
express my doubts, an MTU related issue could make it close immediately. If
Harry's quick test with decreasing MSS doesn't help, you'd rather unpack
your sniffer and check if someone sends a TCP RST.

We ran into a similar issue when a broken switch (BTW, an EX3200) flooded
the frames carrying BGP packets instead of switching them. In addition it
was not a P2P VLAN, other routers existed in the broadcast domain of the BGP
peering subnet. As as result BGP peers received several copies of each
packet. After a few attempts to sort out what happens, one of the peers sent
a TCP RST, closing the FW session, but (I don't really remember why) not
closing the BGP session on the peer itself. Which in turn led to "Hold down
timer expired". Then the BGP session reestablished and the whole thing
repeated again.

In my case it was iBGP, so at the SRX side traffic passed from ingress IFL
to loopback, falling under security policy with "log on close" option
enabled. This is how we discovered the TCP RST.
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp