Re: Doing something wrong with VRF's

2023-09-28 Thread Ondrej Zajicek
On Thu, Sep 28, 2023 at 07:07:03PM +0200, Daniel Gröber wrote:
> On Thu, Sep 28, 2023 at 04:03:33PM +, Nigel Kukard via Bird-users wrote:
> > Well .. I feel embarrassed now. The issue was a missing "kernel table ;"
> > in the kernel protocol.

Hi

Well, i feel embarrassed that BIRD requires you to specify that. It would
make more sense if the kernel protocol used the proper value from VRF
automatically.


> Don't feel bad. I was going to look into using VRFs with bird and now
> there's a nice worked example ready to play with at in my inbox :)

There is also an example from our tests:

https://gitlab.nic.cz/labs/bird-tools/-/blob/master/netlab/cf-ospf-vrf/README.md
https://gitlab.nic.cz/labs/bird-tools/-/blob/master/netlab/cf-ospf-vrf/bird_m1.conf

-- 
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."



Re: Doing something wrong with VRF's

2023-09-28 Thread Nigel Kukard via Bird-users

On 9/28/23 17:07, Daniel Gröber wrote:

On Thu, Sep 28, 2023 at 04:03:33PM +, Nigel Kukard via Bird-users wrote:

Well .. I feel embarrassed now. The issue was a missing "kernel table ;"
in the kernel protocol.

Don't feel bad. I was going to look into using VRFs with bird and now
there's a nice worked example ready to play with at in my inbox :)

--Daniel


Awesome :), hope its some use!

-N




OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: Doing something wrong with VRF's

2023-09-28 Thread Daniel Gröber
On Thu, Sep 28, 2023 at 04:03:33PM +, Nigel Kukard via Bird-users wrote:
> Well .. I feel embarrassed now. The issue was a missing "kernel table ;"
> in the kernel protocol.

Don't feel bad. I was going to look into using VRFs with bird and now
there's a nice worked example ready to play with at in my inbox :)

--Daniel


Re: Doing something wrong with VRF's

2023-09-28 Thread Nigel Kukard via Bird-users
Well .. I feel embarrassed now. The issue was a missing "kernel table 
;" in the kernel protocol.


-N

On 9/28/23 15:29, Nigel Kukard via Bird-users wrote:


Hi there,

I'm wondering if someone could point out what I'm doing wrong here? 
all my routes are being added to the system main table and not my VRF.


I could swear I had this working 100% (I took my config and added vrf 
"vrf0" to each protocol), i then regenerated my config file using my 
software, rebooted and its not worked since. I can't seem to find what 
I broke.


Here is my interfaces... the t0p0 and t0p1 are ip6gretap's, dummy0 is 
just a loopback dummy interface. All are slave to vrf0. lgtm.


4: dummy0:  mtu 1500 qdisc noqueue master 
vrf0 state UNKNOWN mode DEFAULT group default qlen 1000

   link/ether fe:dc:20:04:15:27 brd ff:ff:ff:ff:ff:ff
5: vrf0:  mtu 65575 qdisc noqueue state UP 
mode DEFAULT group default qlen 1000

   link/ether 8a:8e:21:3d:c4:c9 brd ff:ff:ff:ff:ff:ff

8: t0p0@e0p0:  mtu 1430 qdisc 
fq_codel master vrf0 state UNKNOWN mode DEFAULT group default qlen 1000

   link/ether b2:da:ee:78:04:1f brd ff:ff:ff:ff:ff:ff
9: t0p1@e0p0:  mtu 1430 qdisc 
fq_codel master vrf0 state UNKNOWN mode DEFAULT group default qlen 1000

   link/ether fa:61:19:72:65:d8 brd ff:ff:ff:ff:ff:ff

the output from ip rule is this... lgtm.

1000:   from all lookup [l3mdev-table]

The routes within the VRF look like this, lgtm ... ip route show vrf vrf0

X/30 dev t0p0 proto kernel scope link src A
Y/30 dev t0p1 proto kernel scope link src B
Z/27 dev dummy0 proto kernel scope link src C

My main routing table looks like this... lgtm, I don't even have the 
interfaces or anything configured for them in the main table outside 
the VRF.


default via 169.254.1.1 dev e0p0 proto static metric 1000
169.254.1.1 dev e0p0 proto kernel scope link src D metric 256

E dev e0p0 proto kernel metric 256 pref medium
F via fe80::1 dev e0p0 proto static metric 300 pref medium
G via fe80::1 dev e0p0 proto static metric 300 pref medium
fe80::/64 dev e0p0 proto kernel metric 256 pref medium
default via fe80::1 dev e0p0 proto static metric 1000 pref medium

