summaryrefslogtreecommitdiffstats
path: root/zebra/redistribute.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* zebra: Add more vrf name to debugsDonald Sharp2024-09-111-2/+3
| | | | | | | | | Trying to debug some cross vrf stuff in zebra and frankly it's hard to grep the file for the routes you are interested in. Let's clean this up some and get a bit better information for us developers Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Move nhg reinstallation into if_up properDonald Sharp2024-02-081-4/+0
| | | | | | | | | | | | The function call in to zebra_interface_nhg_reinstall is an action that takes place on interface up events *not* when the connected addresses are added to a system. this will prevent this function being called when new connected interfaces come alive that is an independent operation of the interface coming up. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: SA incorrectly believes a NULL pointerDonald Sharp2024-01-091-0/+8
| | | | | | | | | SA has decided that old_re could be a NULL pointer even though the zebra_redistribute_check function checks for NULL and returns false that would not allow a NULL pointer deref. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #12600 from donaldsharp/local_routesRuss White2023-12-051-3/+4
|\ | | | | *: Introduce Local Host Routes to FRR
| * *: Introduce Local Host Routes to FRRDonald Sharp2023-11-011-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create Local routes in FRR: S 0.0.0.0/0 [1/0] via 192.168.119.1, enp39s0, weight 1, 00:03:46 K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:03:51 O 192.168.119.0/24 [110/100] is directly connected, enp39s0, weight 1, 00:03:46 C>* 192.168.119.0/24 is directly connected, enp39s0, 00:03:51 L>* 192.168.119.224/32 is directly connected, enp39s0, 00:03:51 O 192.168.119.229/32 [110/100] via 0.0.0.0, enp39s0 inactive, weight 1, 00:03:46 C>* 192.168.119.229/32 is directly connected, enp39s0, 00:03:46 Create ability to redistribute local routes. Modify tests to support this change. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | Merge pull request #14741 from donaldsharp/zebra_h_cleanupDonatas Abraitis2023-11-081-0/+1
|\ \ | | | | | | Zebra h cleanup
| * | *: Move distance related defines into their own headerDonald Sharp2023-11-071-0/+1
| | | | | | | | | | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | | Merge pull request #14698 from ↵Russ White2023-11-071-0/+3
|\ \ \ | |/ / |/| | | | | | | | opensourcerouting/fix/remove_static_arp_entries_on_ifdown_events zebra: Remove static ARP entries on interface down events
| * | zebra: Remove static ARP entries on interface down eventsDonatas Abraitis2023-11-061-0/+3
| |/ | | | | | | | | | | | | Without this patch, static ARP entries remain active even if the interface is down, but the kernel already removed them. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* / zebra: Remove vrf_id check against VRF_DEFAULT for zebra_redistribute()Donatas Abraitis2023-11-011-4/+0
|/ | | | | | | | | | A dead code. When `is_table_direct` is true, vrf_id is always VRF_DEFAULT. So this block is never called. CID 1570863. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* zebra: add redistribute table-direct supportPhilippe Guibert2023-10-201-15/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Redistributing routes from a specific routing table to a particular routing protocol necessitates copying route entries to the main routing table using the "ip import-table" command. Once copied, these routes are assigned a distinct "table" route type, which the "redistribute table" command of the routing protocol then picks up. For illustration, here is a configuration that showcases the use of "import-table" and "redistribute": > # show running-config > [..] > ip route 172.31.0.10/32 172.31.1.10 table 100 > router bgp 65500 > address-family ipv4 unicast > redistribute table 100 > exit-address-family > exit > ip import-table 100 > > # show ip route vrf default > [..] > T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05 However, this method has inherent constraints: - The 'import-table' parameter only handles route table id up to 252. The 253/254/255 table ids are reserved in the linux system, and adding other table IDs above 255 leads to a design issue, where the size of some tables is directly related to the maximum number of table ids to support. - Duplicated route entries might interfere with original default table routes, leading to potential conflicts. There is no guarantee that the zebra RIB will favor these duplicated entries during redistribution. - There are cases where the table ID can be checked independently of the default routing table, as seen in Linux where the "ip rule" command is able to divert traffic to that routing table. In that case, there is no need to duplicate route entries in the default routing table. To overcome these issues, a new redistribution type is proposed to redistribute route entries directly from a specified routing table, eliminating the need for an initial import into the default table. Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It allows sending routes from a given non default table ID from zebra to a routing daemon. The destination routing protocol table must be the default table. The redistributed route inherit from the default distance value of 14: this is the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* zebra: Free nexthop_groupKeelan102023-10-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `ng` was not properly freed, leading to a memory leak. The commit calls `nexthop_group_delete` to free memory associated with `ng`. The ASan leak log for reference: ``` *********************************************************************************** Address Sanitizer Error detected in isis_topo1.test_isis_topo1/r5.asan.zebra.24308 ================================================================= ==24308==ERROR: LeakSanitizer: detected memory leaks Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105 #2 0x7f4f47559526 in nexthop_group_new lib/nexthop_group.c:270 #3 0x562ded6a39d4 in zebra_add_import_table_entry zebra/redistribute.c:681 #4 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972 #5 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993 #6 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860 #7 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138 #8 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178 #9 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228 #10 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266 #11 0x7f4f475dc7f2 in event_call lib/event.c:1969 #12 0x7f4f4751f347 in frr_run lib/libfrr.c:1213 #13 0x562ded69e818 in main zebra/main.c:486 #14 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 152 byte(s) in 1 object(s) allocated from: #0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105 #2 0x7f4f475510ad in nexthop_new lib/nexthop.c:376 #3 0x7f4f475539c5 in nexthop_dup lib/nexthop.c:914 #4 0x7f4f4755b27a in copy_nexthops lib/nexthop_group.c:444 #5 0x562ded6a3a1c in zebra_add_import_table_entry zebra/redistribute.c:682 #6 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972 #7 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993 #8 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860 #9 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138 #10 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178 #11 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228 #12 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266 #13 0x7f4f475dc7f2 in event_call lib/event.c:1969 #14 0x7f4f4751f347 in frr_run lib/libfrr.c:1213 #15 0x562ded69e818 in main zebra/main.c:486 #16 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 184 byte(s) leaked in 2 allocation(s). *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
* *: remove ZEBRA_INTERFACE_VRF_UPDATEanlan_cs2023-10-071-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | Currently when one interface changes its VRF, zebra will send these messages to all daemons in *order*: 1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF ) 2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF ) 3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF ) When daemons deal with `VRF_UPDATE`, they use `zebra_interface_vrf_update_read()->if_lookup_by_name()` to check the interface exist or not in old VRF. This check will always return *NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't find this interface in old VRF. Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough, they will deal with RB tree, so don't send this `VRF_UPDATE` message when vrf changes. Since all daemons have good mechanism to deal with changing vrf, and don't use this `VRF_UPDATE` mechanism. So, it is safe to completely remove all the code with `VRF_UPDATE`. Signed-off-by: anlan_cs <anlan_cs@tom.com>
* zebra: Make main routing table (RT_TABLE_MAIN) configurableMartin Pels2023-08-221-1/+1
| | | | Signed-off-by: Martin Pels <mpels@ripe.net>
* zebra: Remove tag from zebra_rmap_objDonald Sharp2023-08-111-1/+1
| | | | | | | The tag value in all cases was being set to the re->tag. re is already stored, so let's just use that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Remove instance from zebra_rmap_obj data structureDonald Sharp2023-08-111-2/+1
| | | | | | | | In all cases the instance is derived from the re pointer and since the re pointer is already stored, let's just remove it from the game and cut to the chase. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Replace source_protocol with just using re in route map objectDonald Sharp2023-08-111-2/+2
| | | | | | | Replace the source_protocol with just saving a pointer to the re in the `struct zebra_rmap_obj` data structure. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: import table match against interface name could failDonald Sharp2023-08-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If an import table route-map is trying to match against a particular interface, The code is matching against the actual vrf the route entry is in -vs- the vrf the nexthop entry is in. Let's modify the code to actually allow the import table entry to match against the nexthops vrf. Not working: ip import-table 91 ip import-table 93 route-map FOO no service integrated-vtysh-config ! debug zebra events ! interface green ip address 192.168.4.3/24 exit ! route-map FOO permit 10 match interface green exit eva# show ip route 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, r - rejected, b - backup t - trapped, o - offload failure K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp13s0, 1d10h07m T[91]>* 1.2.3.5/32 [15/0] via 192.168.119.1, enp13s0, 00:00:05 K>* 169.254.0.0/16 [0/1000] is directly connected, virbr0 linkdown, 1d16h34m C>* 192.168.44.0/24 is directly connected, virbr1, 01:30:51 C>* 192.168.45.0/24 is directly connected, virbr2, 01:30:51 C>* 192.168.119.0/24 is directly connected, enp13s0, 1d16h34m C>* 192.168.122.0/24 is directly connected, virbr0 linkdown, 01:30:51 eva# show ip route table 91 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, r - rejected, b - backup t - trapped, o - offload failure VRF default table 91: K>* 1.2.3.5/32 [0/0] via 192.168.119.1, enp13s0, 00:00:15 eva# show ip route table 93 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, r - rejected, b - backup t - trapped, o - offload failure VRF default table 93: K * 1.2.3.4/32 [0/0] via 192.168.4.5, green (vrf green), 00:03:05 Working: eva# show ip route 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, r - rejected, b - backup t - trapped, o - offload failure K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp13s0, 00:03:09 T[93]>* 1.2.3.4/32 [15/0] via 192.168.4.5, green (vrf green), 00:02:21 T[91]>* 1.2.3.5/32 [15/0] via 192.168.119.1, enp13s0, 00:02:26 K>* 169.254.0.0/16 [0/1000] is directly connected, virbr0, 00:03:09 C>* 192.168.44.0/24 is directly connected, virbr1, 00:03:09 C>* 192.168.45.0/24 is directly connected, virbr2, 00:03:09 C>* 192.168.119.0/24 is directly connected, enp13s0, 00:03:09 C>* 192.168.122.0/24 is directly connected, virbr0, 00:03:09 eva# show ip route table 91 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, r - rejected, b - backup t - trapped, o - offload failure VRF default table 91: K * 1.2.3.5/32 [0/0] via 192.168.119.1, enp13s0, 00:03:12 eva# show ip route table 93 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, r - rejected, b - backup t - trapped, o - offload failure VRF default table 93: K * 1.2.3.4/32 [0/0] via 192.168.4.5, green (vrf green), 00:03:14 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: fix imported static routes deletionPhilippe Guibert2023-07-121-0/+2
| | | | | | | | | | | | | | | When unconfiguring 'no import <table>', a static route imported from a routing table number is never deleted. When importing a route from a given table, a default distance of 15 is applied. At the time of deletion, when trying to compare the original route with the new one, the distance does not match, because the static route applies a default distance of 1. If the imported route has the distance set, unset the distance flag to avoid comparing it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* zebra: adjust one debug infoanlan_cs2023-07-111-6/+5
| | | | | | | | | | | | | | | | | Adjust one debug info, separate the ip address from it. Just like it is processed in `redistribute_update()`. Before: ``` 34:1375.75.75.75/32: Redist del: re 0x55c1112067e0 (0:static), new re 0x55c1112de7c0 (0:static) ``` After: ``` (34:13):75.75.75.75/32: Redist del: re 0x55c1112067e0 (0:static), new re 0x55c1112de7c0 (0:static) ``` Signed-off-by: anlan_cs <vic.lan@pica8.com>
* *: Rearrange vrf_bitmap_X api to reduce memory footprintDonald Sharp2023-06-261-9/+9
| | | | | | | | | | | | | | | | | | | | When running all daemons with config for most of them, FRR has sharpd@janelle:~/frr$ vtysh -c "show debug hashtable" | grep "VRF BIT HASH" | wc -l 3570 3570 hashes for bitmaps associated with the vrf. This is a very large number of hashes. Let's do two things: a) Reduce the created size of the actually created hashes to 2 instead of 32. b) Delay generation of the hash *until* a set operation happens. As that no hash directly implies a unset value if/when checked. This reduces the number of hashes to 61 in my setup for normal operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: re-install nhg on interface upAshwini Reddy2023-05-051-0/+4
| | | | | | | | | | | | | | | | | | | | | Intermittently zebra and kernel are out of sync when interface flaps and the add's/dels are in same processing queue and zebra assumes no change in nexthop. Hence we need to bring in a reinstall to kernel of the nexthops and routes to sync their states. Upon interface flap kernel would have deleted NHGs associated to a interface (the one flapped), zebra retains NHGs for 3 mins even though upper layer protocol removes the nexthops (associated NHG). As part of interface address add , re-add singleton NHGs associated to interface. Ticket: #3173663 Issue: 3173663 Signed-off-by: Ashwini Reddy <ashred@nvidia.com> Signed-off-by: Chirag Shah <chirag@nvidia.com>
* zebra: Use zebra_vrf_lookup_by_id when we canDonald Sharp2023-03-281-1/+1
| | | | | | Let's make this as consistent as is possible. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #12780 from opensourcerouting/spdx-license-idDonald Sharp2023-02-171-16/+1
|\ | | | | *: convert to SPDX License identifiers
| * *: auto-convert to SPDX License IDsDavid Lamparter2023-02-091-16/+1
| | | | | | | | | | | | Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* | zebra: Use string for type instead of numberDonald Sharp2023-02-131-2/+4
|/ | | | | | Let's make it easier to debug instead of guessing Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Create a zebra_rib_route_entry_new function and use itDonald Sharp2022-08-171-9/+4
| | | | | | Abstract the creation of the route_entry and use it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Fix ships in the night issueDonald Sharp2022-02-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | When using wait for install there exists situations where zebra will issue several route change operations to the kernel but end up in a state where we shouldn't be at the end due to extra data being received. Example: a) zebra receives from bgp a route change, installs sends the route to the kernel. b) zebra receives a route deletion from bgp, removes the struct route entry and then sends to the kernel a deletion. c) zebra receives an asynchronous notification that (a) succeeded but we treat this as a new route. This is the ships in the night problem. In this case if we receive notification from the kernel about a route that we know nothing about and we are not in startup and we are doing asic offload then we can ignore this update. Ticket: #2563300 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Add table and instance data to debugs for redistribute_deleteDonald Sharp2022-01-181-5/+20
| | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Cleanup temp variable usage in debugs for %pFXDonald Sharp2022-01-181-10/+6
| | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Modify zsend_redistribute_route to receive struct route_nodeDonald Sharp2022-01-181-22/+12
| | | | | | | The function zsend_redistribute_route uses the prefix and source prefix. Just pass in the route_node instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Pass rn to zebra_redistribute_check insteadDonald Sharp2022-01-181-13/+11
| | | | | | | FRR is using struct prefix and afi to be passed around. When all that is needed is the route node. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Convert redistribute_update to use a route_nodeDonald Sharp2022-01-181-16/+14
| | | | | | | | | FRR is passing around a bunch of data that is encapsulated within the route node. Let's just pass that around instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Convert redistribute_delete to use a route_nodeDonald Sharp2022-01-181-17/+14
| | | | | | | FRR is passing around a bunch of data that is encapsulated within the route node. Let's just pass that around instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Do not allow instance redistribution to happen no matter whatDonald Sharp2022-01-181-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you have this setup: router ospf 3 redistribute sharp ! and then install: sharp install route 4.5.6.7 nexthop 192.168.100.1 1 sharp install route 4.5.6.8 nexthop 192.168.100.1 1 instance 3 sharp install route 4.5.6.9 nexthop 192.168.100.1 1 instance 4 The .8 and .9 routes are auto redistributed into ospf instance 3: eva# show ip ospf data OSPF Instance: 3 OSPF Router with ID (192.168.122.1) AS External Link States Link ID ADV Router Age Seq# CkSum Route 4.5.6.7 192.168.122.1 13 0x80000001 0x477c E2 4.5.6.7/32 [0x0] 4.5.6.8 192.168.122.1 5 0x80000001 0x3d85 E2 4.5.6.8/32 [0x0] 4.5.6.9 192.168.122.1 5 0x80000001 0x338e E2 4.5.6.9/32 [0x0] This cannot be correct behavior. When redistributing in the absense of an instance number the default instance of 0 should be used and should be the only route redistributed. Here is the correct behavior: eva# show ip route 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, r - rejected, b - backup t - trapped, o - offload failure K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:00:28 D>* 4.5.6.7/32 [150/0] via 192.168.100.1, virbr1, weight 1, 00:00:02 D[3]>* 4.5.6.8/32 [150/0] via 192.168.100.1, virbr1, weight 1, 00:00:02 D[4]>* 4.5.6.9/32 [150/0] via 192.168.100.1, virbr1, weight 1, 00:00:02 C>* 192.168.100.0/24 is directly connected, virbr1, 00:00:28 C>* 192.168.110.0/24 is directly connected, virbr2, 00:00:28 C>* 192.168.119.0/24 is directly connected, enp39s0, 00:00:28 C>* 192.168.122.0/24 is directly connected, virbr0, 00:00:28 eva# show ip ospf data OSPF Instance: 3 OSPF Router with ID (192.168.122.1) AS External Link States Link ID ADV Router Age Seq# CkSum Route 4.5.6.7 192.168.122.1 6 0x80000001 0x477c E2 4.5.6.7/32 [0x0] Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Add hint to what instance we are looking atDonald Sharp2022-01-181-6/+6
| | | | | | | | | FRR allows redistribution to a client with a specific instance in mind. The code was not allowing you to figure out what instance was being looked at. So let's clarify this in the debugs. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: cleanup ifp->vrf_idIgor Ryzhov2021-11-221-16/+16
| | | | | | | Since f60a1188 we store a pointer to the VRF in the interface structure. There's no need anymore to store a separate vrf_id field. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
* zebra: Do not allow redistribution for non-vrf tablesDonald Sharp2021-07-201-0/+6
| | | | | | | | | | | | | | | | | Current code was allowing redistribution of kernel routes from the non-default non vrf tables once FRR was already up and running. In the case where we add `redistribute kernel` in an upper level protocol we never consider the non-default vrf or non-vrf tables so it is never accepted. In the case where a kernel route is added after `redistribute kernel` is already in place we were never looking at the fact that the route was in a non-default non-vrf table. This code fixes that issue. Fixes: #9073 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Revert "bgpd: vrf route leaking, fix vrf redistribute"Igor Ryzhov2021-05-091-6/+11
| | | | This reverts commit 6b2433c63f7fd3027cea8e06ca45f85bd3eea6f2.
* zebra: Allow redistribution for routes selectedDonald Sharp2021-05-041-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current code has an inconsistent behavior with redistribute routes. Suppose you have a kernel route that is being read w/ a distance of 255: eva# show ip route kernel 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, r - rejected, b - backup t - trapped, o - offload failure K>* 0.0.0.0/0 [0/100] via 192.168.161.1, enp39s0, 00:06:39 K>* 4.4.4.4/32 [255/8192] via 192.168.161.1, enp39s0, 00:01:26 eva# If you have redistribution already turned on for kernel routes you will be notified of the 4.4.4.4/32 route. If you turn on kernel route redistribution watching after the 4.4.4.4/32 route has been read by zebra you will never learn of it. There is no need to look for infinite distance in the redistribution code. Either we are selected or not. In other words non kernel routes with an 255 distance are never installed so the checks were pointless. So let's just remove the distance checking and tell interested parties about the 255 kernel route if it exists. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: debug log for redistribute_delEmanuele Di Pascale2021-04-261-0/+8
| | | | | | | We're firing an event debug log for zebra_redistribute_add, but not one for zebra_redistribute_delete. Let's make it symmetric. Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
* bgpd: vrf route leaking, fix vrf redistributeAbhinay Ramesh2021-04-071-11/+6
| | | | | | | | | | | | | | | | | | Description: After FRR restart, routes are not getting redistributed; when routes added first and then 'redistribute static' cmd is issued. During the frr restart, vrf_id will be unknown, so irrespective of redistribution, we set the redistribute vrf bitmap. Later, when we add a route and then issue 'redistribute' cmd, we check the redistribute vrf bitmap and return CMD_WARNING; zebra_redistribute_add also checks the redistribute vrf bitmap and returns. Instead of checking the redistribute vrf bitmap, always set it anyways. Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com> Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
* zebra: kill zebra_memory.h, use MTYPE_STATICDavid Lamparter2021-03-221-1/+0
| | | | | | | This one also needed a bit of shuffling around, but MTYPE_RE is the only one left used across file boundaries now. Signed-off-by: David Lamparter <equinox@diac24.net>
* *: remove remaining severity prefixesDavid Lamparter2021-03-141-1/+1
| | | | | | Having a "warning:" prefix on a debug message is particularly dumb... Signed-off-by: David Lamparter <equinox@diac24.net>
* *: remove tabs & newlines from log messagesDavid Lamparter2021-02-141-2/+2
| | | | | | | Neither tabs nor newlines are acceptable in syslog messages. They also break line-based parsing of file logs. Signed-off-by: David Lamparter <equinox@diac24.net>
* Revert "zebra: When shutting down an interface immediately notify about rnh"Donald Sharp2020-12-121-1/+1
| | | | This reverts commit 0aaa722883245c2109d9856ca0656749860fc579.
* :* Convert prefix2str to %pFXDonatas Abraitis2020-10-221-36/+24
| | | | Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
* zebra: When shutting down an interface immediately notify about rnhDonald Sharp2020-08-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Imagine a situation where a interface is bouncing up/down. The interface comes up and daemons like pbr will get a nht tracking callback for a connected interface up and will install the routes down to zebra. At this same time the interface can go down. But since zebra is busy handling route changes ( from pbr ) it has not read the netlink message and can get into a situation where the route resolves properly and then we attempt to install it into the kernel( which is rejected ). If the interface bounces back up fast at this point, the down then up netlink message will be read and create two route entries off the connected route node. Zebra will then enqueue both route entries for future processing. After this processing happens the down/up is collapsed into an up and nexthop tracking sees no changes and does not inform any upper level protocol( in this case pbr ) that nexthop tracking has changed. So pbr still believes the nexthops are good but the routes are not installed since pbr has taken no action. Fix this by immediately running rnh when we signal a connected route entry is scheduled for removal. This should cause upper level protocols to get a rnh notification for the small amount of time that the connected route was bouncing around like a madman. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* zebra: Add table id to debug outputDonald Sharp2020-08-191-8/+8
| | | | | | | | | There are a bunch of places where the table id is not being outputed in debug messages for routing changes. Add in the table id we are operating on. This is especially useful for the case where pbr is working. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Zebra: Default route distribute handling.Santosh P K2020-04-071-63/+47
| | | | | | | | When default route is requested from client, default route is sent to client if present. When route gets deleted then delete is sent to clients. Signed-off-by: Santosh P K <sapk@vmware.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-06 05:27:09 +0100