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 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
Re: Bird 1.6.3 removing IPv6 device routes on Linux (3.10.0)
On Wed, Jan 31, 2018 at 02:06:22PM +, Ben Arblaster wrote: > Hi, > > I’m seeing an issue with bird 1.6.3 where IPv6 device routes are unexpectedly > removed from the kernel table on Linux (3.10.0, CentOS 7) when bird removes a > matching route learned via another protocol (in this case OSPF). > ... > This is a change in behaviour from 1.4.5 and seems like a bug, rather than > the expected behaviour? Hi This is an unfortunate side-effect of IPv6 ECMP changes introduced in 1.6.x. You can fix it by setting kernel protocol option 'metric' to e.g. 32, see [*]. Also, the default value for kernel 'metric' has changed to 32 in version 2.0.0. [*] http://bird.network.cz/?get_doc=bird-6.html#krt-metric -- 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
Bird 2.0.1/ RR VPNv6 Issue
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--- 0125
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:
log "/home/bird/log/bird.log" all;
debug commands 0;
debug protocols {states,events};
router id A.A.A.A;
ipv4 table master4;
ipv6 table master6;
vpn4 table vpntab4;
vpn6 table vpntab6;
protocol kernel kernel4 {
#persist;# Don't remove routes on BIRD shutdown
debug off;
scan time 20; # Scan kernel routing table every 20 seconds
ipv4{
export all; # Default is export none
};
}
protocol kernel kernel6 {
scan time 20;
debug off;
ipv6 {
export all;
};
}
protocol device {
scan time 10; # Scan interfaces every 10 seconds
debug off;
}
protocol static static4 {
ipv4;
route B.B.0.0/16 via C.C.C.C;
}
template bgp rr_client {
local A.A.A.A as 65000;
passive on;
multihop;
rr client;
rr cluster id 500;
ipv4 {
# connects to master4 table by default
import all;
#export where source ~ [ RTS_STATIC, RTS_BGP ];
};
vpn4 mpls {
# connects to vpntab4 table by default
import all;
export all;
};
vpn6 mpls {
# connects to vpntab6 table by default
import all;
export all;
};
}
protocol bgp rrcli1 from rr_client {
neighbor D.D.D.D as 65000;
}
protocol bgp rrcli2 from rr_client {
neighbor E.E.E.E as 65000;
}
protocol bgp rrcli3 from rr_client {
neighbor F.F.F.F as 65000;
}
Did I missed something ?
Thanks
Gilles Friang
