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