My bird config is below ... I made sure to add vrf "vrf0" to all 
protocols. I searched the mailing list and I can't see what I did 
wrong here.


OSPF comes up fine, I can ping inside the VRF fine, but all my routes 
are being added to the main system table.


I cut out the filters, they're not doing anything interesting. Despite 
BGP being mentioned in the config below, I don't have it configured atm.


# Kernel Table
ipv4 table t_kernel4;
ipv6 table t_kernel6;

# Direct Tables:
ipv4 table t_direct4;
ipv6 table t_direct6;

# OSPF Tables
ipv4 table t_ospf4;
ipv6 table t_ospf6;

...

protocol kernel kernel4 {
 vrf "vrf0";
 description "Kernel protocol for IPv4";


 metric 600; # Set the BIRD metric to be used when creating kernel 
routes to fall in line with our OS

 learn; # Learn routes from the kernel
 persist; # Dont remove routes on BIRD shutdown
 merge paths on; # Merge similar BGP paths into a multi-hop

 ipv4 {
   table t_kernel4;

   export all;
   import all;
 };
};

protocol kernel kernel6 {
 vrf "vrf0";
 description "Kernel protocol for IPv6";


 metric 600; # Set the BIRD metric to be used when creating kernel 
routes to fall in line with our OS

 learn; # Learn routes from the kernel
 persist; # Dont remove routes on BIRD shutdown
 merge paths on; # Merge similar BGP paths into a multi-hop

 ipv6 {
   table t_kernel6;

   export all;
   import all;
 };
};

protocol pipe p_master4_to_kernel4 {
 vrf "vrf0";
 description "Pipe from master4 to t_kernel4";


 table master4;
 peer table t_kernel4;

 export filter f_master4_kernel4_export;
 import filter f_master4_kernel4_import;
};

protocol pipe p_master6_to_kernel6 {
 vrf "vrf0";
 description "Pipe from master6 to t_kernel6";


 table master6;
 peer table t_kernel6;

 export filter f_master6_kernel6_export;
 import filter f_master6_kernel6_import;
};

protocol device {
 vrf "vrf0";
 description "Device protocol";


 scan time 10;
};

protocol direct direct4 {
 vrf "vrf0";
 description "Direct protocol for IPv4";


 ipv4 {
   table t_direct4;

   export none;
   import all;
 };
};

protocol direct direct6 {
 vrf "vrf0";
 description "Direct protocol for IPv6";


 ipv6 {
   table t_direct6;

   export none;
   import all;
 };
};

protocol pipe p_master4_to_direct4 {
 vrf "vrf0";
 description "Pipe from master4 to t_direct4";


 table master4;
 peer table t_direct4;

 export none;
 import all;
};

protocol pipe p_master6_to_direct6 {
 vrf "vrf0";
 description "Pipe from master6 to t_direct6";


 table master6;
 peer table t_direct6;

 export none;
 import all;
};

protocol ospf v2 ospf4 {
 vrf "vrf0";
 description "OSPF protocol for IPv4";


 ipv4 {
   table t_ospf4;

   export filter f_ospf_export;
   import filter f_ospf_import;

 };

