- frog - lists.frrouting.org

Display in wrong order for prefix-list
by Sébastien 65 24 Apr '20

24 Apr '20

Hi, I note that the display of a prefix-list AND bgp as-path access-list is not in the correct order, the sequences are mixed and this is not easily readable ... ip prefix-list LIST1 seq 10 deny X ip prefix-list LIST1 seq 100 deny X ip prefix-list LIST1 seq 105 deny X ip prefix-list LIST1 seq 15 deny X ip prefix-list LIST1 seq 20 deny X ip prefix-list LIST1 seq 200 permit X ip prefix-list LIST1 seq 25 deny X ip prefix-list LIST1 seq 30 deny X ip prefix-list LIST1 seq 35 deny X ip prefix-list LIST1 seq 40 deny X ip prefix-list LIST1 seq 45 deny X ip prefix-list LIST1 seq 5 deny X How to display the sequences in the right order (10,15,20,25,...,100,105,200,...)? Thank you !

4 6

L3vpn and FRR - Issue
by Rakesh M 23 Apr '20

23 Apr '20

Hi All, I have a peculiar problem with reaching two VPN endpoints between L3VPN enabled FRR Routers I see the routes and everything w.r.t to control plane appears to be fine, but when I try to source the traffic I cant ping each other r1# sh ip route vrf BLUE Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route VRF BLUE: B> 100.65.64.152/30 [200/0] via x.x.x.x(vrf default) (recursive), label 16, 00:33:56 * via 100.65.64.137, bond0.3054(vrf default), label 179/16, 00:33:56 C>* 100.65.64.156/30 is directly connected, bond0.3600, 00:47:03 B> 100.65.64.160/30 [200/0] via x.x.x.x(vrf default) (recursive), label 16, 00:13:06 * via 100.65.64.137, bond0.3054(vrf default), label 179/16, 00:13:06 C>* 100.65.64.164/30 is directly connected, eth10, 00:13:24 *root@r1:~# ping -I eth10 100.65.64.161ping: Warning: source address might be selected on device other than eth10.PING 100.65.64.161 (100.65.64.161) from 100.65.64.138 eth10: 56(84) bytes of data.^C* I don't understand this message at all, why it always picking a wrong address when I try to ping it. Can anyone give insights to this? -- -- Rakesh Madupu 2xJNCIE - SP/DC / CCIE-SP#47613 https://r2079.wordpress.com

1 0

Why two duplicate route-map exist in bgpd and zebra ?
by Simon Jones 21 Apr '20

21 Apr '20

Hi all, I'm using quagga-0.99, I set a route-map by vtysh like this: vtysh# prefix-list ARP2HOST_PL3 ... > vtysh# route-map ARP2HOST_RM2 deny sequence 6 > vtysh# match interface lo > vtysh# route-map ARP2HOST_RM2, permit, sequence 10 > vtysh# match ip address prefix-list ARP2HOST_PL3 But I found there are two SAME route-map exist in zebra and bgpd, like this: vtysh# show route-map > ZEBRA: > route-map ARP2HOST_RM2, deny, sequence 6 > Match clauses: > interface eth0 > Set clauses: > Call clause: > Action: > Exit routemap > route-map ARP2HOST_RM2, permit, sequence 10 > Match clauses: > ip address prefix-list ARP2HOST_PL3 > Set clauses: > Call clause: > Action: > Exit routemap > BGP: > route-map ARP2HOST_RM2, deny, sequence 6 > Match clauses: > Set clauses: > Call clause: > Action: > Exit routemap > route-map ARP2HOST_RM2, permit, sequence 10 > Match clauses: > ip address prefix-list ARP2HOST_PL3 > Set clauses: > metric 13 > community 0:100 > Call clause: > Action: > Exit routemap And when I use command > vtysh# redistribute static route-map ARP2HOST_RM2 the redistribute will NOT process any static route SOMETIME, not always !!! Then I compare by add route-map through zebra.conf and bgpd.conf, like this: > zebra.conf: > route-map ARP2HOST_RM2 deny sequence 6 > match interface lo > > bgpd.conf: > prefix-list ARP2HOST_PL3 ... > route-map ARP2HOST_RM2, permit, sequence 10 > match ip address prefix-list ARP2HOST_PL3 And show route-map result beome: > vtysh# show route-map > ZEBRA: > route-map ARP2HOST_RM2, deny, sequence 6 > Match clauses: > interface eth0 > Set clauses: > Call clause: > Action: > Exit routemap > BGP: > route-map ARP2HOST_RM2, permit, sequence 10 > Match clauses: > ip address prefix-list ARP2HOST_PL3 > Set clauses: > metric 13 > community 0:100 > Call clause: > Action: > Exit routemap Then the redistribute will work. focus on code, I guess ALL of zebra(zebra_routemap.c) and bgpd(bgp_routemap.c) will process route-map from vtysh command, which cause this bug? If it is, how to set route-map correctly by vtysh? Thanks !!! ---- Simon Jones

3 3

IS-IS Error
by Mark Tinka 19 Apr '20

19 Apr '20

Hi all. I'm almost there getting IS-IS to work without issue. I'm now faced with the following error log: 2020/04/17 10:02:01 ISIS: IS-IS bpf: could not transmit packet on em0: Input/output error 2020/04/17 10:02:01 ISIS: [EC 67108865] ISIS-Snp (1): Send L2 PSNP on em0 failed This repeats every second. Anyone know what this could be? Systems is FreeBSD-12.1-RELEASE-p3. Despite the error, IS-IS is running and routing is good, talking to a Cisco IOS XE implementation on the other side. So the error is throwing me off. Mark.

