vrf configuration with same addresses
Alexander Zubkov
green at qrator.net
Mon Nov 5 10:21:07 CET 2018
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 at 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 at 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 at 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 at 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 at 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 at 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 at 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
>>>>>
>>>>
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20181105/eb817908/attachment.html>
More information about the Bird-users
mailing list