On 10/10/2012 20:54, Claudio Jeker wrote:
Looking at the pcap I see one strange thing:
17:48:39.910152 193.105.232.181.21798 > 193.105.232.145.179: S [tcp sum ok]
35124087:35124087(0) win 16384 <mss 1460,wscale 0,eol> (DF) [tos 0xc0] [ttl 1] (id
53673, len 48)
17:48:39.910198 193.105.232.145.179 > 193.105.232.181.21798: S [tcp sum ok]
1526797827:1526797827(0) ack 35124088 win 16384 <mss 1460,nop,wscale 3> (DF) (ttl
255, id 63110, len 48)
17:48:39.911212 193.105.232.181.21798 > 193.105.232.145.179: . [tcp sum ok] ack
1 win 16384 (DF) [tos 0xc0] [ttl 1] (id 53674, len 40)
17:48:39.911290 193.105.232.145.179 > 193.105.232.181.21798: F [tcp sum ok]
1:1(0) ack 1 win 2190 (DF) (ttl 64, id 22529, len 40)
17:48:39.912004 193.105.232.181.21798 > 193.105.232.145.179: P [tcp sum ok]
1:59(58) ack 1 win 16384: BGP (OPEN: Version 4, AS #30126, Holdtime 180, ID
192.228.82.16, Option length 29 ((CAP MULTI_PROTOCOL [IPv4 Unicast]) (CAP #128 len
0) (CAP ROUTE_REFRESH) (CAP #131 len 1) (CAP AS4 #30126))) (DF) [tos 0xc0] [ttl 1]
(id 53675, len 98)
17:48:39.912023 193.105.232.145.179 > 193.105.232.181.21798: R [tcp sum ok]
1526797828:1526797828(0) win 0 (DF) (ttl 64, id 22749, len 40)
17:48:39.912346 193.105.232.181.21798 > 193.105.232.145.179: . [tcp sum ok] ack
2 win 16384 (DF) [tos 0xc0] [ttl 1] (id 53676, len 40)
17:48:39.912360 193.105.232.145.179 > 193.105.232.181.21798: R [tcp sum ok]
1526797829:1526797829(0) win 0 (DF) (ttl 64, id 50452, len 40)
17:48:39.912980 193.105.232.181.21798 > 193.105.232.145.179: FP [tcp sum ok]
59:59(0) ack 2 win 16384 (DF) [tos 0xc0] [ttl 1] (id 53677, len 40)
17:48:39.912993 193.105.232.145.179 > 193.105.232.181.21798: R [tcp sum ok]
1526797829:1526797829(0) win 0 (DF) (ttl 64, id 29177, len 40)
17:48:39.913417 193.105.232.181.21798 > 193.105.232.145.179: . [tcp sum ok] ack
2 win 16384 (DF) [tos 0xc0] [ttl 1] (id 53678, len 40)
17:48:39.913430 193.105.232.145.179 > 193.105.232.181.21798: R [tcp sum ok]
1526797829:1526797829(0) win 0 (DF) (ttl 64, id 9044, len 40)
This connection initiated by the cisco is accepted and immediatly closed.
That looks suspicious (also because nothing is logged in bgpd). Feels like
pf(4) is playing dirty tricks here.
Afterwards the openbgpd initiates the session and the cisco sends back a
NOTIFICATION (maybe because it is still unhappy about the rather
unexpected FIN/RST of the previous session).
If the problem still exists when bgpd is accepting the cisco connection
then we need to have a closer look at the messages.
Hi Claudio,
For reference I did:
- disable pf (pfctl -d)
- take down the bgp session (bgpctl nei pv4_gw-003_to_ISC down)
- tcpdump (tcpdump -w /tmp/cap2.out -Xi bnx2 host 193.105.232.181)
- take up the bgp session (bgpctl nei pv4_gw-003_to_ISC up)
- enable pf back (pfctl -e)
Here is the new capture file (pf disabled):
http://elfe.lncsa.com/get?k=2crqFiFNUZNmKw0jvk0
# bgpctl show neigh pv4_gw-003_to_ISC
BGP neighbor is 193.105.232.181, remote AS 30126
Description: pv4_gw-003_to_ISC
BGP version 4, remote router-id 192.228.82.16
BGP state = Idle
Last read 00:04:17, holdtime 240s, keepalive interval 80s
Message statistics:
Sent Received
Opens 80 2
Notifications 0 80
Updates 0 0
Keepalives 2 0
Route Refresh 0 0
Total 82 82
Update statistics:
Sent Received
Updates 0 0
Withdraws 0 0
Last error: unknown error code
Thanks
Laurent
