- dev - lists.frrouting.org

vtysh: Missing "Show Ip" Commands
by Carr, Christopher 19 Aug '19

19 Aug '19

I was unclear if this should be asked on the dev mailing list or as an issue on GitHub. We are currently using Quagga on our systems and I am investigating moving over to FRRouting. I've been building FRRouting with a custom Yocto recipe, cross-compiled for the PPC. (I'm using one of the latest commits rather than a released version from GitHub, as there were some fixes for hosttools that was not available in the release) So far I've got it to the point where my build completes, and I have binaries that run on the target. As my system used quagga before, I've configured FRR to use the quagga and quaggavty user/groups. The installed files on the switch have also been chown'd with quagga/quaggavty as appropriate. The one thing that I'm having trouble figuring out is the exposing of the "show ip" commnds via vtysh. Running just zebra, staticd and ripd the vtysh utility will only show the default subset of "show" commands. All the "show ip", "show ip rip" etc are missing. However if I telnet directly to the ripd port, after setting a password via vtysh, then everything is present via that telnet connection. I've tried both configure and privileged mode to see if the command set changed to display these, but neither did. I've included the output of the success and failure below. I've looked at the vtysh code however nothing is jumping out as obviously wrong. I'm guessing that I've not configured something in the build correctly, but I'm confused as to what it could be. Searching the mailing lists and GitHub issues hasn't unearthed and similar issues. Does anyone have any pointers to areas that I might look at to solve this be it in configuration, compilation or installation etc. Thanks Chris Carr Eg. [root@openware]# vtysh Hello, this is FRRouting (version 7.2-dev). Copyright 1996-2005 Kunihiro Ishiguro, et al. quagga-router# show daemons Show list of running daemons debugging Debugging functions error Information on errors log-filter Filter Logs logging Show current logging configuration memory Memory statistics modules Loaded modules running-config Current operating configuration startup-config Contents of startup configuration thread Thread information version Displays zebra version work-queues Work Queue information [root@openware]# vtysh -d ripd Hello, this is FRRouting (version 7.2-dev). Copyright 1996-2005 Kunihiro Ishiguro, et al. quagga-router# show daemons Show list of running daemons debugging Debugging functions error Information on errors log-filter Filter Logs logging Show current logging configuration memory Memory statistics modules Loaded modules running-config Current operating configuration startup-config Contents of startup configuration thread Thread information version Displays zebra version work-queues Work Queue information [root@openware]# telnet localhost 2601 [root@openware]# telnet localhost 2602 Hello, this is FRRouting (version 7.2-dev). Copyright 1996-2005 Kunihiro Ishiguro, et al. User Access Verification Entering character mode Escape character is '^]'. Password: openware> openware> show commandtree Show command tree debugging Debugging information error Information on errors evpn EVPN history Display the session command history interface Interface status and configuration ip IP information ipv6 IPv6 information log-filter Filter Logs logging Show current logging configuration memory Memory statistics modules Loaded modules mpls MPLS information pbr Policy-Based Routing thread Thread information version Displays zebra version vrf VRF work-queues Work Queue information zebra Zebra information

2 3

Re: [dev] Invite for Slack
by Donald Sharp 13 Aug '19

13 Aug '19

Varun - Please goto https://frrouting.org and click on the slack link for a self invite. donald On Mon, Aug 12, 2019 at 6:21 PM Varun Vij via dev <dev(a)lists.frrouting.org> wrote: > > > > > ---------- Forwarded message ---------- > From: Varun Vij <vvij(a)apple.com> > To: dev(a)lists.frrouting.org > Cc: > Bcc: > Date: Mon, 12 Aug 2019 18:12:14 -0400 > Subject: Invite for Slack > Requesting to join the Slack workspace if it’s ok. > > Thanks and Regards > Varun > > > > > ---------- Forwarded message ---------- > From: Varun Vij via dev <dev(a)lists.frrouting.org> > To: dev(a)lists.frrouting.org > Cc: > Bcc: > Date: Mon, 12 Aug 2019 15:21:14 -0700 (PDT) > Subject: [dev] Invite for Slack > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev

1 0

Invite for Slack
by Varun Vij 13 Aug '19

13 Aug '19

Requesting to join the Slack workspace if it’s ok. Thanks and Regards Varun

1 0

Re: [dev] Disco package?
by David Lamparter 03 Aug '19