 area 0 {
   interface "dummy0" {
 cost 10;
 ecmp weight 1;
 stub;
   };
   interface "t0p0" {
 cost 1000;

Doing something wrong with VRF's

2023-09-28 Thread Nigel Kukard via Bird-users

Hi there,

I'm wondering if someone could point out what I'm doing wrong here? all 
my routes are being added to the system main table and not my VRF.


I could swear I had this working 100% (I took my config and added vrf 
"vrf0" to each protocol), i then regenerated my config file using my 
software, rebooted and its not worked since. I can't seem to find what I 
broke.


Here is my interfaces... the t0p0 and t0p1 are ip6gretap's, dummy0 is 
just a loopback dummy interface. All are slave to vrf0. lgtm.


4: dummy0:  mtu 1500 qdisc noqueue master 
vrf0 state UNKNOWN mode DEFAULT group default qlen 1000

   link/ether fe:dc:20:04:15:27 brd ff:ff:ff:ff:ff:ff
5: vrf0:  mtu 65575 qdisc noqueue state UP 
mode DEFAULT group default qlen 1000

   link/ether 8a:8e:21:3d:c4:c9 brd ff:ff:ff:ff:ff:ff

8: t0p0@e0p0:  mtu 1430 qdisc fq_codel 
master vrf0 state UNKNOWN mode DEFAULT group default qlen 1000

   link/ether b2:da:ee:78:04:1f brd ff:ff:ff:ff:ff:ff
9: t0p1@e0p0:  mtu 1430 qdisc fq_codel 
master vrf0 state UNKNOWN mode DEFAULT group default qlen 1000

   link/ether fa:61:19:72:65:d8 brd ff:ff:ff:ff:ff:ff

the output from ip rule is this... lgtm.

1000:   from all lookup [l3mdev-table]

The routes within the VRF look like this, lgtm ... ip route show vrf vrf0

X/30 dev t0p0 proto kernel scope link src A
Y/30 dev t0p1 proto kernel scope link src B
Z/27 dev dummy0 proto kernel scope link src C

My main routing table looks like this... lgtm, I don't even have the 
interfaces or anything configured for them in the main table outside the 
VRF.


default via 169.254.1.1 dev e0p0 proto static metric 1000
169.254.1.1 dev e0p0 proto kernel scope link src D metric 256

E dev e0p0 proto kernel metric 256 pref medium
F via fe80::1 dev e0p0 proto static metric 300 pref medium
G via fe80::1 dev e0p0 proto static metric 300 pref medium
fe80::/64 dev e0p0 proto kernel metric 256 pref medium
default via fe80::1 dev e0p0 proto static metric 1000 pref medium

My bird config is below ... I made sure to add vrf "vrf0" to all 
protocols. I searched the mailing list and I can't see what I did wrong 
here.


OSPF comes up fine, I can ping inside the VRF fine, but all my routes 
are being added to the main system table.


I cut out the filters, they're not doing anything interesting. Despite 
BGP being mentioned in the config below, I don't have it configured atm.


# Kernel Table
ipv4 table t_kernel4;
ipv6 table t_kernel6;

# Direct Tables:
ipv4 table t_direct4;
ipv6 table t_direct6;

# OSPF Tables
ipv4 table t_ospf4;
ipv6 table t_ospf6;

...

protocol kernel kernel4 {
 vrf "vrf0";
 description "Kernel protocol for IPv4";


 metric 600; # Set the BIRD metric to be used when creating kernel 
routes to fall in line with our OS

 learn; # Learn routes from the kernel
 persist; # Dont remove routes on BIRD shutdown
 merge paths on; # Merge similar BGP paths into a multi-hop

 ipv4 {
   table t_kernel4;

   export all;
   import all;
 };
};

protocol kernel kernel6 {
 vrf "vrf0";
 description "Kernel protocol for IPv6";


 metric 600; # Set the BIRD metric to be used when creating kernel 
routes to fall in line with our OS

 learn; # Learn routes from the kernel
 persist; # Dont remove routes on BIRD shutdown
 merge paths on; # Merge similar BGP paths into a multi-hop

 ipv6 {
   table t_kernel6;

   export all;
   import all;
 };
};

protocol pipe p_master4_to_kernel4 {
 vrf "vrf0";
 description "Pipe from master4 to t_kernel4";


 table master4;
 peer table t_kernel4;

 export filter f_master4_kernel4_export;
 import filter f_master4_kernel4_import;
};

protocol pipe p_master6_to_kernel6 {
 vrf "vrf0";
 description "Pipe from master6 to t_kernel6";


 table master6;
 peer table t_kernel6;

 export filter f_master6_kernel6_export;
 import filter f_master6_kernel6_import;
};

protocol device {
 vrf "vrf0";
 description "Device protocol";


 scan time 10;
};

protocol direct direct4 {
 vrf "vrf0";
 description "Direct protocol for IPv4";


 ipv4 {
   table t_direct4;

   export none;
   import all;
 };
};

protocol direct direct6 {
 vrf "vrf0";
 description "Direct protocol for IPv6";


 ipv6 {
   table t_direct6;

   export none;
   import all;
 };
};

protocol pipe p_master4_to_direct4 {
 vrf "vrf0";
 description "Pipe from master4 to t_direct4";


 table master4;
 peer table t_direct4;

 export none;
 import all;
};

protocol pipe p_master6_to_direct6 {
 vrf "vrf0";
 description "Pipe from master6 to t_direct6";


 table master6;
 peer table t_direct6;

 export none;
 import all;
};

protocol ospf v2 ospf4 {
 vrf "vrf0";
 description "OSPF protocol for IPv4";


 ipv4 {
   table t_ospf4;

   export filter f_ospf_export;
   import filter f_ospf_import;

 };

 area 0 {
   interface "dummy0" {
 cost 10;
 ecmp weight 1;
 stub;
   };
   interface "t0p0" {
 cost 1000;
 ecmp weight 1;
   };
   interface "t0p1" {
 cost 1000;
 ecmp weight 1;
   };
 };
};

protocol ospf v3 ospf6 {
 vrf "vrf0";
 description "OSPF protoc