RE: Bird 2.0.1/ RR VPNv6 Issue

2018-02-02 Thread Gilles Friang
>Hello
>
>Your config seems fine. Although you probably have no routes in master6, so if 
>VPNv6 routes were imported,
>their next-hop would be resolved as unreachable.
>
>According to stats, BIRD logs no updates, only withdraws. So either neighbors 
>send withdraws, or BIRD detected
>some 'errors' in updates and treated them as to withdraws. Are there any error 
>messages in BIRD log?
>
>One idea is that neighbors want to use IPv4 next-hops for VPNv6 routes, but 
>BIRD does not signal support
>for that. Is it possible? What next hop should be used by these VPNv6 routes? 
>You can enable support
>for dual next hops by 'extended next hop' option in the channel:
>
>   vpn6 mpls {
>   # connects to vpntab6 table by default
>   import all;
>   export all;
>   extended next hop;
>   };
>
>Seems like we forgot to document the option. You should get both IGP IPv4
>table and IGP IPv6 table in the show protocols output for that channel.

Unfortunately no, logs was empty except that since reconfiguring, I do not have 
this output anymore:

"2018-02-02 09:52:29.798  xdsl_01_tc2: Invalid NEXT_HOP attribute"

You were right, adding "extended next hop" solved the issue, thank you very 
much:
---
  Channel vpn6-mpls
State:  UP
Table:  vpntab6
Preference: 100
Input filter:   ACCEPT
Output filter:  ACCEPT
Routes: 2384 imported, 3 exported
Route change stats: received   rejected   filteredignored   accepted
  Import updates:   4784  0  0   2390   2394
  Import withdraws:   10  0---  0 10
  Export updates:   2397   2394  0---  3
  Export withdraws:   10---------  0
BGP Next hop:   81.93.6.3
IGP IPv4 table: master4
IGP IPv6 table: master6
---

>BTW, are the VPNv6 stats formatting broken in show output or it was just
>mangled by mail clients?

Neither bird nor email client. It was me 

Anyway, thanks again for your help and for this great software.

Gilles Friang

Sewan 

-Message d'origine-
De : Ondrej Zajicek [mailto:santi...@crfreenet.org] 
Envoyé : jeudi 1 février 2018 17:33
À : Gilles Friang <gilles.fri...@sewan.fr>
Cc : bird-users@network.cz
Objet : Re: Bird 2.0.1/ RR VPNv6 Issue

On Thu, Feb 01, 2018 at 03:49:44PM +, Gilles Friang wrote:
> Hello,
> 
> I am testing Bird 2.0.1 as a RR in order to replace very old Cisco Hardware 
> RR.
> 
> Everything was fine until I tried VPNv6 RR. Bird seems to ignore all vpnv6 
> routes:
> 
>   Channel vpn4-mpls
> State:  UP
> Table:  vpntab4
> Preference: 100
> Input filter:   ACCEPT
> Output filter:  ACCEPT
> Routes: 5237 imported, 17 exported
> Route change stats: received   rejected   filteredignored   
> accepted
>   Import updates:   5362  0  0  0   
> 5362
>   Import withdraws:  125  0---  0
> 125
>   Export updates:   5401   5362  0--- 
> 39
>   Export withdraws:  147--------- 
> 22
> BGP Next hop:   A.A.A.A
> IGP IPv4 table: master4
>   Channel vpn6-mpls
> State:  UP
> Table:  vpntab6
> Preference: 100
> Input filter:   ACCEPT
> Output filter:  ACCEPT
> Routes: 0 imported, 0 exported
> Route change stats: received   rejected   filteredignored   
> accepted
>   Import updates:  0 0 0  
>   0   0
>   Import withdraws: 4889   0---   
> 4889 0
>   Export updates:  0 0  0 
>   ---  0
>   Export withdraws:0  ------  
> ---  0
> BGP Next hop:   ::
> IGP IPv6 table: master6
> 
> Unlike VPNv4 output, BGP Next hop is empty here...not sure if it's the cause 
> of my issue.
> When I check on one of the client, it was sending ipv6 routes normally.
> 
> VPNv6 are configred through ipv4 bgp sessio

Re: Bird 2.0.1/ RR VPNv6 Issue

2018-02-01 Thread Ondrej Zajicek
On Thu, Feb 01, 2018 at 03:49:44PM +, Gilles Friang wrote:
> Hello,
> 
> I am testing Bird 2.0.1 as a RR in order to replace very old Cisco Hardware 
> RR.
> 
> Everything was fine until I tried VPNv6 RR. Bird seems to ignore all vpnv6 
> routes:
> 
>   Channel vpn4-mpls
> State:  UP
> Table:  vpntab4
> Preference: 100
> Input filter:   ACCEPT
> Output filter:  ACCEPT
> Routes: 5237 imported, 17 exported
> Route change stats: received   rejected   filteredignored   
> accepted
>   Import updates:   5362  0  0  0   
> 5362
>   Import withdraws:  125  0---  0
> 125
>   Export updates:   5401   5362  0--- 
> 39
>   Export withdraws:  147--------- 
> 22
> BGP Next hop:   A.A.A.A
> IGP IPv4 table: master4
>   Channel vpn6-mpls
> State:  UP
> Table:  vpntab6
> Preference: 100
> Input filter:   ACCEPT
> Output filter:  ACCEPT
> Routes: 0 imported, 0 exported
> Route change stats: received   rejected   filteredignored   
> accepted
>   Import updates:  0 0 0  
>   0   0
>   Import withdraws: 4889   0---   
> 4889 0
>   Export updates:  0 0  0 
>   ---  0
>   Export withdraws:0  ------  
> ---  0
> BGP Next hop:   ::
> IGP IPv6 table: master6
> 
> Unlike VPNv4 output, BGP Next hop is empty here...not sure if it's the cause 
> of my issue.
> When I check on one of the client, it was sending ipv6 routes normally.
> 
> VPNv6 are configred through ipv4 bgp sessions (which works fine with our 
> actual RR), here is the bird.conf configuration:

Hello

Your config seems fine. Although you probably have no routes in master6, so if 
VPNv6 routes were imported,
their next-hop would be resolved as unreachable.

According to stats, BIRD logs no updates, only withdraws. So either neighbors 
send withdraws, or BIRD detected
some 'errors' in updates and treated them as to withdraws. Are there any error 
messages in BIRD log?

One idea is that neighbors want to use IPv4 next-hops for VPNv6 routes, but 
BIRD does not signal support
for that. Is it possible? What next hop should be used by these VPNv6 routes? 
You can enable support
for dual next hops by 'extended next hop' option in the channel:

vpn6 mpls {
# connects to vpntab6 table by default
import all;
export all;
extended next hop;
};

Seems like we forgot to document the option. You should get both IGP IPv4
table and IGP IPv6 table in the show protocols output for that channel.


> Unlike VPNv4 output, BGP Next hop is empty here...not sure if it's the cause 
> of my issue.

Unlikely. That would be relevant only for export and when BGP next hop 
attribute is set to self
(which is not done by route reflector).


BTW, are the VPNv6 stats formatting broken in show output or it was just
mangled by mail clients?

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."


signature.asc
Description: PGP signature