03 Aug '19

On Sat, Aug 03, 2019 at 01:14:55PM +0000, Mario Santana via dev wrote: > Hi! I'm now running disco in my dev/test lab, and would love a package for it. > Let me know if there's anything I need to do besides ask here... You should be able to install the Debian 10 package on Ubuntu 19.04. Just alter the instructions from https://deb.frrouting.org/ and replace the "$(lsb_release -s -c)" with "buster": echo "deb https://deb.frrouting.org/frr buster frr-stable" | ... Cheers, -David

2 2

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 02 Aug '19

02 Aug '19

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 11 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 15 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 11 of 11 defect(s) ** CID 1485637: Incorrect expression (SIZEOF_MISMATCH) /qpb/qpb_allocator.h: 57 in qpb_alloc_ptr_array() ________________________________________________________________________________________________________ *** CID 1485637: Incorrect expression (SIZEOF_MISMATCH) /qpb/qpb_allocator.h: 57 in qpb_alloc_ptr_array() 51 * 52 * Allocate space for the specified number of pointers. 53 */ 54 static inline void *qpb_alloc_ptr_array(qpb_allocator_t *allocator, 55 size_t num_ptrs) 56 { >>> CID 1485637: Incorrect expression (SIZEOF_MISMATCH) >>> Passing argument "num_ptrs * 8UL /* sizeof (void *) */" to function "qpb_alloc" which returns a value of type "void *" is suspicious. 57 return qpb_alloc(allocator, num_ptrs * sizeof(void *)); 58 } 59 60 /* 61 * qpb_free 62 */ ** CID 1485636: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1485636: Null pointer dereferences (FORWARD_NULL) /lib/filter.c: 2058 in access_list_exact() 2052 prefix = argv[idx]->arg; 2053 2054 idx = 0; 2055 if (argv_find(argv, argc, "exact-match", &idx)) 2056 exact = 1; 2057 >>> CID 1485636: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "prefix" to "filter_set_zebra", which dereferences it. 2058 return filter_set_zebra(vty, argv[1]->arg, seq, permit_deny, 2059 AFI_IP, prefix, exact, 1); 2060 } 2061 2062 DEFUN (access_list_any, 2063 access_list_any_cmd, ** CID 1485635: Incorrect expression (SIZEOF_MISMATCH) /qpb/qpb.h: 124 in qpb__l3_prefix__get() ________________________________________________________________________________________________________ *** CID 1485635: Incorrect expression (SIZEOF_MISMATCH) /qpb/qpb.h: 124 in qpb__l3_prefix__get() 118 uint8_t family, struct prefix *prefix) 119 { 120 121 switch (family) { 122 123 case AF_INET: >>> CID 1485635: Incorrect expression (SIZEOF_MISMATCH) >>> Passing argument "prefix" of type "struct prefix *" and argument "16UL" ("sizeof (struct prefix_ipv4)") to function "memset" is suspicious because a multiple of "sizeof (struct prefix) /*48*/" is expected. 124 memset(prefix, 0, sizeof(struct prefix_ipv4)); 125 break; 126 127 case AF_INET6: 128 memset(prefix, 0, sizeof(struct prefix_ipv6)); 129 break; ** CID 1485634: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1485634: Null pointer dereferences (FORWARD_NULL) /lib/filter.c: 1956 in no_mac_access_list() 1950 1951 idx = 0; 1952 argv_find(argv, argc, "X:X:X:X:X:X", &idx); 1953 if (idx) 1954 mac = argv[idx]->arg; 1955 >>> CID 1485634: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "mac" to "filter_set_zebra", which dereferences it. 1956 return filter_set_zebra(vty, argv[2]->arg, seq, permit_deny, AFI_L2VPN, 1957 mac, 0, 0); 1958 } 1959 1960 DEFUN (mac_access_list_any, 1961 mac_access_list_any_cmd, ** CID 1485633: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_vty.c: 1021 in show_route_all_table_vrf_magic() ________________________________________________________________________________________________________ *** CID 1485633: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_vty.c: 1021 in show_route_all_table_vrf_magic() 1015 rib_table_info_t *info = route_table_get_info(zrt->table); 1016 1017 if (zvrf && zvrf != info->zvrf) 1018 continue; 1019 if (zrt->afi != afi || zrt->safi != SAFI_UNICAST) 1020 continue; >>> CID 1485633: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "zrt->table" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1021 if (zrt->table) 1022 do_show_route_helper(vty, info->zvrf, zrt->table, afi, 1023 false, 0, false, false, 1024 0, 0, !!json, zrt->tableid); 1025 } 1026 return CMD_SUCCESS; ** CID 1485632: (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1485632: (FORWARD_NULL) /pimd/pim_zebra.c: 1240 in pim_forward_start() 1234 pim_channel_oil_change_iif(pim, up->channel_oil, 1235 MAXVIFS, 1236 __PRETTY_FUNCTION__); 1237 } 1238 1239 else >>> CID 1485632: (FORWARD_NULL) >>> Passing null pointer "up->channel_oil" to "pim_channel_oil_change_iif", which dereferences it. 1240 pim_channel_oil_change_iif(pim, up->channel_oil, 1241 input_iface_vif_index, 1242 __PRETTY_FUNCTION__); 1243 1244 if (PIM_DEBUG_TRACE) { 1245 struct interface *in_intf = pim_if_find_by_vif_index( /pimd/pim_zebra.c: 1234 in pim_forward_start() 1228 source_str, sizeof(source_str)); 1229 zlog_debug( 1230 "%s %s: could not find input interface for source %s", 1231 __FILE__, __PRETTY_FUNCTION__, 1232 source_str); 1233 } >>> CID 1485632: (FORWARD_NULL) >>> Passing null pointer "up->channel_oil" to "pim_channel_oil_change_iif", which dereferences it. 1234 pim_channel_oil_change_iif(pim, up->channel_oil, 1235 MAXVIFS, 1236 __PRETTY_FUNCTION__); 1237 } 1238 1239 else ** CID 1485631: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1485631: Null pointer dereferences (FORWARD_NULL) /lib/filter.c: 1919 in mac_access_list() 1913 1914 idx = 0; 1915 argv_find(argv, argc, "X:X:X:X:X:X", &idx); 1916 if (idx) 1917 mac = argv[idx]->arg; 1918 >>> CID 1485631: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "mac" to "filter_set_zebra", which dereferences it. 1919 return filter_set_zebra(vty, argv[2]->arg, seq, permit_deny, AFI_L2VPN, 1920 mac, 0, 1); 1921 } 1922 1923 DEFUN (no_mac_access_list, 1924 no_mac_access_list_cmd, ** CID 1485630: API usage errors (LOCK) /lib/log.c: 435 in vzlog() ________________________________________________________________________________________________________ *** CID 1485630: API usage errors (LOCK) /lib/log.c: 435 in vzlog() 429 proto_str, msg, &tsctl); 430 431 out: 432 if (msg != buf) 433 XFREE(MTYPE_TMP, msg); 434 errno = original_errno; >>> CID 1485630: API usage errors (LOCK) >>> "pthread_mutex_unlock" unlocks "loglock" while it is unlocked. 435 pthread_mutex_unlock(&loglock); 436 } 437 438 int vzlog_test(int priority) 439 { 440 pthread_mutex_lock(&loglock); ** CID 1485629: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1485629: Null pointer dereferences (FORWARD_NULL) /lib/filter.c: 2375 in no_ipv6_access_list_exact() 2369 prefix = argv[idx]->arg; 2370 2371 idx = 0; 2372 if (argv_find(argv, argc, "exact-match", &idx)) 2373 exact = 1; 2374 >>> CID 1485629: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "prefix" to "filter_set_zebra", which dereferences it. 2375 return filter_set_zebra(vty, argv[idx_word]->arg, seq, permit_deny, 2376 AFI_IP6, prefix, exact, 0); 2377 } 2378 2379 DEFUN (no_ipv6_access_list_any, 2380 no_ipv6_access_list_any_cmd, ** CID 1485628: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1485628: Null pointer dereferences (FORWARD_NULL) /lib/filter.c: 2130 in no_access_list_exact() 2124 prefix = argv[idx]->arg; 2125 2126 idx = 0; 2127 if (argv_find(argv, argc, "exact-match", &idx)) 2128 exact = 1; 2129 >>> CID 1485628: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "prefix" to "filter_set_zebra", which dereferences it. 2130 return filter_set_zebra(vty, argv[2]->arg, seq, permit_deny, 2131 AFI_IP, prefix, exact, 0); 2132 } 2133 2134 DEFUN (no_access_list_any, 2135 no_access_list_any_cmd, ** CID 1399256: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1399256: Null pointer dereferences (FORWARD_NULL) /lib/filter.c: 2300 in ipv6_access_list_exact() 2294 prefix = argv[idx]->arg; 2295 2296 idx = 0; 2297 if (argv_find(argv, argc, "exact-match", &idx)) 2298 exact = 1; 2299 >>> CID 1399256: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "prefix" to "filter_set_zebra", which dereferences it. 2300 return filter_set_zebra(vty, argv[idx_word]->arg, seq, permit_deny, 2301 AFI_IP6, prefix, exact, 1); 2302 } 2303 2304 DEFUN (ipv6_access_list_any, 2305 ipv6_access_list_any_cmd, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

How to build FRR with snmp supported ?
by Simon Jones 02 Aug '19

02 Aug '19

Hi all, I'm working on FRR, and I want bgpd and zebra to support snmp like this ( http://docs.frrouting.org/en/latest/snmp.html) As I want to handle peer down/up events. So I use this script to build : .ONESHELL: SHELL = /bin/bash .SHELLFLAGS += -e MAIN_TARGET = $(FRR) DERIVED_TARGET = $(FRR_PYTHONTOOLS) $(FRR_DBG) $(addprefix $(DEST)/, $(MAIN_TARGET)): $(DEST)/% : # Build the package pushd ./frr tools/tarsource.sh -V -e '-sonic' dpkg-buildpackage -rfakeroot -b -us -uc -Ppkg.frr.nortrlib -j$(SONIC_CONFIG_MAKE_JOBS) popd mv $(DERIVED_TARGET) $* $(DEST)/ $(addprefix $(DEST)/, $(DERIVED_TARGET)): $(DEST)/% : $(DEST)/$(MAIN_TARGET) In build log, I found there are zebra_snmp.so, and I found in this folder > $ find -name zebra_snmp.so > ./frr/zebra/.libs/zebra_snmp.so > ./frr/debian/frr-snmp/usr/lib/x86_64-linux-gnu/frr/modules/zebra_snmp.so > ./frr/debian/tmp/usr/lib/x86_64-linux-gnu/frr/modules/zebra_snmp.so But at last, in deb package, this is no zebra_snmp.so and other snmp.so in modules folder, and actually there is no modules folder. So how to build with these modules and snmp support like that URL? Will this be work? 1. Add '-Ppkg.frr.snmp' in 'dpkg-buildpackage' step? Or 2. Use some old version? Thank you~ ---- Simon Jones

3 7

Disco package?
by Mario Santana 01 Aug '19

01 Aug '19

Hi! I'm now running disco in my dev/test lab, and would love a package for it. Let me know if there's anything I need to do besides ask here... Cheers! Mario

1 0

Identical copy of buster and bullseye - deb.frrouting.org
by Christoffer Hansen 01 Aug '19

01 Aug '19

dev@, Possible to maintain an identical copy of packages for Debian 10 (buster) and Debian testing (bullseye) on http://deb.frrouting.org ? Distribution: * Debian unstable (sid) * Debian testing (bullseye) * Debian 10 (buster) -- Christoffer

3 3

Some doubts regarding asynchronous data plane in FRR
by sudhanshu kumar 30 Jul '19

30 Jul '19

Hi, I have 2 doubts regarding asynchronous dataplane implementation in FRR. 1. When there are multiple dplanes, each can process the same route context and modify the status in the context. But while processing rib_process_after(), we only consider the status returned by the last processed provider. Is this correct? We should, in this case, consider status returned by all the providers. If all of them return success, then only, we should consider the status as success in rib_process_after(). 2. Currently, zebra fpm interaction happens in rib context using hook. I would like to know why this was done ? Can this be made as a separate dplane ? Thanks, Sudhanshu

2 3

Question in relation to draft-sa-grow-maxprefix
by Christoffer Hansen 29 Jul '19

29 Jul '19

dev@, https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/?include_text=1 Do the current FRR master branch have support for both o Type A Pre-Policy, o Type B Post-Policy, and o Outbound BGP Maximum Prefix Limits? Christoffer """ 2.1. Type A: Pre-Policy Inbound Maximum Prefix Limits The Adj-RIBs-In stores routing information learned from inbound UPDATE messages that were received from another BGP speaker Section 3.2 [RFC4271]. The Type A pre-policy limit uses the number of NLRIs per Address Family Identifier (AFI) per Subsequent Address Family Identifier (SAFI) as input into its threshold comparisons. For example, when an operator configures the Type A pre-policy limit for IPv4 Unicast to be 50 on a given EBGP session, and the other BGP speaker announces its 51st IPv4 Unicast NLRI, the session MUST be terminated. Type A pre-policy limits are particularly useful to help dampen the effects of full table route leaks and memory exhaustion when the implementation stores rejected routes. 2.2. Type B: Post-Policy Inbound Maximum Prefix Limits RFC4271 describes a Policy Information Base (PIB) that contains local policies that can be applied to the information in the Routing Information Base (RIB). The Type B post-policy limit uses the number of NLRIs per Address Family Identifier (AFI) per Subsequent Address Family Identifier (SAFI), after application of the Import Policy as input into its threshold comparisons. For example, when an operator configures the Type B post-policy limit for IPv4 Unicast to be 50 on a given EBGP session, and the other BGP speaker announces a hundred IPv4 Unicast routes of which none are accepted as a result of the local import policy (and thus not considered for the Loc-RIB by the local BGP speaker), the session is not terminated. Type B post-policy limits are useful to help prevent FIB exhaustion and prevent accidental BGP session teardown due to prefixes not accepted by policy anyway. 3. Outbound Maximum Prefix Limits An operator MAY configure a BGP speaker to terminate its BGP session with a neighbor when the number of address prefixes to be advertised to that neighbor exceeds a locally configured upper limit. The BGP speaker then MUST send the neighbor a NOTIFICATION message with the Error Code Cease and the Error Subcode "Threshold reached: Maximum Number of Prefixes Send", and MAY support other actions. Reporting when thresholds have been exceeded is an implementation specific consideration, but SHOULD include methods such as Syslog [RFC5424]. By definition, Outbound Maximum Prefix Limits are Post-Policy. The Adj-RIBs-Out stores information selected by the local BGP speaker for advertisement to its neighbors. The routing information stored in the Adj-RIBs-Out will be carried in the local BGP speaker's UPDATE messages and advertised to its neighbors Section 3.2 [RFC4271]. The Outbound Maximum Prefix Limit uses the number of NLRIs per Address Family Identifier (AFI) per Subsequent Address Family Identifier (SAFI), after application of the Export Policy, as input into its threshold comparisons. For example, when an operator configures the Outbound Maximum Prefix Limit for IPv4 Unicast to be 50 on a given EBGP session, and were about to announce its 51st IPv4 Unicast NLRI to the other BGP speaker as a result of the local export policy, the session MUST be terminated. Outbound Maximum Prefix Limits are useful to help dampen the negative effects of a misconfiguration in local policy. In many cases, it would be more desirable to tear down a BGP session rather than causing or propagating a route leak. """ """ +-------------+----------------+-------------------------+----------+ | Vendor | Type A Pre- | Type B Post-Policy | Outbound | | | Policy | | | +-------------+----------------+-------------------------+----------+ | Cisco IOS | | maximum-prefix | | | XR | | | | +-------------+----------------+-------------------------+----------+ | Cisco IOS | | maximum-prefix | | | XE | | | | +-------------+----------------+-------------------------+----------+ | Juniper | prefix-limit | accepted-prefix-limit, | | | Junos OS | | or prefix-limit | | | | | combined with 'keep | | | | | none' | | +-------------+----------------+-------------------------+----------+ | Nokia SR OS | prefix-limit | | | +-------------+----------------+-------------------------+----------+ | NIC.CZ BIRD | 'import keep | 'import limit' or | export | | | filtered' | 'receive limit' | limit | | | combined with | | | | | 'receive | | | | | limit' | | | +-------------+----------------+-------------------------+----------+ | OpenBSD | max-prefix | | | | OpenBGPD | | | | +-------------+----------------+-------------------------+----------+ | Arista EOS | maximum-routes | maximum-accepted-routes | | +-------------+----------------+-------------------------+----------+ | Huawei | peer route- | | | | VRPv5 | limit | | | +-------------+----------------+-------------------------+----------+ | Huawei | peer route- | peer route-limit | | | VRPv8 | limit | accept-prefix | | +-------------+----------------+-------------------------+----------+ First presented by Snijders at [RIPE77] Table 1: Maximum prefix limits capabilities per implementation """

1 0