Enhanced Route Refresh Capability (rfc7313)

[Arnaud Fenioux]

On 23 Jun 2015, at 15:29, Ondrej Zajicek <santiago at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20150623/a2c3e8fd/attachment.asc>