On Wed, Oct 10, 2012 at 05:51:38PM +0200, Laurent CARON wrote: > On 10/10/2012 16:40, Simon Perreault wrote: > >What versions? > > OpenBSD 5.1 (sorry for not mentionning it). > > > > >>In my logs I do observe this: > > > >A pcap dump would be useful... > > Here it is: > http://elfe.lncsa.com/get?k=5Rya5Acaq26TqJ9MXG > > >FYI, subcode 8 has not yet been assigned by IANA: > >http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xml#bgp-parameters-6 > > > > > >...but it is defined in a new draft: > >http://tools.ietf.org/html/draft-ietf-idr-bgp-multisession-07#section-5 > > > > 8 - Grouping Conflict - values of capability codes used in > > Session Id of the received message cannot be unambiguously > > mapped to a locally configured group > > > >That should provide enough clue to be able to dig at the right place... > > Thanks for the hint.
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. -- :wq Claudio
