On 23 Jun 2015, at 15:29, Ondrej Zajicek <santi...@crfreenet.org> wrote: > > Well, they should ignore it if they don't know/like it. Yes, for sure!
> The problem is specific to IPv6 sessions, IPv4 sessions works fine?
Well... actually no, I had to "enable route refresh off;” on the same peers in
IPv4 and IPv6 :
IPv4 sessions were established without any capability while route refresh was
enable.
> Or perhaps the problem is triggered on both, but as a fallback, the capability
> negotiation was disabled on second try, which works for IPv4, but not
> for IPv6 (as multiprotocol cap. must be here)?
Multiprotocol cap was advertised on both side, but I don’t think it is related
to this.
on IPv4 with route-refresh enable I can see :
BGP state: Established
Neighbor caps:
Session: external route-server
on IPv4 with route-refresh disable I can see :
BGP state: Established
Neighbor caps: refresh restart-aware AS4
Session: external route-server AS4
As far as I understand from the traces I took, when I disable route-refresh
capabilities, bird stops advertising enhanced (70) and “regular” (2) route
refresh, but when the neighbour sends the regular route-refresh capability,
bird enables it.
Which is explained in http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2 but
not very up to date compared to
https://gitlab.labs.nic.cz/labs/bird/commit/9aed29e605334d34d0e6a90fc172ee83d0274ad3
Can you confirm, if I understand correctly :
"That even when disabled, BIRD can send route refresh requests [and accept the
capability]” ?
Thank you
Arnaud
signature.asc
Description: Message signed with OpenPGP using GPGMail
