rejected by protocol <prefix> unicast
Hi, Prefixes sent over a eBGP session are getting rejected "by protocol" as can be seen in the logs below. The prefixes are "added" and then get "rejected" by protocol. This means that they are visible using the "show route protocol <protocol>" but not "show route all" (and therefore impossible to push them to the kernel routing table). // logs 2019-12-10 21:15:00.774 <TRACE> pe1: BGP session established 2019-12-10 21:15:00.774 <TRACE> pe1: State changed to up 2019-12-10 21:15:00.774 <TRACE> pe1: Sending END-OF-RIB 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1: Got END-OF-RIB Tcp dump of the corresponding update message(s): // tcpdump 21:18:59.652705 IP (tos 0xc0, ttl 1, id 7035, offset 0, flags [none], proto TCP (6), length 177) *192.168.254.1*.bgp > 192.168.254.0.41073: Flags [P.], cksum 0x4356 (correct), seq 83:208, ack 73, win 16384, options [nop,nop,TS val 2249949122 ecr 1355158152], length 125: BGP Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: IGP 0x0000: 00 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: 192.168.254.1 0x0000: c0a8 fe01 Updated routes: 10.1.12.0/24 Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: Incomplete 0x0000: 02 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: *192.168.254.1* 0x0000: c0a8 fe01 Updated routes: 10.2.34.0/24 Update Message (2), length: 23 End-of-Rib Marker (empty NLRI) The bgp session is over directly connected interfaces and the NLRI prefix next hops are therefore directly connected. // Configuration: protocol bgp pe1 { debug all; description "ebgp"; hold time 90; local 192.168.254.0 as my_asn; neighbor 192.168.254.1 as peer_asn; direct; interpret communities off; ipv4 { table t_pe1; import all; export none; gateway direct; }; } protocol device { scan time 10; }; protocol direct { ipv4; }; protocol kernel { scan time 10; learn; persist; ipv4 { import filter { if net ~ [0.0.0.0/0, 192.168.255.0/24] then reject; }; }; } // relevant show results bird> *show route protocol pe1* Table t_pe1: *10.2.34.0/24 <http://10.2.34.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500?] via 192.168.254.1 on ens5 *10.1.12.0/24 <http://10.1.12.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500i] via 192.168.254.1 on ens5 bird> bird> *show route all* Table master4: 172.16.0.11/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.1 on ens5 Type: static univ 192.168.254.2/31 unicast [direct1 20:56:03.498] * (240) dev ens6 Type: device univ 192.168.254.0/31 unicast [direct1 20:56:03.498] * (240) dev ens5 Type: device univ 192.168.255.0/24 unicast [direct1 20:56:03.498] * (240) dev ens4 Type: device univ 172.16.0.33/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.3 on ens6 Type: static univ Thanks,
The kernel protocol import filter is missing the accept; statement after you selectively filter some prefices out. BIRD doesn't know whether you want to accept or reject these routes. It also shall warn you in log. Do you have any log line saying something about filter not rejecting nor accepting? Maria On December 10, 2019 10:09:06 PM GMT+01:00, wax xitau <waxitau@gmail.com> wrote:
Hi,
Prefixes sent over a eBGP session are getting rejected "by protocol" as can be seen in the logs below. The prefixes are "added" and then get "rejected" by protocol. This means that they are visible using the "show route protocol <protocol>" but not "show route all" (and therefore impossible to push them to the kernel routing table).
// logs
2019-12-10 21:15:00.774 <TRACE> pe1: BGP session established 2019-12-10 21:15:00.774 <TRACE> pe1: State changed to up 2019-12-10 21:15:00.774 <TRACE> pe1: Sending END-OF-RIB 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1: Got END-OF-RIB
Tcp dump of the corresponding update message(s):
// tcpdump
21:18:59.652705 IP (tos 0xc0, ttl 1, id 7035, offset 0, flags [none], proto TCP (6), length 177) *192.168.254.1*.bgp > 192.168.254.0.41073: Flags [P.], cksum 0x4356 (correct), seq 83:208, ack 73, win 16384, options [nop,nop,TS val 2249949122 ecr 1355158152], length 125: BGP Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: IGP 0x0000: 00 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: 192.168.254.1 0x0000: c0a8 fe01 Updated routes: 10.1.12.0/24 Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: Incomplete 0x0000: 02 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: *192.168.254.1* 0x0000: c0a8 fe01 Updated routes: 10.2.34.0/24 Update Message (2), length: 23 End-of-Rib Marker (empty NLRI)
The bgp session is over directly connected interfaces and the NLRI prefix next hops are therefore directly connected.
// Configuration:
protocol bgp pe1 { debug all; description "ebgp"; hold time 90; local 192.168.254.0 as my_asn; neighbor 192.168.254.1 as peer_asn; direct; interpret communities off; ipv4 { table t_pe1; import all; export none; gateway direct; }; }
protocol device { scan time 10; };
protocol direct { ipv4; };
protocol kernel { scan time 10; learn; persist; ipv4 { import filter { if net ~ [0.0.0.0/0, 192.168.255.0/24] then reject; }; }; }
// relevant show results
bird> *show route protocol pe1* Table t_pe1: *10.2.34.0/24 <http://10.2.34.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500?] via 192.168.254.1 on ens5 *10.1.12.0/24 <http://10.1.12.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500i] via 192.168.254.1 on ens5 bird>
bird> *show route all* Table master4: 172.16.0.11/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.1 on ens5 Type: static univ 192.168.254.2/31 unicast [direct1 20:56:03.498] * (240) dev ens6 Type: device univ 192.168.254.0/31 unicast [direct1 20:56:03.498] * (240) dev ens5 Type: device univ 192.168.255.0/24 unicast [direct1 20:56:03.498] * (240) dev ens4 Type: device univ 172.16.0.33/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.3 on ens6 Type: static univ
Thanks,
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Thanks for the prompt response Maria. I actually had import all and that did not work either. I've added accept to the kernel protocol with the same results. I also don't have any log line about a filter rejecting or accepting. // logs after restarting the bgp session 2019-12-10 22:41:40.989 <INFO> Restarting protocol pe1 2019-12-10 22:41:40.989 <TRACE> pe1: Shutting down 2019-12-10 22:41:40.989 <TRACE> pe1: Shutdown requested 2019-12-10 22:41:40.989 <TRACE> pe1: State changed to stop 2019-12-10 22:41:40.989 <TRACE> pe1: BGP session closed 2019-12-10 22:41:40.990 <TRACE> pe1 > removed [sole] 10.2.34.0/24 unicast 2019-12-10 22:41:40.990 <TRACE> pe1 > removed [sole] 10.1.12.0/24 unicast 2019-12-10 22:41:40.990 <TRACE> pe1: Sending NOTIFICATION(code=6.4) 2019-12-10 22:41:40.990 <TRACE> pe1: Down 2019-12-10 22:41:40.990 <TRACE> pe1: State changed to flush 2019-12-10 22:41:40.990 <TRACE> pe1: State changed to down 2019-12-10 22:41:40.990 <TRACE> pe1: Starting 2019-12-10 22:41:40.990 <TRACE> pe1: State changed to start 2019-12-10 22:41:40.990 <TRACE> pe1: Started 2019-12-10 22:41:40.990 <TRACE> pe1: Connect delayed by 5 seconds 2019-12-10 22:41:44.994 <TRACE> pe1: Connecting to 192.168.254.1 from local address 192.168.254.0 2019-12-10 22:41:45.275 <TRACE> pe1: Connected 2019-12-10 22:41:45.275 <TRACE> pe1: Sending OPEN(ver=4,as=65099,hold=90,id=ac100165) 2019-12-10 22:41:45.363 <TRACE> pe1: Got OPEN(as=65001,hold=90,id=172.16.0.11) 2019-12-10 22:41:45.363 <TRACE> pe1: Sending KEEPALIVE 2019-12-10 22:41:45.576 <TRACE> pe1: Got KEEPALIVE 2019-12-10 22:41:45.576 <TRACE> pe1: BGP session established 2019-12-10 22:41:45.576 <TRACE> pe1: State changed to up 2019-12-10 22:41:45.576 <TRACE> pe1: Got UPDATE 2019-12-10 22:41:45.576 <TRACE> pe1 > *added [best] 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 22:41:45.576 <TRACE> pe1 < *rejected by protocol 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 22:41:45.576 <TRACE> pe1: Got UPDATE 2019-12-10 22:41:45.576 <TRACE> pe1 > *added [best] 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 22:41:45.576 <TRACE> pe1 < *rejected by protocol 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 22:41:45.576 <TRACE> pe1: Got UPDATE 2019-12-10 22:41:45.576 <TRACE> pe1: Got END-OF-RIB 2019-12-10 22:41:45.576 <TRACE> pe1 < rejected by protocol 10.2.34.0/24 unicast 2019-12-10 22:41:45.576 <TRACE> pe1 < rejected by protocol 10.1.12.0/24 unicast 2019-12-10 22:41:45.576 <TRACE> pe1: Sending END-OF-RIB // kernel protocol protocol kernel { scan time 10; learn; persist; ipv4 { #import filter { # if net ~ [0.0.0.0/0, 192.168.255.0/24] then reject; # accept; #}; # export all; import all; }; } thx On Tue, Dec 10, 2019 at 10:25 PM Maria Matějka <maria.matejka@nic.cz> wrote:
The kernel protocol import filter is missing the accept; statement after you selectively filter some prefices out. BIRD doesn't know whether you want to accept or reject these routes. It also shall warn you in log. Do you have any log line saying something about filter not rejecting nor accepting? Maria
On December 10, 2019 10:09:06 PM GMT+01:00, wax xitau <waxitau@gmail.com> wrote:
Hi,
Prefixes sent over a eBGP session are getting rejected "by protocol" as can be seen in the logs below. The prefixes are "added" and then get "rejected" by protocol. This means that they are visible using the "show route protocol <protocol>" but not "show route all" (and therefore impossible to push them to the kernel routing table).
// logs
2019-12-10 21:15:00.774 <TRACE> pe1: BGP session established 2019-12-10 21:15:00.774 <TRACE> pe1: State changed to up 2019-12-10 21:15:00.774 <TRACE> pe1: Sending END-OF-RIB 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1: Got END-OF-RIB
Tcp dump of the corresponding update message(s):
// tcpdump
21:18:59.652705 IP (tos 0xc0, ttl 1, id 7035, offset 0, flags [none], proto TCP (6), length 177) *192.168.254.1*.bgp > 192.168.254.0.41073: Flags [P.], cksum 0x4356 (correct), seq 83:208, ack 73, win 16384, options [nop,nop,TS val 2249949122 ecr 1355158152], length 125: BGP Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: IGP 0x0000: 00 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: 192.168.254.1 0x0000: c0a8 fe01 Updated routes: 10.1.12.0/24 Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: Incomplete 0x0000: 02 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: *192.168.254.1* 0x0000: c0a8 fe01 Updated routes: 10.2.34.0/24 Update Message (2), length: 23 End-of-Rib Marker (empty NLRI)
The bgp session is over directly connected interfaces and the NLRI prefix next hops are therefore directly connected.
// Configuration:
protocol bgp pe1 { debug all; description "ebgp"; hold time 90; local 192.168.254.0 as my_asn; neighbor 192.168.254.1 as peer_asn; direct; interpret communities off; ipv4 { table t_pe1; import all; export none; gateway direct; }; }
protocol device { scan time 10; };
protocol direct { ipv4; };
protocol kernel { scan time 10; learn; persist; ipv4 { import filter { if net ~ [0.0.0.0/0, 192.168.255.0/24] then reject; }; }; }
// relevant show results
bird> *show route protocol pe1* Table t_pe1: *10.2.34.0/24 <http://10.2.34.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500?] via 192.168.254.1 on ens5 *10.1.12.0/24 <http://10.1.12.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500i] via 192.168.254.1 on ens5 bird>
bird> *show route all* Table master4: 172.16.0.11/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.1 on ens5 Type: static univ 192.168.254.2/31 unicast [direct1 20:56:03.498] * (240) dev ens6 Type: device univ 192.168.254.0/31 unicast [direct1 20:56:03.498] * (240) dev ens5 Type: device univ 192.168.255.0/24 unicast [direct1 20:56:03.498] * (240) dev ens4 Type: device univ 172.16.0.33/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.3 on ens6 Type: static univ
Thanks,
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Because in kernel protocol you shall write export filter. Also overlooked this at the first sight. To accept routes from bgp to table, you write import filter, to send routes from table to kernel, you write export filter. The import/export semantics is table-centric. Maria On December 10, 2019 10:48:42 PM GMT+01:00, wax xitau <waxitau@gmail.com> wrote:
Thanks for the prompt response Maria.
I actually had import all and that did not work either. I've added accept to the kernel protocol with the same results. I also don't have any log line about a filter rejecting or accepting.
// logs after restarting the bgp session
2019-12-10 22:41:40.989 <INFO> Restarting protocol pe1 2019-12-10 22:41:40.989 <TRACE> pe1: Shutting down 2019-12-10 22:41:40.989 <TRACE> pe1: Shutdown requested 2019-12-10 22:41:40.989 <TRACE> pe1: State changed to stop 2019-12-10 22:41:40.989 <TRACE> pe1: BGP session closed 2019-12-10 22:41:40.990 <TRACE> pe1 > removed [sole] 10.2.34.0/24 unicast 2019-12-10 22:41:40.990 <TRACE> pe1 > removed [sole] 10.1.12.0/24 unicast 2019-12-10 22:41:40.990 <TRACE> pe1: Sending NOTIFICATION(code=6.4) 2019-12-10 22:41:40.990 <TRACE> pe1: Down 2019-12-10 22:41:40.990 <TRACE> pe1: State changed to flush 2019-12-10 22:41:40.990 <TRACE> pe1: State changed to down 2019-12-10 22:41:40.990 <TRACE> pe1: Starting 2019-12-10 22:41:40.990 <TRACE> pe1: State changed to start 2019-12-10 22:41:40.990 <TRACE> pe1: Started 2019-12-10 22:41:40.990 <TRACE> pe1: Connect delayed by 5 seconds 2019-12-10 22:41:44.994 <TRACE> pe1: Connecting to 192.168.254.1 from local address 192.168.254.0 2019-12-10 22:41:45.275 <TRACE> pe1: Connected 2019-12-10 22:41:45.275 <TRACE> pe1: Sending OPEN(ver=4,as=65099,hold=90,id=ac100165) 2019-12-10 22:41:45.363 <TRACE> pe1: Got OPEN(as=65001,hold=90,id=172.16.0.11) 2019-12-10 22:41:45.363 <TRACE> pe1: Sending KEEPALIVE 2019-12-10 22:41:45.576 <TRACE> pe1: Got KEEPALIVE 2019-12-10 22:41:45.576 <TRACE> pe1: BGP session established 2019-12-10 22:41:45.576 <TRACE> pe1: State changed to up 2019-12-10 22:41:45.576 <TRACE> pe1: Got UPDATE 2019-12-10 22:41:45.576 <TRACE> pe1 > *added [best] 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 22:41:45.576 <TRACE> pe1 < *rejected by protocol 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 22:41:45.576 <TRACE> pe1: Got UPDATE 2019-12-10 22:41:45.576 <TRACE> pe1 > *added [best] 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 22:41:45.576 <TRACE> pe1 < *rejected by protocol 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 22:41:45.576 <TRACE> pe1: Got UPDATE 2019-12-10 22:41:45.576 <TRACE> pe1: Got END-OF-RIB 2019-12-10 22:41:45.576 <TRACE> pe1 < rejected by protocol 10.2.34.0/24 unicast 2019-12-10 22:41:45.576 <TRACE> pe1 < rejected by protocol 10.1.12.0/24 unicast 2019-12-10 22:41:45.576 <TRACE> pe1: Sending END-OF-RIB
// kernel protocol
protocol kernel { scan time 10; learn; persist; ipv4 { #import filter { # if net ~ [0.0.0.0/0, 192.168.255.0/24] then reject; # accept; #}; # export all; import all; }; }
thx
On Tue, Dec 10, 2019 at 10:25 PM Maria Matějka <maria.matejka@nic.cz> wrote:
The kernel protocol import filter is missing the accept; statement after you selectively filter some prefices out. BIRD doesn't know whether you want to accept or reject these routes. It also shall warn you in log. Do you have any log line saying something about filter not rejecting nor accepting? Maria
On December 10, 2019 10:09:06 PM GMT+01:00, wax xitau <waxitau@gmail.com> wrote:
Hi,
Prefixes sent over a eBGP session are getting rejected "by protocol"
as
can be seen in the logs below. The prefixes are "added" and then get "rejected" by protocol. This means that they are visible using the "show route protocol <protocol>" but not "show route all" (and therefore impossible to push them to the kernel routing table).
// logs
2019-12-10 21:15:00.774 <TRACE> pe1: BGP session established 2019-12-10 21:15:00.774 <TRACE> pe1: State changed to up 2019-12-10 21:15:00.774 <TRACE> pe1: Sending END-OF-RIB 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.2.34.0/24 <http://10.2.34.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1 > *added [best] 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1 < *rejected by protocol 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-10 21:15:00.984 <TRACE> pe1: Got UPDATE 2019-12-10 21:15:00.984 <TRACE> pe1: Got END-OF-RIB
Tcp dump of the corresponding update message(s):
// tcpdump
21:18:59.652705 IP (tos 0xc0, ttl 1, id 7035, offset 0, flags [none], proto TCP (6), length 177) *192.168.254.1*.bgp > 192.168.254.0.41073: Flags [P.], cksum 0x4356 (correct), seq 83:208, ack 73, win 16384, options [nop,nop,TS val 2249949122 ecr 1355158152], length 125: BGP Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: IGP 0x0000: 00 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: 192.168.254.1 0x0000: c0a8 fe01 Updated routes: 10.1.12.0/24 Update Message (2), length: 51 Origin (1), length: 1, Flags [T]: Incomplete 0x0000: 02 AS Path (2), length: 10, Flags [T]: 65001 65500 0x0000: 0202 0000 fde9 0000 ffdc Next Hop (3), length: 4, Flags [T]: *192.168.254.1* 0x0000: c0a8 fe01 Updated routes: 10.2.34.0/24 Update Message (2), length: 23 End-of-Rib Marker (empty NLRI)
The bgp session is over directly connected interfaces and the NLRI prefix next hops are therefore directly connected.
// Configuration:
protocol bgp pe1 { debug all; description "ebgp"; hold time 90; local 192.168.254.0 as my_asn; neighbor 192.168.254.1 as peer_asn; direct; interpret communities off; ipv4 { table t_pe1; import all; export none; gateway direct; }; }
protocol device { scan time 10; };
protocol direct { ipv4; };
protocol kernel { scan time 10; learn; persist; ipv4 { import filter { if net ~ [0.0.0.0/0, 192.168.255.0/24] then reject; }; }; }
// relevant show results
bird> *show route protocol pe1* Table t_pe1: *10.2.34.0/24 <http://10.2.34.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500?] via 192.168.254.1 on ens5 *10.1.12.0/24 <http://10.1.12.0/24>* unicast [pe1 21:46:13.530] * (100) [AS65500i] via 192.168.254.1 on ens5 bird>
bird> *show route all* Table master4: 172.16.0.11/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.1 on ens5 Type: static univ 192.168.254.2/31 unicast [direct1 20:56:03.498] * (240) dev ens6 Type: device univ 192.168.254.0/31 unicast [direct1 20:56:03.498] * (240) dev ens5 Type: device univ 192.168.255.0/24 unicast [direct1 20:56:03.498] * (240) dev ens4 Type: device univ 172.16.0.33/32 unicast [rt_nh 20:25:25.379] * (200) via 192.168.254.3 on ens6 Type: static univ
Thanks,
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Tue, Dec 10, 2019 at 10:09:06PM +0100, wax xitau wrote:
Hi,
Prefixes sent over a eBGP session are getting rejected "by protocol" as can be seen in the logs below.
The prefixes are "added" and then get "rejected" by protocol.
Hi This 'rejected by protocol' is completely harmless. That just means pe1 reject it back - no need to send the route back to the peer.
This means that they are visible using the "show route protocol <protocol>" but not "show route all" (and therefore impossible to push them to the kernel routing table).
No, the reason why the route is shown in 'show route protocol' but not regular 'show route' is that BGP is connected to table t_pe1, while Kernel is connected to (default) table master4. The first command shows by default routes in table attached to the specified protocol, while the second one shows routes in default table. But you do not have connection between these tables (using pipe protocol), so BGP routes stay in t_pe1 and are not in master4, so that is another reason why they are not exported to the kernel. -- 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 Wed, Dec 11, 2019 at 3:19 AM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Tue, Dec 10, 2019 at 10:09:06PM +0100, wax xitau wrote:
Hi,
Prefixes sent over a eBGP session are getting rejected "by protocol" as can be seen in the logs below.
The prefixes are "added" and then get "rejected" by protocol.
Hi
This 'rejected by protocol' is completely harmless. That just means pe1 reject it back - no need to send the route back to the peer.
Thanks for the explanation, and I actually did see the "rejected by protocol" line in the logs (below) when I reconfigured using a different address family (vpn4 mpls). 2019-12-11 08:26:06.951 <TRACE> *pe1 > added [best] 65001:101 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-11 08:26:06.951 <TRACE> *pe1 < rejected by protocol 65001:101 10.1.12.0/24 <http://10.1.12.0/24> unicast* 2019-12-11 08:26:06.951 <TRACE> pe1 < rejected by protocol 65001:101 10.1.12.0/24 unicast 2019-12-11 08:26:06.951 <TRACE> pe1: Sending END-OF-RIB Probably minor but "show route" seems to display both tables, master4 & t_pe1 (below) when i used vpn4 mpls address family but not when ipv4 unicast AF is used. *bird> show route* *Table master4:* 0.0.0.0/0 unicast [kernel1 07:43:41.186] (10) via 192.168.255.1 on ens4 172.16.0.11/32 unicast [rt_nh 07:43:41.178] * (200) via 192.168.254.1 on ens5 unicast [kernel1 08:23:59.916] (10) via 192.168.254.1 on ens5 172.16.0.33/32 unicast [rt_nh 07:43:41.178] * (200) via 192.168.254.3 on ens6 *Table t_pe1:* 65001:101 10.1.12.0/24 unicast [pe1 08:26:06.951 from 172.16.0.11] * (100/?) [AS65500i] via 192.168.254.1 on ens5 mpls 21 *bird>*
This means that they are visible using the "show route protocol <protocol>" but not "show route all" (and therefore impossible to push them to the kernel routing table).
No, the reason why the route is shown in 'show route protocol' but not regular 'show route' is that BGP is connected to table t_pe1, while Kernel is connected to (default) table master4. The first command shows by default routes in table attached to the specified protocol, while the second one shows routes in default table. But you do not have connection between these tables (using pipe protocol), so BGP routes stay in t_pe1 and are not in master4, so that is another reason why they are not exported to the kernel.
Explains a lot! I had missed the part about being in master4 to be exported to the kernel and another use case for peer tables. A (most likely dump) question that's unrelated to the current topic: - is it possible to discard the route distinguisher from vpn4 mpls prefix (essentially changing the AF to labelled unicast) while retaining the labelled next hop ? maybe during export to kernel ? Thanks,
-- 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."
-- Eric Gitau 0631234053 *Wifirst* 26 rue de Berri, 75008 Paris
On Wed, Dec 11, 2019 at 09:06:15AM +0100, Eric GITAU wrote:
On Wed, Dec 11, 2019 at 3:19 AM Ondrej Zajicek <santiago@crfreenet.org>
Hi
This 'rejected by protocol' is completely harmless. That just means pe1 reject it back - no need to send the route back to the peer.
Thanks for the explanation, and I actually did see the "rejected by protocol" line in the logs (below) when I reconfigured using a different address family (vpn4 mpls). ... Probably minor but "show route" seems to display both tables, master4 & t_pe1 (below) when i used vpn4 mpls address family but not when ipv4 unicast AF is used.
Yes, 'show route' by defaults show one (default) table per type. If you define vpn4 mpls routing table, then it becames the default one for that type (as there is no implicit vpn4 mpls routing table). While there is already default master4 for ipv4.
No, the reason why the route is shown in 'show route protocol' but not regular 'show route' is that BGP is connected to table t_pe1, while Kernel is connected to (default) table master4. The first command shows by default routes in table attached to the specified protocol, while the second one shows routes in default table. But you do not have connection between these tables (using pipe protocol), so BGP routes stay in t_pe1 and are not in master4, so that is another reason why they are not exported to the kernel.
Explains a lot! I had missed the part about being in master4 to be exported to the kernel and another use case for peer tables.
A (most likely dump) question that's unrelated to the current topic: - is it possible to discard the route distinguisher from vpn4 mpls prefix (essentially changing the AF to labelled unicast) while retaining the labelled next hop ? maybe during export to kernel ?
That is currently not supported. Therefore, applicability of vpn4 mpls in BIRD is limited to route reflectors. -- 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."
Got it, thanks for your help guys. On Wed, Dec 11, 2019 at 1:54 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Wed, Dec 11, 2019 at 09:06:15AM +0100, Eric GITAU wrote:
On Wed, Dec 11, 2019 at 3:19 AM Ondrej Zajicek <santiago@crfreenet.org>
Hi
This 'rejected by protocol' is completely harmless. That just means pe1 reject it back - no need to send the route back to the peer.
Thanks for the explanation, and I actually did see the "rejected by protocol" line in the logs (below) when I reconfigured using a different address family (vpn4 mpls). ... Probably minor but "show route" seems to display both tables, master4 & t_pe1 (below) when i used vpn4 mpls address family but not when ipv4 unicast AF is used.
Yes, 'show route' by defaults show one (default) table per type. If you define vpn4 mpls routing table, then it becames the default one for that type (as there is no implicit vpn4 mpls routing table). While there is already default master4 for ipv4.
No, the reason why the route is shown in 'show route protocol' but not regular 'show route' is that BGP is connected to table t_pe1, while Kernel is connected to (default) table master4. The first command shows by default routes in table attached to the specified protocol, while the second one shows routes in default table. But you do not have connection between these tables (using pipe protocol), so BGP routes stay in t_pe1 and are not in master4, so that is another reason why they are not exported to the kernel.
Explains a lot! I had missed the part about being in master4 to be exported to the kernel and another use case for peer tables.
A (most likely dump) question that's unrelated to the current topic: - is it possible to discard the route distinguisher from vpn4 mpls prefix (essentially changing the AF to labelled unicast) while retaining the labelled next hop ? maybe during export to kernel ?
That is currently not supported. Therefore, applicability of vpn4 mpls in BIRD is limited to route reflectors.
-- 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 (4)
-
Eric GITAU -
Maria Matějka -
Ondrej Zajicek -
wax xitau