summaryrefslogtreecommitdiff
path: root/zebra/zebra_dplane.c
AgeCommit message (Collapse)Author
2021-11-17zebra: return void for dplane_ctx_get_pbr_iptableDonald Sharp
The only time this function ever failed is when the developer does not pass in a usable pointer to place the data in. Change it to an assert to signify to the end developer that is what we want and then remove all the if checks for failure Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-11-17zebra: dplane_ctx_get_pbr_ipset should return voidDonald Sharp
The function call dplane_ctx_get_pbr_ipset only returns false when the calling function fails to pass in a valid ipset pointer. This should be an assertion issue since it's a programming issue as opposed to an actual run time issue. Change the function call parameter to not return a bool on success/fail for a compile time decision. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-11-03zebra: update dataplane flowspec address family in ipset_infoPhilippe Guibert
It is needed for the ipset entry to know for which address family this ipset entry applies to. Actually, the family is in the original ipset structure and was not passed as attribute in the dataplane ipset_info structure. Add it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-11-03zebra: fix flowspec ipset operationsPhilippe Guibert
When injecting an ipset entry into the zebra dataplane context, the ipset name is stored in a separate structure. This will permit the flowspec plugin to be able to know which ipset has to be appended with relevant ipset entry. The problem was that the zebra dataplane objects related to ipset entries is made up of an union between the ipset structure and the ipset info structure. This was implying that the two structures were on the same memory zone, and when extracting the data stored, the data were incomplete. Fix this by replacing the union structure by a defined struct. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-10-07pbrd: add vlan actions to vtyEli Baum
Signed-off-by: Eli Baum <ebaum@mitre.org>
2021-09-14zebra: use the dataplane to read netlink intf addr changesMark Stapp
Read incoming interface address change notifications in the dplane pthread; enqueue the events to the main pthread for processing. This is netlink-only for now - the bsd kernel socket path remains unchanged. Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
2021-09-14zebra: add new dplane op codes for interface addr eventsMark Stapp
Add new dplane op values for incoming interface address add and delete events. Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
2021-09-14zebra: add intf accessors for dplane contextsMark Stapp
Add a few more setters for interface data in dplane contexts. Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
2021-09-14zebra: add inbound netlink socket for dataplaneMark Stapp
Add a new netlink socket for events coming in from the host OS to the dataplane system for processing. Rename the existing outbound dplane socket. Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
2021-09-02zebra: Convert to `struct zebra_lsp` as per our internal standardDonald Sharp
We do not use typedef's to talk about structures as per our standard. Fixing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-09-02zebra: Convert to `struct zebra_nhlfe` as per our internal standardDonald Sharp
We do not use typedef's to talk about structures as per our standard. Fixing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-09-02zebra: Convert to `struct zebra_l3nvi` as per our internal standardDonald Sharp
We do not use typedef's to talk about structures as per our standard. Fixing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-06zebra: Remove rib_lookup_and_pushup functionDonald Sharp
The rib_lookup_and_pushup function, from what I can tell, was used more when static route processing and connected routes were more closely integrated in zebra. The goal was when we were adding a new address to remove the connected route and then allow processing of the new address. With the re-org a few years ago to seperate out connected routes as well as static routes, I believe this is no longer needed. on BSD, without this code change we have this log: 2021/08/05 14:33:38 ZEBRA: [QEVVE-G3FQQ] rib_meta_queue_add: (0:0):10.40.30.0/24: queued rn 0x802022bb0 into sub-queue 4 2021/08/05 14:33:38 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 200 Type: RTM_DELETE 2021/08/05 14:33:38 ZEBRA: [V3NSB-BPKBD] Kernel: GATEWAY DONE PROTO1 2021/08/05 14:33:38 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 15 2021/08/05 14:33:38 ZEBRA: [MJD4M-0AAAR] Kernel: pid 53305, rtm_addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:33:38 ZEBRA: [Y9Y5K-JJ7NT] rtm_read: got rtm of type 2 (RTM_DELETE) addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:33:38 ZEBRA: [V17DT-1FJEN] kernel_rtm: 10.40.30.0/24: successfully did NH 9.8.6.7 2021/08/05 14:33:38 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 164 Type: RTM_NEWADDR 2021/08/05 14:33:38 ZEBRA: [V3NSB-BPKBD] Kernel: 2021/08/05 14:33:38 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 4664 2021/08/05 14:33:38 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST} 2021/08/05 14:33:38 ZEBRA: [M09CX-TKB4N] ifam_read_mesg: ifindex 1, ifname vtnet0, ifam_addrs {NETMASK,IFP,IFA,BRD}, ifam_flags 0x0, addr 10.40.30.1/24 broad 10.40.30.255 dst (unspec) gateway (unspec) 2021/08/05 14:33:38 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:0):10.40.30.0/24: Inserting route rn 0x802022bb0, re 0x8032973a0 (connected) existing 0x0, same_count 0 2021/08/05 14:33:38 ZEBRA: [Q4T2G-E2SQF] rib_add_multipath_nhe: dumping RE entry 0x8032973a0 for 10.40.30.0/24 vrf default(0) 2021/08/05 14:33:38 ZEBRA: [M5M58-9PD2R] 10.40.30.0/24: uptime == 1379355, type == 2, instance == 0, table == 0 2021/08/05 14:33:38 ZEBRA: [RVZMM-N7DME] 10.40.30.0/24: metric == 1, mtu == 0, distance == 0, flags == None status == None 2021/08/05 14:33:38 ZEBRA: [Q1NW5-NWY7P] 10.40.30.0/24: nexthop_num == 1, nexthop_active_num == 0 2021/08/05 14:33:38 ZEBRA: [TFHQ8-TC30H] 10.40.30.0/24: NH vtnet0[1] vrf default(0) with flags 2021/08/05 14:33:38 ZEBRA: [SCETK-GQ9E4] 10.40.30.0/24: dump complete 2021/08/05 14:33:38 ZEBRA: [QEVVE-G3FQQ] rib_meta_queue_add: (0:0):10.40.30.0/24: queued rn 0x802022bb0 into sub-queue 2 2021/08/05 14:33:38 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:?):10.40.30.0/24 (MRIB): Inserting route rn 0x802022f30, re 0x803297340 (connected) existing 0x0, same_count 0 2021/08/05 14:33:38 ZEBRA: [Q4T2G-E2SQF] rib_add_multipath_nhe: dumping RE entry 0x803297340 for 10.40.30.0/24 vrf default(0) 2021/08/05 14:33:38 ZEBRA: [M5M58-9PD2R] 10.40.30.0/24: uptime == 1379355, type == 2, instance == 0, table == 0 2021/08/05 14:33:38 ZEBRA: [RVZMM-N7DME] 10.40.30.0/24: metric == 1, mtu == 0, distance == 0, flags == None status == None 2021/08/05 14:33:38 ZEBRA: [Q1NW5-NWY7P] 10.40.30.0/24: nexthop_num == 1, nexthop_active_num == 0 2021/08/05 14:33:38 ZEBRA: [TFHQ8-TC30H] 10.40.30.0/24: NH vtnet0[1] vrf default(0) with flags 2021/08/05 14:33:38 ZEBRA: [SCETK-GQ9E4] 10.40.30.0/24: dump complete 2021/08/05 14:33:38 ZEBRA: [GCGMT-SQR82] rib_link: (0:?):10.40.30.0/24 (MRIB): rn 0x802022f30 adding dest 2021/08/05 14:33:38 ZEBRA: [QEVVE-G3FQQ] rib_meta_queue_add: (0:0):10.40.30.0/24 (MRIB): queued rn 0x802022f30 into sub-queue 2 2021/08/05 14:33:38 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 240 Type: RTM_ADD 2021/08/05 14:33:38 ZEBRA: [V3NSB-BPKBD] Kernel: UP PINNED 2021/08/05 14:33:38 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 0 2021/08/05 14:33:38 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:33:38 ZEBRA: [K0KVE-2GJA1] default(0:0):10.40.30.0/24: Processing rn 0x802022bb0 2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032973a0 (connected) status: Changed flags: None dist 0 metric 1 2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032970a0 (static) status: None flags: Recursion RR Distance dist 1 metric 0 2021/08/05 14:33:38 ZEBRA: [NYYJJ-0Q8QG] default(0:0):10.40.30.0/24: After processing: old_selected 0x0 new_selected 0x8032973a0 old_fib 0x0 new_fib 0x8032973a0 2021/08/05 14:33:38 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.40.30.0/24: Adding route rn 0x802022bb0, re 0x8032973a0 (connected) 2021/08/05 14:33:38 ZEBRA: [PP3BZ-RABJN] default(0:0):10.40.30.0/24: rn 0x802022bb0 dequeued from sub-queue 2 2021/08/05 14:33:38 ZEBRA: [K0KVE-2GJA1] default(0:0):10.40.30.0/24: Processing rn 0x802022f30 2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x803297340 (connected) status: Changed flags: None dist 0 metric 1 2021/08/05 14:33:38 ZEBRA: [NYYJJ-0Q8QG] default(0:0):10.40.30.0/24: After processing: old_selected 0x0 new_selected 0x803297340 old_fib 0x0 new_fib 0x803297340 2021/08/05 14:33:38 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.40.30.0/24: Adding route rn 0x802022f30, re 0x803297340 (connected) 2021/08/05 14:33:38 ZEBRA: [PP3BZ-RABJN] default(0:0):10.40.30.0/24: rn 0x802022f30 dequeued from sub-queue 2 2021/08/05 14:33:38 ZEBRA: [K0KVE-2GJA1] default(0:0):10.40.30.0/24: Processing rn 0x802022bb0 2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032973a0 (connected) status: Queued flags: Selected dist 0 metric 1 2021/08/05 14:33:38 ZEBRA: [RWCK7-TX4HT] default(0:0):10.40.30.0/24: Examine re 0x8032970a0 (static) status: None flags: Recursion RR Distance dist 1 metric 0 2021/08/05 14:33:38 ZEBRA: [NYYJJ-0Q8QG] default(0:0):10.40.30.0/24: After processing: old_selected 0x8032973a0 new_selected 0x8032973a0 old_fib 0x8032973a0 new_fib 0x8032973a0 2021/08/05 14:33:38 ZEBRA: [PP3BZ-RABJN] default(0:0):10.40.30.0/24: rn 0x802022bb0 dequeued from sub-queue 4 2021/08/05 14:33:38 ZEBRA: [GHWHS-ZKQM5] update_from_ctx: default(0:0):10.40.30.0/24: SELECTED, re 0x8032973a0 2021/08/05 14:33:38 ZEBRA: [TS3SH-1276M] default(0:0):10.40.30.0/24 update_from_ctx(): no fib nhg 2021/08/05 14:33:38 ZEBRA: [HKQXC-4STSK] default(0:0):10.40.30.0/24 update_from_ctx(): rib nhg matched, changed 'false' 2021/08/05 14:33:38 ZEBRA: [HBZNK-5H1X0] (0:0):10.40.30.0/24: Redist update re 0x8032973a0 (connected), old 0x0 (None) 2021/08/05 14:33:38 ZEBRA: [GHWHS-ZKQM5] update_from_ctx: default(0:0):10.40.30.0/24: SELECTED, re 0x8032973a0 2021/08/05 14:33:38 ZEBRA: [TS3SH-1276M] default(0:0):10.40.30.0/24 update_from_ctx(): no fib nhg 2021/08/05 14:33:38 ZEBRA: [HKQXC-4STSK] default(0:0):10.40.30.0/24 update_from_ctx(): rib nhg matched, changed 'false' 2021/08/05 14:33:38 ZEBRA: [HBZNK-5H1X0] (0:0):10.40.30.0/24: Redist update re 0x8032973a0 (connected), old 0x0 (None) With this code change: 2021/08/05 14:41:24 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:?):10.10.40.0/24: Inserting route rn 0x802022f30, re 0x8021cbe60 (static) existing 0x0, same_count 0 2021/08/05 14:41:24 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.10.40.0/24: Adding route rn 0x802022f30, re 0x8021cbe60 (static) 2021/08/05 14:41:24 ZEBRA: [V17DT-1FJEN] kernel_rtm: 10.10.40.0/24: successfully did NH 9.8.6.7 2021/08/05 14:41:24 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 200 Type: RTM_ADD 2021/08/05 14:41:24 ZEBRA: [V3NSB-BPKBD] Kernel: UP GATEWAY DONE PROTO1 2021/08/05 14:41:24 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 0 2021/08/05 14:41:24 ZEBRA: [MJD4M-0AAAR] Kernel: pid 60818, rtm_addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:41:24 ZEBRA: [Y9Y5K-JJ7NT] rtm_read: got rtm of type 1 (RTM_ADD) addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:41:24 ZEBRA: [TS3SH-1276M] default(0:0):10.10.40.0/24 update_from_ctx(): no fib nhg 2021/08/05 14:41:24 ZEBRA: [HKQXC-4STSK] default(0:0):10.10.40.0/24 update_from_ctx(): rib nhg matched, changed 'true' 2021/08/05 14:41:24 ZEBRA: [HBZNK-5H1X0] (0:0):10.10.40.0/24: Redist update re 0x8021cbe60 (static), old 0x0 (None) 2021/08/05 14:42:06 ZEBRA: [ZJ4AV-JEMJ3] dplane_intf_addr_set 2021/08/05 14:42:06 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 164 Type: RTM_NEWADDR 2021/08/05 14:42:06 ZEBRA: [V3NSB-BPKBD] Kernel: 2021/08/05 14:42:06 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 4664 2021/08/05 14:42:06 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST} 2021/08/05 14:42:06 ZEBRA: [M09CX-TKB4N] ifam_read_mesg: ifindex 1, ifname vtnet0, ifam_addrs {NETMASK,IFP,IFA,BRD}, ifam_flags 0x0, addr 10.10.40.3/24 broad 10.10.40.255 dst (unspec) gateway (unspec) 2021/08/05 14:42:06 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:0):10.10.40.0/24: Inserting route rn 0x802022f30, re 0x80308c4c0 (connected) existing 0x0, same_count 0 2021/08/05 14:42:06 ZEBRA: [MFYWV-KH3MC] rib_add_multipath_nhe: (0:?):10.10.40.0/24 (MRIB): Inserting route rn 0x802023160, re 0x80308c460 (connected) existing 0x0, same_count 0 2021/08/05 14:42:06 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 240 Type: RTM_ADD 2021/08/05 14:42:06 ZEBRA: [V3NSB-BPKBD] Kernel: UP PINNED 2021/08/05 14:42:06 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 0 2021/08/05 14:42:06 ZEBRA: [MJD4M-0AAAR] Kernel: pid 0, rtm_addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:42:06 ZEBRA: [RG9Y6-E93A0] default(0:0):10.10.40.0/24: Updating route rn 0x802022f30, re 0x80308c4c0 (connected) old 0x8021cbe60 (static) 2021/08/05 14:42:06 ZEBRA: [RT9DY-ZS2KN] default(0:0):10.10.40.0/24: Adding route rn 0x802023160, re 0x80308c460 (connected) 2021/08/05 14:42:06 ZEBRA: [THSYN-E2XFY][EC 100663299] rtm_write: write : Address already in use (48) 2021/08/05 14:42:06 ZEBRA: [RV5F2-MQGZG][EC 100663303] kernel_rtm: 10.10.40.0/24: rtm_write() unexpectedly returned -5 for command RTM_DELETE 2021/08/05 14:42:06 ZEBRA: [ZPR30-5G1FB] Kernel: Len: 200 Type: RTM_DELETE 2021/08/05 14:42:06 ZEBRA: [V3NSB-BPKBD] Kernel: UP PROTO1 2021/08/05 14:42:06 ZEBRA: [HDTM1-ENZNM] Kernel: message seq 1 2021/08/05 14:42:06 ZEBRA: [MJD4M-0AAAR] Kernel: pid 60818, rtm_addrs {DST,GATEWAY,NETMASK} 2021/08/05 14:42:06 ZEBRA: [XASXT-GF69Y] kernel_rtm: No useful nexthops were found in RIB prefix 10.10.40.0/24 2021/08/05 14:42:06 ZEBRA: [TS3SH-1276M] default(0:0):10.10.40.0/24 update_from_ctx(): no fib nhg 2021/08/05 14:42:06 ZEBRA: [HKQXC-4STSK] default(0:0):10.10.40.0/24 update_from_ctx(): rib nhg matched, changed 'false' 2021/08/05 14:42:06 ZEBRA: [HBZNK-5H1X0] (0:0):10.10.40.0/24: Redist update re 0x80308c4c0 (connected), old 0x8021cbe60 (static) netstat -rn: 10.10.40.0/24 link#1 U vtnet0 10.10.40.3 link#1 UHS lo0 show ip route: C>* 10.10.40.0/24 [0/1] is directly connected, vtnet0, 00:18:48 S 10.10.40.0/24 [1/0] via 9.8.6.7, vtnet0, weight 1, 00:19:30 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-02zebra: use strlcpy in dplane_rule_initMark Stapp
Use strlcpy for safety in dplane rule init api. Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
2021-07-27Merge pull request #9007 from donaldsharp/pbr_stuffJafar Al-Gharaibeh
add ability to match on proto to pbr
2021-07-19zebra: replace ipaddr2str in dplane moduleMark Stapp
Replace a couple of ipaddr2str calls with pIA in the dplane module. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2021-07-08zebra: Add ability for dataplane code to understand rule ip protocolsDonald Sharp
The zebra dplane needs to be taught about the rule ip_proto that can be installed. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-07-01*: Replace IPV4_MAX_PREFIXLEN to IPV4_MAX_BITLENDonatas Abraitis
Just drop IPV4_MAX_PREFIXLEN at all, no need keeping both. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-07-01*: Replace IPV6_MAX_PREFIXLEN to IPV6_MAX_BITLENDonatas Abraitis
Just drop IPV6_MAX_PREFIXLEN at all, no need keeping both. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-06-11zebra: update pw dataplane infoMark Stapp
Include the complete set of primary and backup nexthops from the resolving route for a pseudowire. Add accessors for that info. Modify the logic that creates the fib set of pw nexthops so that only installed, labelled nexthops are included. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2021-04-30zebra: collect gre information and push it when neededPhilippe Guibert
- gre keys are collected and stored locally. - when gre source set is requested, and the link interface configured is different, the gre information collected is pushed in the query, namely source ip or gre keys if present. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-04-30nhrp: Preserve mtu during interface up/down and tunnel source changePhilippe Guibert
preserve mtu upon interface flapping and tunnel source change. Signed-off-by:Reuben Dowle <reuben.dowle@4rf.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-04-30zebra: new dplane action to set gre link interfacePhilippe Guibert
This action is initiated by nhrp and has been stubbed when moving to zebra. Now, a netlink request is forged to set the link interface of a gre interface if that gre interface does not have already a link interface. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-04-13zebra, lib: replace ZEBRA_ROUTE_NEIGH with simplified versionPhilippe Guibert
do not add a new route type, and consider 0 as a value meaning that zebra should be the owner. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-04-13nhrp, zebra, lib: enforce usage of zapi_neigh_ip structurePhilippe Guibert
zapi_nbr structure is renamed to zapi_neigh_ip. Initially used to set a neighbor ip entry for gre interfaces, this structure is used to get events from the zebra layer to nhrp layer. The ndm state has been added, as it is needed on both sides. The zebra dplane layer is slightly modified. Also, to clarify what ZEBRA_NEIGH_ADD/DEL means, a rename is done: it is called now ZEBRA_NEIGH_IP_ADD/DEL, and it signified that this zapi interface permits to set link operations by associating ip addresses to link addresses. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-04-09zebra: move neighbor table configuration to dplane contextsPhilippe Guibert
Instead of directly configuring the neighbor table after read from zapi interface, a zebra dplane context is prepared to host the interface and the family where the neighbor table is updated. Also, some other fields are hosted: app_probes, ucast_probes, and mcast_probes. More information on those fields can be found on ip-ntable configuration. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-04-09zebra, lib: handle NEIGH_ADD/DELETE to zebra dataplane frameworkPhilippe Guibert
EVPN neighbor operations were already done in the zebra dataplane framework. Now that NHRP is able to use zebra to perform neighbor IP operations (by programming link IP operations), handle this operation under dataplane framework: - assign two new operations NEIGH_IP_INSTALL and NEIGH_IP_DELETE; this is reserved for GRE like interfaces: example: ip neigh add A.B.C.D lladdr E.F.G.H - use 'struct ipaddr' to store and encode the link ip address - reuse dplane_neigh_info, and create an union with mac address - reuse the protocol type and use it for neighbor operations; this permits to store the daemon originating this neighbor operation. a new route type is created: ZEBRA_ROUTE_NEIGH. - the netlink level functions will handle a pointer, and a type; the type indicates the family of the pointer: AF_INET or AF_INET6 if the link type is an ip address, mac address otherwise. - to keep backward compatibility with old queries, as no extension was done, an option NEIGH_NO_EXTENSION has been put in place - also, 2 new state flags are used: NUD_PERMANENT and NUD_FAILED. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-03-22zebra: kill zebra_memory.h, use MTYPE_STATICDavid Lamparter
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>
2021-03-17*: require semicolon after DEFINE_MTYPE & coDavid Lamparter
Back when I put this together in 2015, ISO C11 was still reasonably new and we couldn't require it just yet. Without ISO C11, there is no "good" way (only bad hacks) to require a semicolon after a macro that ends with a function definition. And if you added one anyway, you'd get "spurious semicolon" warnings on some compilers... With C11, `_Static_assert()` at the end of a macro will make it so that the semicolon is properly required, consumed, and not warned about. Consistently requiring semicolons after "file-level" macros matches Linux kernel coding style and helps some editors against mis-syntax'ing these macros. Signed-off-by: David Lamparter <equinox@diac24.net>
2021-03-14zebra: use printfrr exts in EVPN/VXLAN codeDavid Lamparter
Signed-off-by: David Lamparter <equinox@diac24.net>
2021-03-10zebra: move ipset and ipset_entry to zebra dplane contextsPhilippe Guibert
like it has been done for iptable contexts, a zebra dplane context is created for each ipset/ipset entry event. The zebra_dplane_ctx job is then enqueued and processed by separate thread. Like it has been done for zebra_pbr_iptable context, the ipset and ipset entry contexts are encapsulated into an union of structures in zebra_dplane_ctx. There is a specificity in that when storing ipset_entry structure, there was a backpointer pointer to the ipset structure that is necessary to get some complementary information before calling the hook. The proposal is to use an ipset_entry_info structure next to the ipset_entry, in the zebra_dplane context. That information is used for ipset_entry processing. The ipset name and the ipset type are the only fields necessary. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-03-04zebra: move iptable handling in zebra_dplanePhilippe Guibert
The iptable processing was not handled in remote dataplane, and was directly processed by the thread in charge of zapi calls. Now that call can be handled in the zebra_dplane separate thread. once a zebra_dplane_ctx is allocated for iptable handling, the hook call is performed later. Subsequently, a return code may be triggered to zclient interface if any problem occurs when calling the hook call. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-02-24zebra: support for lacp bypass with EVPN MHAnuradha Karuppiah
Feature overview: ================= A 802.3ad bond can be setup to allow lacp-bypass. This is done to enable servers to pxe boot without a LACP license i.e. allows the bond to go oper up (with a single link) without LACP converging. If an ES-bond is oper-up in an "LACP-bypass" state MH treats it as a non-ES bond. This involves the following special handling - 1. If the bond is in a bypass-state the associated ES is placed in a bypass state. 2. If an ES is in a bypass state - a. DF election is disabled (i.e. assumed DF) b. SPH filter is not installed. 3. MACs learnt via the host bond are advertised with a zero ESI. When the ES moves out of "bypass" the MACs are moved from a zero-ESI to the correct non-zero id. This is treated as a local station move. Implementation: =============== When (a) an ES is detached from a hostbond or (b) an ES-bond goes into LACP bypass zebra deletes all the local macs (with that ES as destination) in the kernel and its local db. BGP re-sends any imported MAC-IP routes that may exist with this ES destination as remote routes i.e. zebra can end up programming a MAC that was perviously local as remote pointing to a VTEP-ECMP group. When an ES is attached to a hostbond or an ES-bond goes LACP-up (out of bypss) zebra again deletes all the local macs in the kernel and its local db. At this point BGP resends any imported MAC-IP routes that may exist with this ES destination as sync routes i.e. zebra can end up programming a MAC that was perviously remote as local pointing to an access port. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2021-01-13Merge pull request #6853 from mjstapp/fix_rib_dupsDonald Sharp
zebra: reduce impact of route-update overload
2020-12-22zebra: resched dp thread if output queue limit hitDuncan Eastoe
If the dataplane thread hits the work limit while processing the output queue for any given provider, we now explicitly reschedule the thread. Otherwise, if the number of items in the output queue is greater than the work limit, draining of that output queue is dependent on new dataplane work. Routes which are not drained from the output queue are stuck with the 'q' flag, so this is a similar issue to that observed in 164d8e86081fdf33992b6c45af446bac6103e20c. Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
2020-12-18zebra: fix loop logic in dplane for extra intf infoMark Stapp
The way a couple of clauses were placed in a loop meant that some info might not be collected - re-order things just a bit. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2020-12-11zebra: dplane API to get provider output q lengthDuncan Eastoe
Returns the current number of (completed) contexts in the provider's output queue (dp_ctx_out_q), allowing access to this data from the provider itself. Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
2020-12-07zebra: improve dataplane plugin queue countersMark Stapp
Add the current queue depths for each plugin to the 'show dplane providers' output. Maintain the out-bound queue max counter properly, that was being ignored. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2020-11-30zebra: add an api to process/clean the pending dplane queueMark Stapp
Add an api that allows a caller in the zebra main pthread to process the queue of pending dplane updates. The caller supplies a function to call to test each pending context. Selected contexts are dequeued, and freed without being processed. Signed-off-by: Mark Stapp <mjs@voltanet.io>
2020-10-30zebra: add optional extra data about routes' interfacesMark Stapp
Add extra data about the interfaces used in route updates' nexthops - some consumers of route updates may want additional data, but dataplane plugins running in the dplane pthread cannot safely access the normal zebra data structures. Capturing this info is optional - a plugin must request it (via an api). Signed-off-by: Mark Stapp <mjs@voltanet.io>
2020-10-26zebra: changes for programming SPH, non-DF and backup NHG br-port attrsAnuradha Karuppiah
split horizon filter, non-DF block filter and backup nexthop group are passed as bridge port attributes to the dataplane. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-10-26zebra: dplane APIs for programming evpn-mh access port attributesAnuradha Karuppiah
This includes - 1. non-DF block filter 2. List of es-peers that need to be blocked per-access port (for split horizon filtering) 3. Backup nexthop group to failover local-es via the VxLAN overlay Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2020-10-22zebra: replace inet_ntoaMark Stapp
Stop using inet_ntoa - use %pI4 or inet_ntop instead Signed-off-by: Mark Stapp <mjs@voltanet.io>
2020-10-22:* Convert prefix2str to %pFXDonatas Abraitis
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-09-28zebra: free ctx if we skip replace for NHG PROTO routesStephen Worley
Free the ctx if we decide we dont need to do anything with this route update. Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
2020-09-28zebra: limit no re-install to NHG PROTO using routesStephen Worley
Limit the not re-installation of routes with the same NHG ID to routes that are using the new NHG PROTO API. This would only include sharpd and EVPN-MH for now. Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
2020-09-28zebra: Properly set NEXTHOP_FLAG_FIB when skipping installDonald Sharp
When the dataplane detects that we have no need to reinstall the same route, setup the NEXTHOP_FLAG_FIB appropriately. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-09-28zebra: Prevent duplicate re-installDonald Sharp
If we have received a route that the already existing route is exactly the same, just note that it happened and move on. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-09-11bgpd, lib, pbrd, zebra: Pass by ifnameDonald Sharp
When installing rules pass by the interface name across zapi. This is being changed because we have a situation where if you quickly create/destroy ephermeal interfaces under linux the upper level protocol may be trying to add a rule for a interface that does not quite exist at the moment. Since ip rules actually want the interface name ( to handle just this sort of situation ) convert over to passing the interface name and storing it and using it in zebra. Ticket: CM-31042 Signed-off-by: Stephen Worley <sworley@nvidia.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2020-08-26zebra: When we fail, actually note the failureDonald Sharp
During testing it was noticed that routes were considered installed by zebra, but the kernel did not have the route. Upon close debugging of the rib it was noticed that FRR was turning a dplane_ctx_route_init into a success and FRR was now in a bad state. 2020/08/26 17:55:53.897436 PBR: route_notify_owner: [0.0.0.0/0] Route Removed succeeded for table: 10012 2020/08/26 17:55:53.897572 ZEBRA: 0.0.0.0/0: uptime == 432033, type == 24, instance == 0, table == 10012 2020/08/26 17:55:53.897622 ZEBRA: rib_meta_queue_add: (0:10012):0.0.0.0/0: queued rn 0x5566b0ea7680 into sub-queue 5 2020/08/26 17:55:53.907637 ZEBRA: default(0:10012):0.0.0.0/0: Processing rn 0x5566b0ea7680 2020/08/26 17:55:53.907665 ZEBRA: default(0:10012):0.0.0.0/0: Examine re 0x5566b0d01200 (pbr) status 2 flags 1 dist 200 metric 0 2020/08/26 17:55:53.907702 ZEBRA: default(0:10012):0.0.0.0/0: After processing: old_selected 0x0 new_selected 0x5566b0d01200 old_fib 0x0 new_fib 0x5566b0d01200 2020/08/26 17:55:53.907713 ZEBRA: default(0:10012):0.0.0.0/0: Adding route rn 0x5566b0ea7680, re 0x5566b0d01200 (pbr) 2020/08/26 17:55:53.907879 ZEBRA: default(0:10012):0.0.0.0/0: rn 0x5566b0ea7680 dequeued from sub-queue 5 2020/08/26 17:55:53.907943 ZEBRA: netlink_route_multipath: RTM_NEWROUTE 0.0.0.0/0 vrf 0(10012) 2020/08/26 17:55:53.910756 ZEBRA: default(0:10012):0.0.0.0/0 Processing dplane result ctx 0x5566b0ea82f0, op ROUTE_INSTALL result SUCCESS 2020/08/26 17:55:53.910769 ZEBRA: update_from_ctx: default(0:10012):0.0.0.0/0: SELECTED, re 0x5566b0d01200 2020/08/26 17:55:53.910785 ZEBRA: default(0:10012):0.0.0.0/0 update_from_ctx(): no fib nhg 2020/08/26 17:55:53.910793 ZEBRA: default(0:10012):0.0.0.0/0 update_from_ctx(): rib nhg matched, changed 'true' 2020/08/26 17:55:53.910802 ZEBRA: (0:10012):0.0.0.0/0: Redist update re 0x5566b0d01200 (pbr), old 0x0 (None) 2020/08/26 17:55:53.910812 ZEBRA: Notifying Owner: 24 about prefix 0.0.0.0/0(10012) 2 vrf: 0 2020/08/26 17:55:53.910912 PBR: route_notify_owner: [0.0.0.0/0] Route installed succeeded for table: 10012 2020/08/26 17:55:55.400516 ZEBRA: RTM_DELROUTE 0.0.0.0/0 vrf default(0) table_id: 10012 metric: 20 Admin Distance: 0 2020/08/26 17:55:55.400527 ZEBRA: rib_delete: (0:10012):0.0.0.0/0: rn 0x5566b0ea7680, re 0x5566b0d01200 (pbr) was deleted from kernel, adding We were receiving a notification from the kernel that the route was deleted and deciding that we needed to reinstall it. At that point in time when it got into the dplane handlers to convert it to the dplane pthread, the dplane decided to drop the request convert it too a success and not do anything. This code change removes the conversion from this failure to success and notifies the upper level about it. After this change the default route to table 10012 is now properly marked as rejected: root@mlx-2700-07:mgmt:/var/log/frr# vtysh -c "show ip route table 10012" 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 default table 10012: F>r 0.0.0.0/0 [200/0] via 172.168.1.164, isp2-uplink (vrf PUBLIC), weight 1, 00:24:48 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>