2 2

fd80 prefix allocation
by Tran (US), Katherine K 16 Apr '20

16 Apr '20

Hello, Does anyone know how FRR treats "fd80" prefixes? My configuration uses "fd80" prefixes as Unique Local IPv6 Unicast Addresses (IETF RFC 4193), which can be routed. But, somehow, FRR changes these "fd80" addresses to "fe80". Thanks, Katherine

3 7

getting IS-IS routerIPs in BGP-LS
by Colin Zeidler 16 Apr '20

16 Apr '20

Hi, I am trying to monitor an IS-IS network using BGP-LS to receive the network topology. In IS-IS the LSP typically contains a routerIP entry that provides a IP address on the device the LSP is about. This is useful when monitoring the network as it provides an IP that can be queried with SNMP for more information about the given router. In BGP-LS the RFCs show that there is a Node attribute for the IPv4 address/ID of a router, but this is not populated when distributing an IS-IS network (cisco router sending BGP-LS). Is there a known way to configure a router to provide an IP address as part of the BGP-LS node attributes when distributing IS-IS linkstate? My BGP-LS setup involves a cisco ISIS network with 1 router per area, configured with bgp-ls, peered with frr such that frr will receive the BGP-LS messages (but not do anything with them) Currently my solution involves looking at the advertised prefixes. Prefixes with a IS-IS level of 1, and a /32 mask are an IP address that exists on the named router and can be pinged or queried with SNMP. This works until we encounter a L2-only IS-IS router, as the level2 advertised prefixes can exist from any other router in the area, not just interfaces on the device. A potential workaround for this issue with the l2-only routers I think is to check for the prefix with the lowest metric cost and use that one, though this runs the risk of a local /32 prefix being configured with a higher cost than the links + a neighbors /32 (is this something that would realistically happen?) and choosing the wrong IP address. Are there any potential issues with that solution? Thanks, Colin

1 1

FRR 7.2 or 7.3
by Sébastien 65 15 Apr '20

15 Apr '20

Hi, I plan to replace a production router with Quagga... Which version of FRR (7.2.1 or 7.3) you advise me to go into production (BGP/OSPF ipv4 + ipv6 full feed) ? I'm going to use Debian with FRR. Thanks !

2 2

how to trigger a graceful restart for a bgp session
by Xinyong Wang 13 Apr '20

13 Apr '20

hi, if we just did `systemctl restart frr`, the bgpd process will be stopped by `kill -2`, and it would send cease/peer de-config notification to its peer. its peer will flush the routes insteading of make them stale. if we did `neighbor xxxxx shutdown`,then `no neighbor xxxxxx shutdown` via vtysh, it would send cease/administrative shutdown notification. graceful restart did not work too. Now, we have changed frrcommon.sh by 's/kill -2/kill -9/g', when bgpd is killed by `kill -9`, it would not send any notifications, and this time, graceful restart functionality works, its peer makes the routes be stale and forwarding is perserverd during frr restarting. however, we think this approach is ugly. So can anyone tell us what is the corrent approach to restart bgp session gracefully. we have to restart bgp session for upgrading to a new version or changing some parameters, etc. thanks! best regards, Xinyong

2 3

FRR Adding IPv6 Routes
by Tran (US), Katherine K 09 Apr '20

09 Apr '20

Hello, I am trying to switch from Quagga to FRR, but I am having issues adding distributed IPv6 routes. Although the IPv6 routes get added, they keep toggling between being added and removed. This did not occur while using Quagga. A difference between the added IPv6 routes of Quagga and FRR was that (1) the Quagga routes are by protocol zebra and (2) the FRR routes are by protocol 186, which I deduced to be bgpd. This can be seen by initiating the command "ip -6 ro sh". Quagga ---------- 2001:XXXX:X:X::/64 via fe80::1:2 dev eth0 proto zebra metric 1024 pref medium FRR ----- 2001:XXXX:X:X::/64 via fe80::1:2 dev eth0 proto 186 metric 20 pref medium I have a simple BGP configuration using Autonomous System Border Router (ASBR). I am running the daemons (zebra, staticd, bgpd) through the all-encompassing config file frr.conf, and I have also tried separating each daemon out to a separate config file and running them separately. I used the same commands from the Quagga confile files, and I added the additional staticd commands. I've looked at all the generated log files, and I can't seem to find anything substantial to investigation. Would anyone have an idea why these IPv6 routes keep toggling from being added and removed? Any additional suggestions on troubleshooting steps? Thank you, Katherine

5 13

IS-IS Complains When Loopback Interface is in Play
by Mark Tinka 09 Apr '20

09 Apr '20

Hi all. When I add my Loopback interface to isisd.conf and restart it, it throws the below: 2020/04/07 14:35:44 errors: ISIS: libyang: Missing required element "area-tag" in "isis". (/frr-interface:lib/interface[name='lo0'][vrf='default']/frr-isisd:isis) 2020/04/07 14:35:44 warnings: ISIS: [EC 100663337] nb_candidate_commit_prepare: failed to validate candidate configuration % Configuration failed: validation error. A bit of Googling indicated that "router isis 1" would need to come first in the configuration, since some previous versions of FRR processed the files line by line, and not atomically. But even after doing that, I still get the same error; but get this, ONLY when I add "interface lo0" to the configuration. Without that, and with just the physical interface in the configuration, IS-IS starts up fine. Any thoughts? System FRR 7.3 on FreeBSD-12.1. Thanks. Mark.

1 1