vrf configuration with same addresses
Hi All, Tried to configure vrf with same own and peer addresses as in global. When I ping in vrf, packets go in and out via correct interfaces, but bird bgp sessions are constantly flapping. Only one session to peer with same address exists at each moment As a w/a tried to configure interface per session, but this did not helped. Here is my partial configuration: protocol device { scan time 2; # Scan interfaces every 2 seconds } protocol direct { interface "br*"; # bridge interfaces interface "swp*"; # router ports interface "bond*"; # Disable by default ipv4; # Connect to default IPv4 table ipv6; # ... and to default IPv6 table } protocol kernel { ipv4 { # Connect protocol to IPv4 table by channel table master4; # Default IPv4 table is master4 import none; # Import to table, default is import all export all; # Export to protocol. default is export none }; learn on; # Learn alien routes from the kernel merge paths yes; } protocol bgp bgp3411 { local as 65001; bfd yes; neighbor 191.34.1.3 as 65034; # interface "swp2"; ipv4 { import all; export all; }; } protocol bgp bgp3412 { local as 65001; bfd yes; neighbor 192.34.1.3 as 65034; # interface "swp1"; ipv4 { import all; export all; }; } ipv4 table table_vrf01; protocol kernel kernel_vrf01 { vrf "vrf01"; kernel table 101; scan time 2; ipv4 { table table_vrf01; import none; # Default is import all export all; # Default is export none }; merge paths yes; learn on; # Learn all alien routes from the kernel } protocol direct direct_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; interface "swp7.101"; interface "swp1.201"; interface "swp2.301"; interface "vrf01"; } protocol static static_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; } protocol bgp bgp_vrf01_n1 { vrf "vrf01"; local as 65001; graceful restart; neighbor 191.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; } protocol bgp bgp_vrf01_n2 { vrf "vrf01"; local as 65001; graceful restart; neighbor 192.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; } ip -br link show type vrf vrf01 UP fe:58:94:d2:d8:ee <NOARP,MASTER,UP,LOWER_UP> vrf02 UP 42:2d:8f:bd:87:9f <NOARP,MASTER,UP,LOWER_UP> (mlnx)root@bdg-crf-01:~# ip route show vrf vrf01 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload (mlnx)root@bdg-crf-01:~# ip route show table 101 broadcast 172.1.7.0 dev swp7.101 proto kernel scope link src 172.1.7.1 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload local 172.1.7.1 dev swp7.101 proto kernel scope host src 172.1.7.1 broadcast 172.1.7.255 dev swp7.101 proto kernel scope link src 172.1.7.1 local 191.34.1.2 dev swp2.301 proto kernel scope host src 191.34.1.2 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload local 192.34.1.2 dev swp1.201 proto kernel scope host src 192.34.1.2 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload -- Semion Lisyansky
Hi, What version of bird you are using? There was a path for BGP & VRF applied just recently: https://gitlab.labs.nic.cz/labs/bird/commit/e19d08055a4614f03e51ee72617be109... On Sun, Nov 4, 2018 at 5:01 PM, Semion Lisyansky <semionl@gmail.com> wrote:
Hi All,
Tried to configure vrf with same own and peer addresses as in global. When I ping in vrf, packets go in and out via correct interfaces, but bird bgp sessions are constantly flapping. Only one session to peer with same address exists at each moment As a w/a tried to configure interface per session, but this did not helped.
Here is my partial configuration:
protocol device { scan time 2; # Scan interfaces every 2 seconds } protocol direct { interface "br*"; # bridge interfaces interface "swp*"; # router ports interface "bond*"; # Disable by default ipv4; # Connect to default IPv4 table ipv6; # ... and to default IPv6 table }
protocol kernel { ipv4 { # Connect protocol to IPv4 table by channel table master4; # Default IPv4 table is master4 import none; # Import to table, default is import all export all; # Export to protocol. default is export none }; learn on; # Learn alien routes from the kernel merge paths yes; }
protocol bgp bgp3411 { local as 65001; bfd yes; neighbor 191.34.1.3 as 65034; # interface "swp2"; ipv4 { import all; export all; }; }
protocol bgp bgp3412 { local as 65001; bfd yes; neighbor 192.34.1.3 as 65034; # interface "swp1"; ipv4 { import all; export all; }; }
ipv4 table table_vrf01;
protocol kernel kernel_vrf01 { vrf "vrf01"; kernel table 101; scan time 2; ipv4 { table table_vrf01; import none; # Default is import all export all; # Default is export none }; merge paths yes; learn on; # Learn all alien routes from the kernel }
protocol direct direct_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; interface "swp7.101"; interface "swp1.201"; interface "swp2.301"; interface "vrf01"; }
protocol static static_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; }
protocol bgp bgp_vrf01_n1 { vrf "vrf01"; local as 65001; graceful restart; neighbor 191.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; }
protocol bgp bgp_vrf01_n2 { vrf "vrf01"; local as 65001; graceful restart; neighbor 192.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; }
ip -br link show type vrf vrf01 UP fe:58:94:d2:d8:ee <NOARP,MASTER,UP,LOWER_UP> vrf02 UP 42:2d:8f:bd:87:9f <NOARP,MASTER,UP,LOWER_UP> (mlnx)root@bdg-crf-01:~# ip route show vrf vrf01 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload (mlnx)root@bdg-crf-01:~# ip route show table 101 broadcast 172.1.7.0 dev swp7.101 proto kernel scope link src 172.1.7.1 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload local 172.1.7.1 dev swp7.101 proto kernel scope host src 172.1.7.1 broadcast 172.1.7.255 dev swp7.101 proto kernel scope link src 172.1.7.1 local 191.34.1.2 dev swp2.301 proto kernel scope host src 191.34.1.2 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload local 192.34.1.2 dev swp1.201 proto kernel scope host src 192.34.1.2 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload
-- Semion Lisyansky
Thanks, Alexander Using bird 2.0.2. Guess it does not include patch you mentioned Have another question: Configured peers in vrf with different addresses but still in overlapping subnets. BGP session are established and some prefixes advertised. The issue is that bird/bgp tries to resolve nexthops for all vrfs only in default. ip -4 neigh show vrf vrf01 190.34.32.101 dev swp32.101 lladdr 00:00:80:8f:c3:1a REACHABLE ip -4 neigh show 190.34.32.101 dev swp32 INCOMPLETE ip route show vrf vrf01 134.0.0.0/24 via 190.34.32.101 dev swp32 proto bird metric 32 .-- Semion Lisyansky On Sun, Nov 4, 2018 at 8:11 PM Alexander Zubkov <green@qrator.net> wrote:
Hi,
What version of bird you are using? There was a path for BGP & VRF applied just recently:
https://gitlab.labs.nic.cz/labs/bird/commit/e19d08055a4614f03e51ee72617be109...
On Sun, Nov 4, 2018 at 5:01 PM, Semion Lisyansky <semionl@gmail.com> wrote:
Hi All,
Tried to configure vrf with same own and peer addresses as in global. When I ping in vrf, packets go in and out via correct interfaces, but bird bgp sessions are constantly flapping. Only one session to peer with same address exists at each moment As a w/a tried to configure interface per session, but this did not helped.
Here is my partial configuration:
protocol device { scan time 2; # Scan interfaces every 2 seconds } protocol direct { interface "br*"; # bridge interfaces interface "swp*"; # router ports interface "bond*"; # Disable by default ipv4; # Connect to default IPv4 table ipv6; # ... and to default IPv6 table }
protocol kernel { ipv4 { # Connect protocol to IPv4 table by channel table master4; # Default IPv4 table is master4 import none; # Import to table, default is import all export all; # Export to protocol. default is export none }; learn on; # Learn alien routes from the kernel merge paths yes; }
protocol bgp bgp3411 { local as 65001; bfd yes; neighbor 191.34.1.3 as 65034; # interface "swp2"; ipv4 { import all; export all; }; }
protocol bgp bgp3412 { local as 65001; bfd yes; neighbor 192.34.1.3 as 65034; # interface "swp1"; ipv4 { import all; export all; }; }
ipv4 table table_vrf01;
protocol kernel kernel_vrf01 { vrf "vrf01"; kernel table 101; scan time 2; ipv4 { table table_vrf01; import none; # Default is import all export all; # Default is export none }; merge paths yes; learn on; # Learn all alien routes from the kernel }
protocol direct direct_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; interface "swp7.101"; interface "swp1.201"; interface "swp2.301"; interface "vrf01"; }
protocol static static_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; }
protocol bgp bgp_vrf01_n1 { vrf "vrf01"; local as 65001; graceful restart; neighbor 191.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; }
protocol bgp bgp_vrf01_n2 { vrf "vrf01"; local as 65001; graceful restart; neighbor 192.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; }
ip -br link show type vrf vrf01 UP fe:58:94:d2:d8:ee <NOARP,MASTER,UP,LOWER_UP> vrf02 UP 42:2d:8f:bd:87:9f <NOARP,MASTER,UP,LOWER_UP> (mlnx)root@bdg-crf-01:~# ip route show vrf vrf01 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload (mlnx)root@bdg-crf-01:~# ip route show table 101 broadcast 172.1.7.0 dev swp7.101 proto kernel scope link src 172.1.7.1 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload local 172.1.7.1 dev swp7.101 proto kernel scope host src 172.1.7.1 broadcast 172.1.7.255 dev swp7.101 proto kernel scope link src 172.1.7.1 local 191.34.1.2 dev swp2.301 proto kernel scope host src 191.34.1.2 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload local 192.34.1.2 dev swp1.201 proto kernel scope host src 192.34.1.2 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload
-- Semion Lisyansky
Using bird 2.0.2. Guess it does not include patch you mentioned
Yes, it is not released yet.
The issue is that bird/bgp tries to resolve nexthops for all vrfs only in default.
I think it depends on your configuration. Do you have separate tables for protocols in different vrfs? On Mon, Nov 5, 2018 at 9:42 AM, Semion Lisyansky <semionl@gmail.com> wrote:
Thanks, Alexander
Using bird 2.0.2. Guess it does not include patch you mentioned
Have another question: Configured peers in vrf with different addresses but still in overlapping subnets. BGP session are established and some prefixes advertised. The issue is that bird/bgp tries to resolve nexthops for all vrfs only in default.
ip -4 neigh show vrf vrf01 190.34.32.101 dev swp32.101 lladdr 00:00:80:8f:c3:1a REACHABLE
ip -4 neigh show 190.34.32.101 dev swp32 INCOMPLETE
ip route show vrf vrf01 134.0.0.0/24 via 190.34.32.101 dev swp32 proto bird metric 32
.-- Semion Lisyansky
On Sun, Nov 4, 2018 at 8:11 PM Alexander Zubkov <green@qrator.net> wrote:
Hi,
What version of bird you are using? There was a path for BGP & VRF applied just recently: https://gitlab.labs.nic.cz/labs/bird/commit/ e19d08055a4614f03e51ee72617be10946ce7919
On Sun, Nov 4, 2018 at 5:01 PM, Semion Lisyansky <semionl@gmail.com> wrote:
Hi All,
Tried to configure vrf with same own and peer addresses as in global. When I ping in vrf, packets go in and out via correct interfaces, but bird bgp sessions are constantly flapping. Only one session to peer with same address exists at each moment As a w/a tried to configure interface per session, but this did not helped.
Here is my partial configuration:
protocol device { scan time 2; # Scan interfaces every 2 seconds } protocol direct { interface "br*"; # bridge interfaces interface "swp*"; # router ports interface "bond*"; # Disable by default ipv4; # Connect to default IPv4 table ipv6; # ... and to default IPv6 table }
protocol kernel { ipv4 { # Connect protocol to IPv4 table by channel table master4; # Default IPv4 table is master4 import none; # Import to table, default is import all export all; # Export to protocol. default is export none }; learn on; # Learn alien routes from the kernel merge paths yes; }
protocol bgp bgp3411 { local as 65001; bfd yes; neighbor 191.34.1.3 as 65034; # interface "swp2"; ipv4 { import all; export all; }; }
protocol bgp bgp3412 { local as 65001; bfd yes; neighbor 192.34.1.3 as 65034; # interface "swp1"; ipv4 { import all; export all; }; }
ipv4 table table_vrf01;
protocol kernel kernel_vrf01 { vrf "vrf01"; kernel table 101; scan time 2; ipv4 { table table_vrf01; import none; # Default is import all export all; # Default is export none }; merge paths yes; learn on; # Learn all alien routes from the kernel }
protocol direct direct_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; interface "swp7.101"; interface "swp1.201"; interface "swp2.301"; interface "vrf01"; }
protocol static static_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; }
protocol bgp bgp_vrf01_n1 { vrf "vrf01"; local as 65001; graceful restart; neighbor 191.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; }
protocol bgp bgp_vrf01_n2 { vrf "vrf01"; local as 65001; graceful restart; neighbor 192.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; }
ip -br link show type vrf vrf01 UP fe:58:94:d2:d8:ee <NOARP,MASTER,UP,LOWER_UP> vrf02 UP 42:2d:8f:bd:87:9f <NOARP,MASTER,UP,LOWER_UP> (mlnx)root@bdg-crf-01:~# ip route show vrf vrf01 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload (mlnx)root@bdg-crf-01:~# ip route show table 101 broadcast 172.1.7.0 dev swp7.101 proto kernel scope link src 172.1.7.1 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload local 172.1.7.1 dev swp7.101 proto kernel scope host src 172.1.7.1 broadcast 172.1.7.255 dev swp7.101 proto kernel scope link src 172.1.7.1 local 191.34.1.2 dev swp2.301 proto kernel scope host src 191.34.1.2 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload local 192.34.1.2 dev swp1.201 proto kernel scope host src 192.34.1.2 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload
-- Semion Lisyansky
Yes, I have separate tables for each vrf -- Semion Lisyansky On Mon, Nov 5, 2018 at 10:48 AM Alexander Zubkov <green@qrator.net> wrote:
Using bird 2.0.2. Guess it does not include patch you mentioned
Yes, it is not released yet.
The issue is that bird/bgp tries to resolve nexthops for all vrfs only in default.
I think it depends on your configuration. Do you have separate tables for protocols in different vrfs?
On Mon, Nov 5, 2018 at 9:42 AM, Semion Lisyansky <semionl@gmail.com> wrote:
Thanks, Alexander
Using bird 2.0.2. Guess it does not include patch you mentioned
Have another question: Configured peers in vrf with different addresses but still in overlapping subnets. BGP session are established and some prefixes advertised. The issue is that bird/bgp tries to resolve nexthops for all vrfs only in default.
ip -4 neigh show vrf vrf01 190.34.32.101 dev swp32.101 lladdr 00:00:80:8f:c3:1a REACHABLE
ip -4 neigh show 190.34.32.101 dev swp32 INCOMPLETE
ip route show vrf vrf01 134.0.0.0/24 via 190.34.32.101 dev swp32 proto bird metric 32
.-- Semion Lisyansky
On Sun, Nov 4, 2018 at 8:11 PM Alexander Zubkov <green@qrator.net> wrote:
Hi,
What version of bird you are using? There was a path for BGP & VRF applied just recently:
https://gitlab.labs.nic.cz/labs/bird/commit/e19d08055a4614f03e51ee72617be109...
On Sun, Nov 4, 2018 at 5:01 PM, Semion Lisyansky <semionl@gmail.com> wrote:
Hi All,
Tried to configure vrf with same own and peer addresses as in global. When I ping in vrf, packets go in and out via correct interfaces, but bird bgp sessions are constantly flapping. Only one session to peer with same address exists at each moment As a w/a tried to configure interface per session, but this did not helped.
Here is my partial configuration:
protocol device { scan time 2; # Scan interfaces every 2 seconds } protocol direct { interface "br*"; # bridge interfaces interface "swp*"; # router ports interface "bond*"; # Disable by default ipv4; # Connect to default IPv4 table ipv6; # ... and to default IPv6 table }
protocol kernel { ipv4 { # Connect protocol to IPv4 table by channel table master4; # Default IPv4 table is master4 import none; # Import to table, default is import all export all; # Export to protocol. default is export none }; learn on; # Learn alien routes from the kernel merge paths yes; }
protocol bgp bgp3411 { local as 65001; bfd yes; neighbor 191.34.1.3 as 65034; # interface "swp2"; ipv4 { import all; export all; }; }
protocol bgp bgp3412 { local as 65001; bfd yes; neighbor 192.34.1.3 as 65034; # interface "swp1"; ipv4 { import all; export all; }; }
ipv4 table table_vrf01;
protocol kernel kernel_vrf01 { vrf "vrf01"; kernel table 101; scan time 2; ipv4 { table table_vrf01; import none; # Default is import all export all; # Default is export none }; merge paths yes; learn on; # Learn all alien routes from the kernel }
protocol direct direct_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; interface "swp7.101"; interface "swp1.201"; interface "swp2.301"; interface "vrf01"; }
protocol static static_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; }
protocol bgp bgp_vrf01_n1 { vrf "vrf01"; local as 65001; graceful restart; neighbor 191.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; }
protocol bgp bgp_vrf01_n2 { vrf "vrf01"; local as 65001; graceful restart; neighbor 192.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; }
ip -br link show type vrf vrf01 UP fe:58:94:d2:d8:ee <NOARP,MASTER,UP,LOWER_UP> vrf02 UP 42:2d:8f:bd:87:9f <NOARP,MASTER,UP,LOWER_UP> (mlnx)root@bdg-crf-01:~# ip route show vrf vrf01 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload (mlnx)root@bdg-crf-01:~# ip route show table 101 broadcast 172.1.7.0 dev swp7.101 proto kernel scope link src 172.1.7.1 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload local 172.1.7.1 dev swp7.101 proto kernel scope host src 172.1.7.1 broadcast 172.1.7.255 dev swp7.101 proto kernel scope link src 172.1.7.1 local 191.34.1.2 dev swp2.301 proto kernel scope host src 191.34.1.2 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload local 192.34.1.2 dev swp1.201 proto kernel scope host src 192.34.1.2 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload
-- Semion Lisyansky
May be you have direct routes from different vrf somehow in this table? On Mon, Nov 5, 2018 at 9:54 AM, Semion Lisyansky <semionl@gmail.com> wrote:
Yes, I have separate tables for each vrf
-- Semion Lisyansky
On Mon, Nov 5, 2018 at 10:48 AM Alexander Zubkov <green@qrator.net> wrote:
Using bird 2.0.2. Guess it does not include patch you mentioned
Yes, it is not released yet.
The issue is that bird/bgp tries to resolve nexthops for all vrfs only in default.
I think it depends on your configuration. Do you have separate tables for protocols in different vrfs?
On Mon, Nov 5, 2018 at 9:42 AM, Semion Lisyansky <semionl@gmail.com> wrote:
Thanks, Alexander
Using bird 2.0.2. Guess it does not include patch you mentioned
Have another question: Configured peers in vrf with different addresses but still in overlapping subnets. BGP session are established and some prefixes advertised. The issue is that bird/bgp tries to resolve nexthops for all vrfs only in default.
ip -4 neigh show vrf vrf01 190.34.32.101 dev swp32.101 lladdr 00:00:80:8f:c3:1a REACHABLE
ip -4 neigh show 190.34.32.101 dev swp32 INCOMPLETE
ip route show vrf vrf01 134.0.0.0/24 via 190.34.32.101 dev swp32 proto bird metric 32
.-- Semion Lisyansky
On Sun, Nov 4, 2018 at 8:11 PM Alexander Zubkov <green@qrator.net> wrote:
Hi,
What version of bird you are using? There was a path for BGP & VRF applied just recently: https://gitlab.labs.nic.cz/labs/bird/commit/ e19d08055a4614f03e51ee72617be10946ce7919
On Sun, Nov 4, 2018 at 5:01 PM, Semion Lisyansky <semionl@gmail.com> wrote:
Hi All,
Tried to configure vrf with same own and peer addresses as in global. When I ping in vrf, packets go in and out via correct interfaces, but bird bgp sessions are constantly flapping. Only one session to peer with same address exists at each moment As a w/a tried to configure interface per session, but this did not helped.
Here is my partial configuration:
protocol device { scan time 2; # Scan interfaces every 2 seconds } protocol direct { interface "br*"; # bridge interfaces interface "swp*"; # router ports interface "bond*"; # Disable by default ipv4; # Connect to default IPv4 table ipv6; # ... and to default IPv6 table }
protocol kernel { ipv4 { # Connect protocol to IPv4 table by channel table master4; # Default IPv4 table is master4 import none; # Import to table, default is import all export all; # Export to protocol. default is export none }; learn on; # Learn alien routes from the kernel merge paths yes; }
protocol bgp bgp3411 { local as 65001; bfd yes; neighbor 191.34.1.3 as 65034; # interface "swp2"; ipv4 { import all; export all; }; }
protocol bgp bgp3412 { local as 65001; bfd yes; neighbor 192.34.1.3 as 65034; # interface "swp1"; ipv4 { import all; export all; }; }
ipv4 table table_vrf01;
protocol kernel kernel_vrf01 { vrf "vrf01"; kernel table 101; scan time 2; ipv4 { table table_vrf01; import none; # Default is import all export all; # Default is export none }; merge paths yes; learn on; # Learn all alien routes from the kernel }
protocol direct direct_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; interface "swp7.101"; interface "swp1.201"; interface "swp2.301"; interface "vrf01"; }
protocol static static_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; }
protocol bgp bgp_vrf01_n1 { vrf "vrf01"; local as 65001; graceful restart; neighbor 191.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; }
protocol bgp bgp_vrf01_n2 { vrf "vrf01"; local as 65001; graceful restart; neighbor 192.34.1.3 as 65034; ipv4 { table table_vrf01; import none; export none; }; }
ip -br link show type vrf vrf01 UP fe:58:94:d2:d8:ee <NOARP,MASTER,UP,LOWER_UP> vrf02 UP 42:2d:8f:bd:87:9f <NOARP,MASTER,UP,LOWER_UP> (mlnx)root@bdg-crf-01:~# ip route show vrf vrf01 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload (mlnx)root@bdg-crf-01:~# ip route show table 101 broadcast 172.1.7.0 dev swp7.101 proto kernel scope link src 172.1.7.1 172.1.7.0/24 dev swp7.101 proto kernel scope link src 172.1.7.1 offload local 172.1.7.1 dev swp7.101 proto kernel scope host src 172.1.7.1 broadcast 172.1.7.255 dev swp7.101 proto kernel scope link src 172.1.7.1 local 191.34.1.2 dev swp2.301 proto kernel scope host src 191.34.1.2 191.34.1.2/31 dev swp2.301 proto kernel scope link src 191.34.1.2 offload local 192.34.1.2 dev swp1.201 proto kernel scope host src 192.34.1.2 192.34.1.2/31 dev swp1.201 proto kernel scope link src 192.34.1.2 offload
-- Semion Lisyansky
On Mon, Nov 05, 2018 at 10:42:27AM +0200, Semion Lisyansky wrote:
Thanks, Alexander
Using bird 2.0.2. Guess it does not include patch you mentioned
Have another question: Configured peers in vrf with different addresses but still in overlapping subnets. BGP session are established and some prefixes advertised. The issue is that bird/bgp tries to resolve nexthops for all vrfs only in default.
Hi This should work in 2.0.2, the routes are supposed to be resolved by default in the same table to which the BGP protocol is connected, in your case table_vrf01. Could you send output of BIRD commands: show interfaces show protocols all show route show route table table_vrf01 ? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Hi, Please find below requested info. Some omitted because of size You may clearly see the issue on 1st show bird> show route table table_vrf01 Table table_vrf01: 192.34.1.2/31 unicast [direct_vrf01 15:43:55.271] * (240) dev swp17.201 191.34.1.2/31 unicast [direct_vrf01 15:43:55.271] * (240) dev swp18.301 190.34.32.0/24 unicast [direct_vrf01 15:43:55.271] * (240) dev swp32.101 134.0.0.0/24 unicast [bgp_vrf01_ixia1 15:44:26.288] * (100) [AS65134i] via 190.34.32.101 on swp32 134.1.0.0/24 unicast [bgp_vrf01_ixia1 15:44:26.288] * (100) [AS65134i] via 190.34.32.101 on swp32 bird> bird> show route table table_vrf02 Table table_vrf02: 192.34.1.2/31 unicast [direct_vrf02 15:43:55.271] * (240) dev swp17.202 191.34.1.2/31 unicast [direct_vrf02 15:43:55.271] * (240) dev swp18.302 190.34.32.0/24 unicast [direct_vrf02 15:43:55.271] * (240) dev swp32.102 134.0.0.0/24 unicast [bgp_vrf02_ixia1 15:44:31.250] * (100) [AS65134i] via 190.34.32.102 on swp32 134.1.0.0/24 unicast [bgp_vrf02_ixia1 15:44:31.250] * (100) [AS65134i] via 190.34.32.102 on swp32 bird> bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 127.0.0.1/8 (Preferred, scope host) ::1/128 (Preferred, scope host) ... swp32 up (index=24) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 190.34.32.254/24 (Preferred, scope univ) fe80::ee0d:9aff:fe5d:f1df/64 (Preferred, scope link) ... swp7 up (index=33) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 190.12.34.2/31 (Preferred, opposite 190.12.34.3, scope univ) fe80::ee0d:9aff:fe5d:f1f1/64 (Preferred, scope link) swp8 up (index=34) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::ee0d:9aff:fe5d:f1f3/64 (Preferred, scope link) swp5 up (index=35) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 190.11.34.2/31 (Preferred, opposite 190.11.34.3, scope univ) fe80::ee0d:9aff:fe5d:f1f5/64 (Preferred, scope link) swp6 up (index=36) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::ee0d:9aff:fe5d:f1f7/64 (Preferred, scope link) swp3 up (index=37) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 190.2.34.2/31 (Preferred, opposite 190.2.34.3, scope univ) fe80::ee0d:9aff:fe5d:f1f9/64 (Preferred, scope link) swp4 up (index=38) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::ee0d:9aff:fe5d:f1fb/64 (Preferred, scope link) swp1 up (index=39) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 190.1.34.2/31 (Preferred, opposite 190.1.34.3, scope univ) fe80::ee0d:9aff:fe5d:f1fd/64 (Preferred, scope link) swp2 up (index=40) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::ee0d:9aff:fe5d:f1ff/64 (Preferred, scope link) vrf01 up (index=41) MultiAccess AdminUp LinkUp MTU=65536 vrf02 up (index=42) MultiAccess AdminUp LinkUp MTU=65536 swp32.101 up (index=43 master=vrf01) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 190.34.32.254/24 (Preferred, scope univ) fe80::ee0d:9aff:fe5d:f1df/64 (Preferred, scope link) swp32.102 up (index=44 master=vrf02) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 190.34.32.254/24 (Preferred, scope univ) fe80::ee0d:9aff:fe5d:f1df/64 (Preferred, scope link) swp17.201 up (index=45 master=vrf01) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 192.34.1.3/31 (Preferred, opposite 192.34.1.2, scope univ) fe80::ee0d:9aff:fe5d:f1c1/64 (Preferred, scope link) swp17.202 up (index=46 master=vrf02) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 192.34.1.3/31 (Preferred, opposite 192.34.1.2, scope univ) fe80::ee0d:9aff:fe5d:f1c1/64 (Preferred, scope link) swp18.301 up (index=47 master=vrf01) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 191.34.1.3/31 (Preferred, opposite 191.34.1.2, scope univ) fe80::ee0d:9aff:fe5d:f1c3/64 (Preferred, scope link) swp18.302 up (index=48 master=vrf02) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 191.34.1.3/31 (Preferred, opposite 191.34.1.2, scope univ) fe80::ee0d:9aff:fe5d:f1c3/64 (Preferred, scope link) bird> show protocols all Name Proto Table State Since Info device1 Device --- up 15:43:55.266 direct1 Direct --- up 15:43:55.266 Channel ipv4 State: UP Table: master4 Preference: 240 Input filter: ACCEPT Output filter: REJECT Routes: 15 imported, 0 exported Route change stats: received rejected filtered ignored accepted Import updates: 15 0 0 0 15 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 Channel ipv6 State: UP Table: master6 Preference: 240 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 kernel1 Kernel master4 up 15:43:55.266 Channel ipv4 State: UP Table: master4 Preference: 10 Input filter: REJECT Output filter: ACCEPT Routes: 0 imported, 45 exported Route change stats: received rejected filtered ignored accepted Import updates: 1 0 1 0 0 Import withdraws: 0 0 --- 1 0 Export updates: 1245 0 0 --- 1245 Export withdraws: 293 --- --- --- 293 kernel2 Kernel master6 up 15:43:55.266 Channel ipv6 State: UP Table: master6 Preference: 10 Input filter: ACCEPT Output filter: ACCEPT Routes: 0 imported, 0 exported Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 static1 Static master4 up 15:43:55.266 Channel ipv4 State: UP Table: master4 Preference: 200 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 bfd1 BFD --- up 15:43:55.266 ... ixia16 BGP --- up 15:44:00.013 Established BGP state: Established Neighbor address: 190.34.32.16 Neighbor AS: 65134 Neighbor ID: 190.34.32.16 Local capabilities Multiprotocol AF announced: ipv4 Route refresh Graceful restart Restart time: 120 AF supported: ipv4 AF preserved: 4-octet AS numbers Enhanced refresh Neighbor capabilities Multiprotocol AF announced: ipv4 ipv6 Route refresh Graceful restart Restart time: 45 AF supported: ipv4 ipv6 AF preserved: ipv4 ipv6 4-octet AS numbers Session: external AS4 Source address: 190.34.32.254 Hold timer: 7.076/9 Keepalive timer: 1.985/3 Channel ipv4 State: UP Table: master4 Preference: 100 Input filter: ACCEPT Output filter: ACCEPT Routes: 0 imported, 36 exported Route change stats: received rejected filtered ignored accepted Import updates: 2 0 0 0 2 Import withdraws: 2 0 --- 0 2 Export updates: 698 2 0 --- 696 Export withdraws: 293 --- --- --- 291 BGP Next hop: 190.34.32.254 kernel_vrf01 Kernel table_vrf01 up 15:43:55.266 VRF: vrf01 Channel ipv4 State: UP Table: table_vrf01 Preference: 10 Input filter: REJECT Output filter: ACCEPT Routes: 0 imported, 5 exported Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 5 0 0 --- 5 Export withdraws: 0 --- --- --- 0 direct_vrf01 Direct --- up 15:43:55.266 VRF: vrf01 Channel ipv4 State: UP Table: table_vrf01 Preference: 240 Input filter: ACCEPT Output filter: REJECT Routes: 3 imported, 0 exported Route change stats: received rejected filtered ignored accepted Import updates: 3 0 0 0 3 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 static_vrf01 Static table_vrf01 up 15:43:55.266 VRF: vrf01 Channel ipv4 State: UP Table: table_vrf01 Preference: 200 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 bgp_vrf01_n1 BGP --- start 15:43:55.266 Idle VRF: vrf01 BGP state: Idle Neighbor address: 191.34.1.4 Neighbor AS: 65001 Channel ipv4 State: DOWN Table: table_vrf01 Preference: 100 Input filter: ACCEPT Output filter: (unnamed) bgp_vrf01_n2 BGP --- start 15:43:55.266 Idle VRF: vrf01 BGP state: Idle Neighbor address: 192.34.1.4 Neighbor AS: 65001 Channel ipv4 State: DOWN Table: table_vrf01 Preference: 100 Input filter: ACCEPT Output filter: (unnamed) bgp_vrf01_ixia1 BGP --- up 15:44:26.249 Established BGP state: Established Neighbor address: 190.34.32.101 Neighbor AS: 65134 Neighbor ID: 190.34.32.101 Local capabilities Multiprotocol AF announced: ipv4 Route refresh Graceful restart Restart time: 120 AF supported: ipv4 AF preserved: 4-octet AS numbers Enhanced refresh Neighbor capabilities Multiprotocol AF announced: ipv4 ipv6 Route refresh Graceful restart Restart time: 45 AF supported: ipv4 ipv6 AF preserved: ipv4 ipv6 4-octet AS numbers Session: external AS4 Source address: 190.34.32.254 Hold timer: 7.266/9 Keepalive timer: 2.310/3 Channel ipv4 State: UP Table: table_vrf01 Preference: 100 Input filter: ACCEPT Output filter: ACCEPT Routes: 2 imported, 3 exported Route change stats: received rejected filtered ignored accepted Import updates: 2 0 0 0 2 Import withdraws: 0 0 --- 0 0 Export updates: 5 2 0 --- 3 Export withdraws: 0 --- --- --- 0 BGP Next hop: 190.34.32.254 kernel_vrf02 Kernel table_vrf02 up 15:43:55.266 VRF: vrf02 Channel ipv4 State: UP Table: table_vrf02 Preference: 10 Input filter: REJECT Output filter: ACCEPT Routes: 0 imported, 5 exported Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 5 0 0 --- 5 Export withdraws: 0 --- --- --- 0 direct_vrf02 Direct --- up 15:43:55.266 VRF: vrf02 Channel ipv4 State: UP Table: table_vrf02 Preference: 240 Input filter: ACCEPT Output filter: REJECT Routes: 3 imported, 0 exported Route change stats: received rejected filtered ignored accepted Import updates: 3 0 0 0 3 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 static_vrf02 Static table_vrf02 up 15:43:55.266 VRF: vrf02 Channel ipv4 State: UP Table: table_vrf02 Preference: 200 Input filter: ACCEPT Output filter: REJECT Routes: 0 imported, 0 exported Route change stats: received rejected filtered ignored accepted Import updates: 0 0 0 0 0 Import withdraws: 0 0 --- 0 0 Export updates: 0 0 0 --- 0 Export withdraws: 0 --- --- --- 0 bgp_vrf02_n1 BGP --- start 15:43:55.266 Idle VRF: vrf02 BGP state: Idle Neighbor address: 191.34.1.6 Neighbor AS: 65001 Channel ipv4 State: DOWN Table: table_vrf02 Preference: 100 Input filter: ACCEPT Output filter: (unnamed) bgp_vrf02_n2 BGP --- start 15:43:55.266 Idle VRF: vrf02 BGP state: Idle Neighbor address: 192.34.1.6 Neighbor AS: 65001 Channel ipv4 State: DOWN Table: table_vrf02 Preference: 100 Input filter: ACCEPT Output filter: (unnamed) bgp_vrf02_ixia1 BGP --- up 15:44:31.250 Established BGP state: Established Neighbor address: 190.34.32.102 Neighbor AS: 65134 Neighbor ID: 190.34.32.102 Local capabilities Multiprotocol AF announced: ipv4 Route refresh Graceful restart Restart time: 120 AF supported: ipv4 AF preserved: 4-octet AS numbers Enhanced refresh Neighbor capabilities Multiprotocol AF announced: ipv4 ipv6 Route refresh Graceful restart Restart time: 45 AF supported: ipv4 ipv6 AF preserved: ipv4 ipv6 4-octet AS numbers Session: external AS4 Source address: 190.34.32.254 Hold timer: 6.307/9 Keepalive timer: 2.470/3 Channel ipv4 State: UP Table: table_vrf02 Preference: 100 Input filter: ACCEPT Output filter: ACCEPT Routes: 2 imported, 3 exported Route change stats: received rejected filtered ignored accepted Import updates: 2 0 0 0 2 Import withdraws: 0 0 --- 0 0 Export updates: 5 2 0 --- 3 Export withdraws: 0 --- --- --- 0 BGP Next hop: 190.34.32.254 bird> No such command. Press `?' for help. bird> show route Table master4: 190.12.34.2/31 unicast [direct1 15:43:55.271] * (240) dev swp7 190.12.35.2/31 unicast [bgp3421 15:49:46.366] * (100) [AS65035i] via 191.34.2.2 on swp19 unicast [bgp3422 15:49:46.366] (100) [AS65035i] via 192.34.2.2 on swp20 190.11.34.2/31 unicast [direct1 15:43:55.271] * (240) dev swp5 190.11.35.2/31 unicast [bgp3421 15:49:46.366] * (100) [AS65035i] via 191.34.2.2 on swp19 unicast [bgp3422 15:49:46.366] (100) [AS65035i] via 192.34.2.2 on swp20 192.35.1.2/31 unicast [bgp3421 15:49:46.366] * (100) [AS65035i] via 191.34.2.2 on swp19 unicast [bgp3422 15:49:46.366] (100) [AS65035i] via 192.34.2.2 on swp20 192.35.2.2/31 unicast [bgp3421 15:44:51.377] * (100) [AS65002i] via 191.34.2.2 on swp19 unicast [bgp3422 15:43:59.441] (100) [AS65002i] via 192.34.2.2 on swp20 192.34.1.2/31 unicast [direct1 15:43:55.271] * (240) dev swp17 unicast [direct1 15:43:55.271] (240) dev swp17.202 unicast [direct1 15:43:55.271] (240) dev swp17.201 192.34.2.2/31 unicast [direct1 15:43:55.271] * (240) dev swp20 unicast [bgp3421 15:44:51.377] (100) [AS65002i] via 191.34.2.2 on swp19 unicast [bgp3422 15:43:59.441] (100) [AS65002i] via 192.34.2.2 on swp20 191.34.2.2/31 unicast [direct1 15:43:55.271] * (240) dev swp19 unicast [bgp3421 15:44:51.377] (100) [AS65002i] via 191.34.2.2 on swp19 unicast [bgp3422 15:43:59.441] (100) [AS65002i] via 192.34.2.2 on swp20 134.0.0.0/17 unicast [ixia1 15:43:59.877] * (100) [AS65134i] via 190.34.32.1 on swp32 134.1.0.0/21 unicast [ixia5 15:44:00.490] * (100) [AS65134i] via 190.34.32.5 on swp32 191.34.1.2/31 unicast [direct1 15:43:55.271] * (240) dev swp18 unicast [direct1 15:43:55.271] (240) dev swp18.302 unicast [direct1 15:43:55.271] (240) dev swp18.301 134.0.0.0/16 unicast [ixia1 15:43:59.877] * (100) [AS65134i] via 190.34.32.1 on swp32 134.1.0.0/20 unicast [ixia4 15:43:59.051] * (100) [AS65134i] via 190.34.32.4 on swp32 134.0.0.0/19 unicast [ixia3 15:43:59.995] * (100) [AS65134i] via 190.34.32.3 on swp32 134.1.0.0/23 unicast [ixia7 15:45:22.424] * (100) [AS65134i] via 190.34.32.7 on swp32 134.0.0.0/18 unicast [ixia2 15:43:59.057] * (100) [AS65134i] via 190.34.32.2 on swp32 134.1.0.0/22 unicast [ixia6 15:44:01.544] * (100) [AS65134i] via 190.34.32.6 on swp32 191.35.2.2/31 unicast [bgp3421 15:44:51.377] * (100) [AS65002i] via 191.34.2.2 on swp19 unicast [bgp3422 15:43:59.441] (100) [AS65002i] via 192.34.2.2 on swp20 134.0.0.0/21 unicast [ixia5 15:44:00.490] * (100) [AS65134i] via 190.34.32.5 on swp32 134.1.0.0/17 unicast [ixia1 15:43:59.877] * (100) [AS65134i] via 190.34.32.1 on swp32 190.1.34.2/31 unicast [direct1 15:43:55.271] * (240) dev swp1 191.35.1.2/31 unicast [bgp3421 15:49:46.366] * (100) [AS65035i] via 191.34.2.2 on swp19 unicast [bgp3422 15:49:46.366] (100) [AS65035i] via 192.34.2.2 on swp20 190.1.35.2/31 unicast [bgp3421 15:49:46.366] * (100) [AS65035i] via 191.34.2.2 on swp19 unicast [bgp3422 15:49:46.366] (100) [AS65035i] via 192.34.2.2 on swp20 134.0.0.0/20 unicast [ixia4 15:43:59.051] * (100) [AS65134i] via 190.34.32.4 on swp32 134.1.0.0/16 unicast [ixia1 15:43:59.877] * (100) [AS65134i] via 190.34.32.1 on swp32 134.0.0.0/23 unicast [ixia7 15:45:22.424] * (100) [AS65134i] via 190.34.32.7 on swp32 134.1.0.0/19 unicast [ixia3 15:43:59.995] * (100) [AS65134i] via 190.34.32.3 on swp32 190.34.32.0/24 unicast [direct1 15:43:55.271] * (240) dev swp32 unicast [direct1 15:43:55.271] (240) dev swp32.102 unicast [direct1 15:43:55.271] (240) dev swp32.101 134.0.0.0/22 unicast [ixia6 15:44:01.544] * (100) [AS65134i] via 190.34.32.6 on swp32 134.1.0.0/18 unicast [ixia2 15:43:59.057] * (100) [AS65134i] via 190.34.32.2 on swp32 134.0.0.0/25 unicast [ixia9 15:44:00.550] * (100) [AS65134i] via 190.34.32.9 on swp32 190.2.34.2/31 unicast [direct1 15:43:55.271] * (240) dev swp3 190.2.35.2/31 unicast [bgp3421 15:49:46.366] * (100) [AS65035i] via 191.34.2.2 on swp19 unicast [bgp3422 15:49:46.366] (100) [AS65035i] via 192.34.2.2 on swp20 134.0.0.0/24 unicast [ixia8 15:43:59.535] * (100) [AS65134i] via 190.34.32.8 on swp32 172.0.0.0/16 unicast [bgp3421 15:44:51.377] * (100) [AS65002i] via 191.34.2.2 on swp19 unicast [bgp3422 15:43:59.441] (100) [AS65002i] via 192.34.2.2 on swp20 134.0.0.0/26 unicast [ixia10 15:44:00.145] * (100) [AS65134i] via 190.34.32.10 on swp32 134.1.0.0/25 unicast [ixia9 15:44:00.550] * (100) [AS65134i] via 190.34.32.9 on swp32 134.1.0.0/24 unicast [ixia8 15:43:59.535] * (100) [AS65134i] via 190.34.32.8 on swp32 134.1.0.0/26 unicast [ixia10 15:44:00.145] * (100) [AS65134i] via 190.34.32.10 on swp32 bird> bird> show route table table_vrf01 Table table_vrf01: 192.34.1.2/31 unicast [direct_vrf01 15:43:55.271] * (240) dev swp17.201 191.34.1.2/31 unicast [direct_vrf01 15:43:55.271] * (240) dev swp18.301 190.34.32.0/24 unicast [direct_vrf01 15:43:55.271] * (240) dev swp32.101 134.0.0.0/24 unicast [bgp_vrf01_ixia1 15:44:26.288] * (100) [AS65134i] via 190.34.32.101 on swp32 134.1.0.0/24 unicast [bgp_vrf01_ixia1 15:44:26.288] * (100) [AS65134i] via 190.34.32.101 on swp32 bird> -- Semion Lisyansky On Mon, Nov 5, 2018 at 1:22 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Mon, Nov 05, 2018 at 10:42:27AM +0200, Semion Lisyansky wrote:
Thanks, Alexander
Using bird 2.0.2. Guess it does not include patch you mentioned
Have another question: Configured peers in vrf with different addresses but still in overlapping subnets. BGP session are established and some prefixes advertised. The issue is that bird/bgp tries to resolve nexthops for all vrfs only in default.
Hi
This should work in 2.0.2, the routes are supposed to be resolved by default in the same table to which the BGP protocol is connected, in your case table_vrf01. Could you send output of BIRD commands:
show interfaces show protocols all show route show route table table_vrf01 ?
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
On Mon, Nov 05, 2018 at 03:05:17PM +0200, Semion Lisyansky wrote:
Hi,
Please find below requested info. Some omitted because of size You may clearly see the issue on 1st show
Thanks for info. You are using single-hop EBGP, therefore next hop is not resolved through a routing table, but directly through interface table, but still it should take into account VRF protocol specified by the BGP protocol. I guess setting 'gateway recursive' BGP option would fix the issue, but that is just workaround, it should work even without it. Could you try compile and run current 'int-new' branch from GIT? It has plenty of fixes related to neighbor cache, which may be related. Could you also show your config for bgp_vrf01_ixia1 protocol? That was not in the config from original post. It may be useful to know if your established BGP sessions were incoming or outgoing. Could you check that using netstat/ss? Also, what is your kernel versions? Older kernels have limited support for VRF, but not sure if that is related. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Most chances that BGP session was initiated from BIRD cat /etc/issue Ubuntu 18.04 LTS \n \l uname -r 4.19.0-041900rc7-generic #VRF vrf01 ipv4 table table_vrf01; protocol kernel kernel_vrf01 { vrf "vrf01"; kernel table 101; scan time 2; ipv4 { table table_vrf01; import none; # Default is import all export all; # Default is export none }; merge paths yes; learn on; # Learn all alien routes from the kernel } protocol direct direct_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; interface "swp32.101"; interface "swp17.201"; interface "swp18.301"; interface "vrf01"; } protocol static static_vrf01 { vrf "vrf01"; ipv4 { table table_vrf01; }; } protocol bgp bgp_vrf01_n1 { vrf "vrf01"; local as 65034; bfd yes; graceful restart; neighbor 191.34.1.4 as 65001; ipv4 { table table_vrf01; import all; # export all; export where source = RTS_BGP; }; } protocol bgp bgp_vrf01_n2 { vrf "vrf01"; local as 65034; bfd yes; graceful restart; neighbor 192.34.1.4 as 65001; ipv4 { table table_vrf01; import all; # export all; export where source = RTS_BGP; }; } protocol bgp bgp_vrf01_ixia1 { local as 65034; # bfd yes; neighbor 190.34.32.101 as 65134; graceful restart; ipv4 { table table_vrf01; import all; export all; }; } Don't have possibility to compile new version -- Semion Lisyansky On Mon, Nov 5, 2018 at 4:49 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Mon, Nov 05, 2018 at 03:05:17PM +0200, Semion Lisyansky wrote:
Hi,
Please find below requested info. Some omitted because of size You may clearly see the issue on 1st show
Thanks for info.
You are using single-hop EBGP, therefore next hop is not resolved through a routing table, but directly through interface table, but still it should take into account VRF protocol specified by the BGP protocol.
I guess setting 'gateway recursive' BGP option would fix the issue, but that is just workaround, it should work even without it.
Could you try compile and run current 'int-new' branch from GIT? It has plenty of fixes related to neighbor cache, which may be related.
Could you also show your config for bgp_vrf01_ixia1 protocol? That was not in the config from original post.
It may be useful to know if your established BGP sessions were incoming or outgoing. Could you check that using netstat/ss?
Also, what is your kernel versions? Older kernels have limited support for VRF, but not sure if that is related.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
On Mon, Nov 05, 2018 at 05:28:44PM +0200, Semion Lisyansky wrote:
protocol bgp bgp_vrf01_n2 { vrf "vrf01"; local as 65034; bfd yes; graceful restart; neighbor 192.34.1.4 as 65001; ipv4 { table table_vrf01; import all; # export all; export where source = RTS_BGP; }; }
protocol bgp bgp_vrf01_ixia1 { local as 65034; # bfd yes; neighbor 190.34.32.101 as 65134; graceful restart; ipv4 { table table_vrf01; import all; export all; }; }
The protocol bgp_vrf01_ixia1 is not associated with VRF (does not use 'vrf' option, unlike bgp_vrf01_n2 above), so its routes are not associated with vrf1 and lookup is done through all interfaces. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Thanks a lot -- Semion Lisyansky On Mon, Nov 5, 2018 at 5:37 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Mon, Nov 05, 2018 at 05:28:44PM +0200, Semion Lisyansky wrote:
protocol bgp bgp_vrf01_n2 { vrf "vrf01"; local as 65034; bfd yes; graceful restart; neighbor 192.34.1.4 as 65001; ipv4 { table table_vrf01; import all; # export all; export where source = RTS_BGP; }; }
protocol bgp bgp_vrf01_ixia1 { local as 65034; # bfd yes; neighbor 190.34.32.101 as 65134; graceful restart; ipv4 { table table_vrf01; import all; export all; }; }
The protocol bgp_vrf01_ixia1 is not associated with VRF (does not use 'vrf' option, unlike bgp_vrf01_n2 above), so its routes are not associated with vrf1 and lookup is done through all interfaces.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
participants (3)
-
Alexander Zubkov -
Ondrej Zajicek -
Semion Lisyansky