On Mon, Feb 23, 2009 at 02:11:38PM +0100, Arnoud Vermeer wrote: > I found a different way to replicate the bug, this time it crashes ALL > the IPv6 sessions connected to multiple Foundry switches (cisco seems > fine). I have setup a v6 session with a tcp md5sig like so: > > group "peers-rs-v6" { > announce IPv6 unicast > announce IPv4 none > softreconfig in yes > enforce neighbor-as yes > set nexthop no-modify > local-address 2001:7F8:1::A500:6777:4 > > neighbor 2001:7f8:1::A500:1200:1 { > descr "AS1200-v6-01" > remote-as 1200 > announce all > passive > tcp md5sig password hondjes > } > > neighbor 2001:7f8:1::a504:8345:1 { > descr "XSNEWS-v6-01" > remote-as 48345 > announce all > passive > max-prefix 5 > } > > } > > # bgpctl s s > AS1200-v6-01 1200 9042 8142 0 00:13:34 Idle > XSNEWS-v6-01 48345 9374 8492 0 00:12:22 1/5 > > While in Idle, the session logs the following in daemon: > > Feb 23 14:00:03 radix-new bgpd[19498]: Connection attempt from neighbor > 2001:7f8:1::a500:1200:1 (AS1200-v6-01) while session is in state Idle > Feb 23 14:00:23 radix-new bgpd[19498]: Connection attempt from neighbor > 2001:7f8:1::a500:1200:1 (AS1200-v6-01) while session is in state Idle > > I then clear the peering with the md5 hash: > > bgpctl neigh AS1200-v6-01 clear > > # bgpctl neigh AS1200-v6-01 clear > request processed > # bgpctl s s > XSNEWS-v6-01 48345 9380 8497 0 00:14:35 1/5 > AS1200-v6-01 1200 9042 8142 0 00:17:15 Active > > but then after a few seconds, when the session becomes alive, the empty > update get send out, and all foundry based v6 sessions reset. > > # bgpctl s s > XSNEWS-v6-01 48345 9381 8501 0 00:00:11 Idle > AS1200-v6-01 1200 9047 8152 0 00:00:11 Idle >
Could you please provide mrt session dumps or tcpdumps of the session that fail. This seems like foundry is freaking out about something that is actually a valid BGP update. Neither Henning nor I do have sessions to foundry routers that we can play with. -- :wq Claudio