frrouting / frr Goto Github PK

seen on basically any config that includes a debug bgp ... line, simply start then exit - nothing else needed and see:
bgpd: showing active allocations in memory group libzebra
bgpd: memstats: Command Tokens : 502 * (variably sized)
bgpd: memstats: Graph Node : 7776 * 32
bgpd: memstats: Temporary memory : 10476 * (variably sized)
bgpd: memstats: Command desc : 18446744073709543115 * (variably sized)
bgpd: memstats: Vector index : 15552 * (variably sized)
bgpd: memstats: Vector : 15552 * 16
bgpd: showing active allocations in memory group rfapi
bgpd: showing active allocations in memory group bgpd

command tokens seems to get worse over time (or with different configs, not sure) but rest are probably just exit cleanup issues...

(Master branch only - not stable/2.0)

This started with Git SHA 1a35e2e (First broken) and is only broken in Master
-- EDIT: See correct bad commit below (as found by bisect). NOT 1a35e2e

mininet12# show ip bgp view
Defined BGP views:
	1 (AS100)
	2 (AS100)
	3 (AS100)
mininet12# sh ip bgp view 1
Can't find BGP instance (default)
mininet12# sh ip bgp view 2
Can't find BGP instance (default)
mininet12# sh ip bgp view 3
Can't find BGP instance (default)

OLD
address-family vpnv4
address-family vpnv6
address-family encap|encapv4
address-family encapv6
NEW
address-family <vpnv4|ipv4 vpn>
address-family <vpnv6|ipv6 vpn>
address-family <encap|encapv4|ipv4 encap>
address-family <encapv6|ipv6 encap>

show config shows form

CC command_match.lo
command_lex.c:1152:3: warning: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'int' [-Wsign-compare]
YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
command_lex.c:698:18: note: expanded from macro 'YY_INPUT'
for ( n = 0; n < max_size &&
~ ^ ~~~~~~~~
1 warning generated.

I'd like to be able to turn on -werror on master. This is a show stopper!

Commands that are present in quagga R.1.1.0 are missing in stable 2.0

Seen in wireshark, Works fine in Quagga.
Format is correct when constructed.
Check in debugger @ bgp_updgrp_packet.c line 811 (stable/2.0)

from labn basic regression:
==21683== ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 6 from 6)
==21683==
==21683== 1 errors in context 1 of 2:
==21683== Conditional jump or move depends on uninitialised value(s)
==21683== at 0x52E7A1: vty_close (vty.c:2275)
==21683== by 0x52FF86: vty_reset (vty.c:2999)
==21683== by 0x5303FD: vty_terminate (vty.c:3130)
==21683== by 0x41EAF7: bgp_exit (bgp_main.c:297)
==21683== by 0x41E961: sigint (bgp_main.c:225)
==21683== by 0x560C6D: quagga_sigevent_process (sigevent.c:111)
==21683== by 0x53AF91: thread_fetch (thread.c:1172)
==21683== by 0x41F413: main (bgp_main.c:570)
==21683== Uninitialised value was created by a stack allocation
==21683== at 0x52E5D5: vty_close (vty.c:2231)
==21683==
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:vty_close
fun:vty_reset
fun:vty_terminate
fun:bgp_exit
fun:sigint
fun:quagga_sigevent_process
fun:thread_fetch
fun:main
}
==21683==
==21683== 5 errors in context 2 of 2:
==21683== Conditional jump or move depends on uninitialised value(s)
==21683== at 0x52E7A1: vty_close (vty.c:2275)
==21683== by 0x52D298: vty_read (vty.c:1602)
==21683== by 0x53B605: thread_call (thread.c:1303)
==21683== by 0x41F3F3: main (bgp_main.c:571)
==21683== Uninitialised value was created by a stack allocation
==21683== at 0x52E5D5: vty_close (vty.c:2231)
==21683==
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:vty_close
fun:vty_read
fun:thread_call
fun:main
}

The problem in this defect exhibited itself as a prefix that should be summarized by an area-range statement appearing the rib of a router downstream of the ABR, but not in the lsdb

r3# sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv6, I - IS-IS, B - BGP, T - Table, v - VNC,
V - VPN,
> - selected route, * - FIB route

O>* 2000::/16 [110/30] via fe80::4638:39ff:fe00:6d99, swp1
O>* 2000:1000::/32 [110/30] via fe80::4638:39ff:fe00:6d99, swp1
O>* 2000:1000:1000:1000::/80 [110/20] via fe80::4638:39ff:fe00:6d99, swp1<<<<<<<<<<<<<<<<<<<<
O 3000:1000:1000:1000::/80 [110/10] is directly connected, swp1
C>* 3000:1000:1000:1000::/80 is directly connected, swp1
O>* 3000:1000:1000:1000:1::/80 [110/20] via fe80::4638:39ff:fe00:6d99, swp1
O 3000:1000:1000:1000:2::/80 [110/10] is directly connected, swp2
C>* 3000:1000:1000:1000:2::/80 is directly connected, swp2
O>* 4000:1000:1000:1000::/80 [110/40] via fe80::4638:39ff:fe00:6d99, swp1
C * fe80::/64 is directly connected, swp2
C * fe80::/64 is directly connected, swp1
C>* fe80::/64 is directly connected, eth0

    Area Scoped Link State Database (Area 0.0.0.1)

Type LSId AdvRouter Age SeqNum Payload
Rtr 0.0.0.0 0.0.0.7 992 80000004 0.0.0.8/0.0.0.7
Rtr 0.0.0.0 0.0.0.8 993 80000004 0.0.0.8/0.0.0.7
Net 0.0.0.7 0.0.0.8 993 80000003 0.0.0.8
Net 0.0.0.7 0.0.0.8 993 80000003 0.0.0.7
IAP 0.0.0.0 0.0.0.8 987 80000003 2000::/16
IAP 0.0.0.1 0.0.0.8 987 80000005 2000:1000::/32
IAP 0.0.0.4 0.0.0.8 988 80000003 4000:1000:1000:1000::/80
INP 0.0.0.0 0.0.0.7 992 80000005 3000:1000:1000:1000:2::/80
INP 0.0.0.0 0.0.0.8 993 80000005 3000:1000:1000:1000:1::/80
INP 0.0.0.7 0.0.0.8 993 80000003 3000:1000:1000:1000::/80

    I/F Scoped Link State Database (I/F swp1 in Area 0.0.0.1)

Type LSId AdvRouter Age SeqNum Payload
Lnk 0.0.0.3 0.0.0.7 1034 80000003 fe80::202:ff:fe00:a
Lnk 0.0.0.7 0.0.0.8 1033 80000003 fe80::4638:39ff:fe00:6d99

    I/F Scoped Link State Database (I/F swp2 in Area 0.0.0.1)

Type LSId AdvRouter Age SeqNum Payload
Lnk 0.0.0.4 0.0.0.7 1034 80000003 fe80::202:ff:fe00:b

    AS Scoped Link State Database

Type LSId AdvRouter Age SeqNum Payload

This basic work would consist in providing the following on master branch:

• basic vty command
• add prefix modifications
• make it (un)configurable using --enable-evpn; default evpn is disabled.
  reason behind configuration is the memory consumption hidden behind this change

The other missing changes that I forget to mention would be the common modifications necessary, so that everyone is able to build other evpn features on top of this:
Among other features:

• rt2 controlplane part
• rt2 dataplane/controlplane
• rt5
• rt1

Scenario is: 2xNVAes + 2xGWs (import/export to vpn safi) + 2xRRs, 2xCEs (regression-rr+gw+nva)
This is probably blocked by Issue #91

Leaked type: Socket union : 1 * 28 blocks
Leaked type: Route table : 72 * 32 blocks
Leaked type: Hash : 23 * 40 blocks
Leaked type: Hash Index : 23 * (variably
Leaked type: Work queue : 1 * 128 blocks
Leaked type: Work queue name string : 1 *
Leaked type: BGP instance : 1 * 3168 blocks
Leaked type: BGP peer : 1 * 20800 blocks
Leaked type: BGP peer hostname : 1 * (variably
Leaked type: BGP table : 72 * 40 blocks
Leaked type: BGP node : 32 * 120 blocks
Leaked type: BGP route : 10 * 112 blocks
Leaked type: BGP synchronise : 21 * 72 blocks
Leaked type: BGP Process queue : 10 * 24
Leaked type: BGP node clear queue : 10 * 8

Issue by donaldsharp
Friday Dec 09, 2016 at 17:53 GMT
Originally opened as https://github.com/opensourcerouting/cumulus-private_quagga/issues/12

mpls ldp
router-id 6.0.0.3
!
address-family ipv4
discovery transport-address 6.0.0.3
!
interface swp4
!
interface swp3
!
interface swp2
!
interface swp1
!
!
!

We should have a sorted list as is the case for other routing protocols.

patch which was submitted to quagga: https://bugzilla.quagga.net/show_bug.cgi?id=875

specification: https://tools.ietf.org/html/draft-ietf-idr-large-community

This is not necessary a defect. The only purpose is to make a conscious decision at a technical meeting.

Cisco, old Quagga and various others use BGP timers of 30s for Keepalive and 90s for Hold timer.
FRR uses currently 3s for keepalive and 9s for holdtimer.

The argument (long time back) on the Quagga mailing list is that the new default is better suited - and it might be much better for BGP as internal protocol in a Datacenter (and might be in other places as well)

The issue is that the defaults are not visible, so someone creating a new config might not be aware of it. I would prefer to make the default visible at least for the BGP timers before the first release.

(This issue can be closed after it is discussed at a technical meeting and a decision made either way.)

While attempting to install the frr package on a device currently running quagga, the following error is encountered.

root@leaf2:# dpkg -i frr_2.1_amd64.deb
(Reading database ... 25545 files and directories currently installed.)
Preparing to unpack frr_2.1_amd64.deb ...
Unpacking frr (2.1) ...
dpkg: error processing archive frr_2.1_amd64.deb (--install):
trying to overwrite '/usr/share/snmp/mibs/GNOME-PRODUCT-ZEBRA-MIB', which is also in package quagga 1.0.0+cl3u6
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
frr_2.1_amd64.deb
root@leaf2:#

lib/log.c:

int
proto_redistnum(int afi, const char *s)
{
  if (! s)
    return -1;

  if (afi == AFI_IP)
    {
      if (strncmp (s, "k", 1) == 0)
        return ZEBRA_ROUTE_KERNEL;
      else if (strncmp (s, "c", 1) == 0)
        return ZEBRA_ROUTE_CONNECT;
      else if (strncmp (s, "s", 1) == 0)
        return ZEBRA_ROUTE_STATIC;
      else if (strncmp (s, "r", 1) == 0)
        return ZEBRA_ROUTE_RIP;
      else if (strncmp (s, "o", 1) == 0)
        return ZEBRA_ROUTE_OSPF;
      else if (strncmp (s, "i", 1) == 0)
        return ZEBRA_ROUTE_ISIS;
      else if (strncmp (s, "bg", 2) == 0)
        return ZEBRA_ROUTE_BGP;
      else if (strncmp (s, "ta", 2) == 0)
        return ZEBRA_ROUTE_TABLE;
      else if (strncmp (s, "v", 1) == 0)
        return ZEBRA_ROUTE_VNC;
      else if (strncmp (s, "vd", 1) == 0)
        return ZEBRA_ROUTE_VNC_DIRECT;
    }
  if (afi == AFI_IP6)
    {
      if (strncmp (s, "k", 1) == 0)
        return ZEBRA_ROUTE_KERNEL;
      else if (strncmp (s, "c", 1) == 0)
        return ZEBRA_ROUTE_CONNECT;
      else if (strncmp (s, "s", 1) == 0)
        return ZEBRA_ROUTE_STATIC;
      else if (strncmp (s, "r", 1) == 0)
        return ZEBRA_ROUTE_RIPNG;
      else if (strncmp (s, "o", 1) == 0)
        return ZEBRA_ROUTE_OSPF6;
      else if (strncmp (s, "i", 1) == 0)
        return ZEBRA_ROUTE_ISIS;
      else if (strncmp (s, "bg", 2) == 0)
        return ZEBRA_ROUTE_BGP;
      else if (strncmp (s, "ta", 2) == 0)
        return ZEBRA_ROUTE_TABLE;
      else if (strncmp (s, "v", 1) == 0)
        return ZEBRA_ROUTE_VNC;
      else if (strncmp (s, "vd", 1) == 0)
        return ZEBRA_ROUTE_VNC_DIRECT;
    }
  return -1;
}

This is called in many locations with raw user's CLI input. In cases where the user matches one of the calling commands with a single letter for the protocol name, this function will fail.

Checking 1 or 2 letters is not consistent and breaks some CLI completions.

Broken out from #20.

Need to move VPN and encap VNC related calls to after filtering.

Does not need to gate 2.0-rc1, but should be fixed in 2.0-rc2

some discussion on #101 led to the need to:
1- implement rfc4684 in order for a BGP speaker to signal which RT he wants the remote BGP speaker to learn
2- change the default behaviour of frr when receiving VPNvx messages. that is to say if VRF are no configured, then the incoming vpnvx message should be ignored.

This issue is related to 2.

Before installing a new static route Zebra checks to see if an equivalent route already exists and deletes it before installing the new route.

zebra_static.c

394   /* Do nothing if there is a same static route.  */
395   for (si = rn->info; si; si = si->next)
396     {
397       if (type == si->type
398           && (! gate ||
399               ((afi == AFI_IP && IPV4_ADDR_SAME (gate, &si->addr.ipv4)) ||
400                (afi == AFI_IP6 && IPV6_ADDR_SAME (gate, &si->addr.ipv6))))
401           && (! ifindex || ifindex == si->ifindex))
402         {
403           if ((distance == si->distance) && (tag == si->tag) &&
404               !memcmp (&si->snh_label, snh_label, sizeof (struct static_nh_label)))
405             {
406               route_unlock_node (rn);
407               return 0;
408             }
409           else
410             update = si;
411         }
412     }

This fails to check the route flags, which results in behavior like this:

cumulus# conf t
cumulus(config)# ip route 1.2.3.4/24 reject
cumulus(config)# do show ip route static
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, P - PIM, T - Table, v - VNC,
       V - VPN,
       > - selected route, * - FIB route

S>* 1.2.3.0/24 [1/0] is directly connected, Null0, rej
cumulus(config)# ip route 1.2.3.4/24 blackhole
cumulus(config)# do show ip route static
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, P - PIM, T - Table, v - VNC,
       V - VPN,
       > - selected route, * - FIB route

S>* 1.2.3.0/24 [1/0] is directly connected, Null0, rej
cumulus(config)#

The route flags are still set to reject. Correct behavior:

cumulus# conf t
cumulus(config)# ip route
  A.B.C.D    IP destination prefix
  A.B.C.D/M  IP destination prefix (e.g. 10.0.0.0/8)
cumulus(config)# ip route 1.2.3.4/24 reject
cumulus(config)# do show ip route static
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, P - PIM, T - Table, v - VNC,
       V - VPN,
       > - selected route, * - FIB route

S>* 1.2.3.0/24 [1/0] is directly connected, Null0, rej
cumulus(config)# ip route 1.2.3.4/24 blackhole
cumulus(config)# do show ip route static
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, P - PIM, T - Table, v - VNC,
       V - VPN,
       > - selected route, * - FIB route

S>* 1.2.3.0/24 [1/0] is directly connected, Null0, bh
cumulus(config)#

The route has been changed to a blackhole route.

s1 ----- robot

s1's config:

!
router bgp 10
 bgp router-id 10.0.2.15
 no bgp network import-check
 neighbor 4.3.2.1 remote-as external
 neighbor fe:c002:1:2::2 remote-as 10
 neighbor fe:c002:1:2::13 remote-as external
!
 address-family ipv6 unicast
  network 3:2:1::/64
  neighbor fe:c002:1:2::2 activate
  neighbor fe:c002:1:2::13 activate
 exit-address-family
!

 s1# show bgp ipv6 unic
BGP table version is 4, local router ID is 10.0.2.15
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
              i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 3:2:1::/64       ::                       0         32768 i
*> 2001:db8:1cc:222::/64
                    ::                       0         32768 i
*> 2001:db8:1cc:223::/64
                    ::                       0         32768 i
*> 2002:db9:432:1::/64
                    ::                       0         32768 i

Total number of prefixes 4
s1#

on robot we have:

!
router bgp 44
 neighbor fe:c002:1:2::1 remote-as external
 !
 address-family ipv6 unicast
  neighbor fe:c002:1:2::1 activate
  neighbor fe:c002:1:2::1 route-map V6-RM in
 exit-address-family
!
!
ipv6 prefix-list V6-PREFIX seq 5 permit 2001:db8:1cc:222::/64
!
route-map V6-RM permit 10
 match ipv6 address prefix-list V6-PREFIX
!

robot.cumulusnetworks.com# show bgp ipv6
BGP table version is 5, local router ID is 192.168.122.1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
              i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 2001:db8:1cc:222::/64
                    fe80::a00:27ff:fe96:bff9
                                             0             0 10 i

Displayed  1 routes and 1 total paths
robot.cumulusnetworks.com#

Let's add a new item to the prefix-list:

robot.cumulusnetworks.com# conf t
robot.cumulusnetworks.com(config)# ipv6 prefix-list V6-PREFIX seq 10 permit 2002:db9:432:1::/64
robot.cumulusnetworks.com(config)# end
robot.cumulusnetworks.com# show bgp ipv6
BGP table version is 5, local router ID is 192.168.122.1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
              i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 2001:db8:1cc:222::/64
                    fe80::a00:27ff:fe96:bff9
                                             0             0 10 i

Displayed  1 routes and 1 total paths

whoops...

robot.cumulusnetworks.com# clear bgp *
robot.cumulusnetworks.com# show bgp ipv6
BGP table version is 8, local router ID is 192.168.122.1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
              i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 2001:db8:1cc:222::/64
                    fe80::a00:27ff:fe96:bff9
                                             0             0 10 i
*> 2002:db9:432:1::/64
                    fe80::a00:27ff:fe96:bff9
                                             0             0 10 i

Displayed  2 routes and 2 total paths
robot.cumulusnetworks.com#

Problem description:

ubuntu(config)# do sh run
Building configuration...
(...)
!
l2vpn CUST_A type vpls
 bridge rt1-br0
 member interface rt1-eth0
 !
 member pseudowire rt1-mpw0
  neighbor lsr-id 2.2.2.2
  pw-id 100
 !
 member pseudowire rt1-mpw1
  neighbor lsr-id 3.3.3.3
  pw-id 100
 !
!
(...)
ubuntu(config)# no l2vpn CUST_A type vpls 
ubuntu(config)# l2vpn CUST_A type vpls
ubuntu(config-l2vpn)#  bridge rt1-br0
ubuntu(config-l2vpn)#  member interface rt1-eth0
ubuntu(config-l2vpn)#  !
ubuntu(config-l2vpn)#  member pseudowire rt1-mpw0
ubuntu(config-l2vpn-pw)#   neighbor lsr-id 2.2.2.2
ubuntu(config-l2vpn-pw)#   pw-id 100
ubuntu(config-l2vpn-pw)#  !
ubuntu(config-l2vpn-pw)#  member pseudowire rt1-mpw1
% [LDP] Unknown command:  member pseudowire rt1-mpw1
ubuntu(config)#   neighbor lsr-id 3.3.3.3
% Unknown command.
ubuntu(config)#   pw-id 100
% Unknown command.
ubuntu(config)#  !

The same problem doesn't happen when we configure ldpd directly through telnet:

ldpd(config)# l2vpn CUST_A type vpls
ldpd(config-l2vpn)#  bridge rt1-br0
ldpd(config-l2vpn)#  member interface rt1-eth0
ldpd(config-l2vpn)#  !
ldpd(config-l2vpn)#  member pseudowire rt1-mpw0
ldpd(config-l2vpn-pw)#   neighbor lsr-id 2.2.2.2
ldpd(config-l2vpn-pw)#   pw-id 100
ldpd(config-l2vpn-pw)#  !
ldpd(config-l2vpn-pw)#  member pseudowire rt1-mpw1
ldpd(config-l2vpn-pw)#   neighbor lsr-id 3.3.3.3
ldpd(config-l2vpn-pw)#   pw-id 100
ldpd(config-l2vpn-pw)#  !
ldpd(config-l2vpn-pw)# !

from master branch, I fail to run gdb command, because of undefined symbol qobj_t_route_map_index
.

./configure --prefix=/opt/quagga --enable-user=root --enable-group=root --enable-vty-gro
up=root --localstatedir=/opt/quagga/var/run/quagga --disable-doc --enable-multipath=64 --host=cc -dumpmachine --build=gcc -dumpmachine

root@ubuntu1404:/frr# LD_LIBRARY_PATH=./lib/.libs/ gdb ./bgpd/.libs/bgpd
GNU gdb (Ubuntu 7.7.1-0ubuntu514.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./bgpd/.libs/bgpd...done.
(gdb) run
Starting program: /root/frr/bgpd/.libs/bgpd
/root/frr/bgpd/.libs/bgpd: symbol lookup error: /root/frr/bgpd/.libs/bgpd: undefined symbol: qobj_t_route_map_index

nm ./lib/.libs/libzebra.*a | grep qobj_t_route_map_index
0000000000000750 D qobj_t_route_map_index

Add to prefix.c the ability to stringify mac addresses and take strings of mac addresses and turn them into the internal data representation.

These commands are ambiguous (on master):

• show_bgp_ipv4_encap_neighbor_routes_cmd
• show_bgp_ipv4_encap_neighbor_advertised_routes_cmd
• show_bgp_ipv6_encap_neighbor_routes_cmd
• show_bgp_ipv6_encap_neighbor_advertised_routes_cmd

Output from vtysh/vtysh -C -c 'grammar find-ambiguous nodescan' (needs --enable-dev-build on configure):

'show bgp ipv4 encap neighbors A.B.C.D advertised-routes' AMBIGUOUS:
  show_ip_bgp_instance_neighbor_advertised_route_cmd_vtysh
   'show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6> [<unicast|multicast|vpn|encap>]] neighbors <A.B.C.D|X:X::X:X|WORD> <received-routes|advertised-routes> [route-map WORD] [json]'
  show_bgp_ipv4_encap_neighbor_advertised_routes_cmd_vtysh
   'show [ip] bgp ipv4 encap neighbors A.B.C.D advertised-routes'

'show bgp ipv4 encap neighbors A.B.C.D routes' AMBIGUOUS:
  show_ip_bgp_neighbor_routes_cmd_vtysh
   'show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6> [<unicast|multicast|vpn|encap>]] neighbors <A.B.C.D|X:X::X:X|WORD> <flap-statistics|dampened-routes|routes> [json]'
  show_bgp_ipv4_encap_neighbor_routes_cmd_vtysh
   'show [ip] bgp ipv4 encap neighbors A.B.C.D routes'

'show bgp ipv6 encap neighbors A.B.C.D advertised-routes' AMBIGUOUS:
  show_bgp_ipv6_encap_neighbor_advertised_routes_cmd_vtysh
   'show [ip] bgp ipv6 encap neighbors A.B.C.D advertised-routes'
  show_ip_bgp_instance_neighbor_advertised_route_cmd_vtysh
   'show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6> [<unicast|multicast|vpn|encap>]] neighbors <A.B.C.D|X:X::X:X|WORD> <received-routes|advertised-routes> [route-map WORD] [json]'

'show bgp ipv6 encap neighbors A.B.C.D routes' AMBIGUOUS:
  show_bgp_ipv6_encap_neighbor_routes_cmd_vtysh
   'show [ip] bgp ipv6 encap neighbors A.B.C.D routes'
  show_ip_bgp_neighbor_routes_cmd_vtysh
   'show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6> [<unicast|multicast|vpn|encap>]] neighbors <A.B.C.D|X:X::X:X|WORD> <flap-statistics|dampened-routes|routes> [json]'

'show ip bgp ipv4 encap neighbors A.B.C.D advertised-routes' AMBIGUOUS:
  show_ip_bgp_instance_neighbor_advertised_route_cmd_vtysh
   'show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6> [<unicast|multicast|vpn|encap>]] neighbors <A.B.C.D|X:X::X:X|WORD> <received-routes|advertised-routes> [route-map WORD] [json]'
  show_bgp_ipv4_encap_neighbor_advertised_routes_cmd_vtysh
   'show [ip] bgp ipv4 encap neighbors A.B.C.D advertised-routes'

'show ip bgp ipv4 encap neighbors A.B.C.D routes' AMBIGUOUS:
  show_ip_bgp_neighbor_routes_cmd_vtysh
   'show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6> [<unicast|multicast|vpn|encap>]] neighbors <A.B.C.D|X:X::X:X|WORD> <flap-statistics|dampened-routes|routes> [json]'
  show_bgp_ipv4_encap_neighbor_routes_cmd_vtysh
   'show [ip] bgp ipv4 encap neighbors A.B.C.D routes'

'show ip bgp ipv6 encap neighbors A.B.C.D advertised-routes' AMBIGUOUS:
  show_bgp_ipv6_encap_neighbor_advertised_routes_cmd_vtysh
   'show [ip] bgp ipv6 encap neighbors A.B.C.D advertised-routes'
  show_ip_bgp_instance_neighbor_advertised_route_cmd_vtysh
   'show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6> [<unicast|multicast|vpn|encap>]] neighbors <A.B.C.D|X:X::X:X|WORD> <received-routes|advertised-routes> [route-map WORD] [json]'

'show ip bgp ipv6 encap neighbors A.B.C.D routes' AMBIGUOUS:
  show_bgp_ipv6_encap_neighbor_routes_cmd_vtysh
   'show [ip] bgp ipv6 encap neighbors A.B.C.D routes'
  show_ip_bgp_neighbor_routes_cmd_vtysh
   'show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6> [<unicast|multicast|vpn|encap>]] neighbors <A.B.C.D|X:X::X:X|WORD> <flap-statistics|dampened-routes|routes> [json]'

It does not work to obtain Ipv6 route. Although Ipv6 network anonce normal.

for BGP speakers in the DFZ, "bgp import-check" (with inexact match) is pretty much operating best practice. unfortunately it was removed in 5623e90

standard DFZ setup is:

• some network statements in bgpd
• no redistribute in bgpd
• bgp import-check enabled
• IGP or static route providing more specific routes for network statements
• announces should be pulled if no route at all matches network statement

i.e. the network statements function as indirect "aggregate" function. They also should not be bound to zebra static routes specifically, any IGP route should be acceptable.

(=> should match default junisco behavior)

current usage in mainline:
show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6|vpnv4 <all|rd ASN:nn_or_IP-address:nn>>] neighbors [<A.B.C.D|X:X::X:X|WORD>] [json]
show [ip] bgp <view|vrf> all [<ipv4 [<unicast|multicast>]|ipv6 [<unicast|multicast>]|encap [unicast]|vpnv4 [unicast]>] [json]
show [ip] bgp [<ipv4 [<unicast|multicast|vpn|encap>]|ipv6 [<unicast|multicast|vpn|encap>]|encap [unicast]|vpnv4 [unicast]>] regexp REGEX...
show [ip] bgp [<view|vrf> WORD] [<ipv4 [<unicast|multicast>]|ipv6 [<unicast|multicast>]|encap [unicast]|vpnv4 [unicast]>] neighbors <A.B.C.D|X:X::X:X|WORD> [<received-routes|advertised-routes> [route-map WORD]] [json]
show [ip] bgp [<view|vrf> WORD] [<ipv4 [<unicast|multicast>]|ipv6 [<unicast|multicast>]|encap [unicast]|vpnv4 [unicast]>] neighbors <A.B.C.D|X:X::X:X|WORD> <flap-statistics|dampened-routes|routes> [json]
show [ip] bgp vpnv4 all <A.B.C.D|A.B.C.D/M> [json]
show [ip] bgp vpnv4 all neighbors <A.B.C.D|X:X::X:X|WORD> prefix-counts [json]
show [ip] bgp vpnv4 all
show [ip] bgp vpnv4 rd ASN:nn_or_IP-address:nn
show [ip] bgp vpnv4 all tags
show [ip] bgp vpnv4 rd ASN:nn_or_IP-address:nn tags
show [ip] bgp vpnv4 all neighbors A.B.C.D routes [json]
show [ip] bgp vpnv4 rd ASN:nn_or_IP-address:nn neighbors A.B.C.D routes [json]
show [ip] bgp vpnv4 all neighbors A.B.C.D advertised-routes [json]
show [ip] bgp vpnv4 rd ASN:nn_or_IP-address:nn neighbors A.B.C.D advertised-routes [json]

Current on stable/2.0
clear ip bgp * vpnv4 unicast soft in
clear ip bgp * vpnv4 unicast in
clear ip bgp (A.B.C.D|WORD) vpnv4 unicast soft in
clear ip bgp (A.B.C.D|WORD) vpnv4 unicast in
clear ip bgp <1-4294967295> vpnv4 unicast soft in
clear ip bgp <1-4294967295> vpnv4 unicast in
clear ip bgp * vpnv4 unicast soft out
clear ip bgp * vpnv4 unicast out
clear ip bgp (A.B.C.D|WORD) vpnv4 unicast soft out
clear ip bgp (A.B.C.D|WORD) vpnv4 unicast out
clear ip bgp <1-4294967295> vpnv4 unicast soft out
clear ip bgp <1-4294967295> vpnv4 unicast out
clear ip bgp * vpnv4 unicast soft
clear ip bgp (A.B.C.D|WORD) vpnv4 unicast soft
clear ip bgp <1-4294967295> vpnv4 unicast soft
show ip bgp vpnv4 all summary {json}
show ip bgp vpnv4 rd ASN:nn_or_IP-address:nn summary {json}
show ip bgp vpnv4 all neighbors {json}
show ip bgp vpnv4 rd ASN:nn_or_IP-address:nn neighbors {json}
show ip bgp vpnv4 all neighbors A.B.C.D {json}
show ip bgp vpnv4 rd ASN:nn_or_IP-address:nn neighbors A.B.C.D {json}
show ip bgp vpnv4 all A.B.C.D {json}
show ip bgp vpnv4 rd ASN:nn_or_IP-address:nn A.B.C.D {json}
show ip bgp vpnv4 all A.B.C.D/M {json}
show ip bgp vpnv4 rd ASN:nn_or_IP-address:nn A.B.C.D/M {json}
show ip bgp vpnv4 all neighbors (A.B.C.D|X:X::X:X|WORD) prefix-counts {json}
show ip bgp vpnv4 all
show ip bgp vpnv4 rd ASN:nn_or_IP-address:nn
show ip bgp vpnv4 all tags
show ip bgp vpnv4 rd ASN:nn_or_IP-address:nn tags
show ip bgp vpnv4 all neighbors A.B.C.D routes {json}
show ip bgp vpnv4 rd ASN:nn_or_IP-address:nn neighbors A.B.C.D routes {json}
show ip bgp vpnv4 all neighbors A.B.C.D advertised-routes {json}
show ip bgp vpnv4 rd ASN:nn_or_IP-address:nn neighbors A.B.C.D advertised-routes {json}

Currently we have 2 ways of specifying ECMP

1. Via compilation of FRR
2. Via runtime specification

Let's add a 3rd ability to query the kernel( or relevant api ) for any underlying hardware abstraction

Then after we have this input. Choose the min of the 3 to use at run time

Also add the same thing for # of routes. Some hardware has a limitation on the # of routes that can be installed. Allow the code to smartly understand that.

Issue by rwestphal
Thursday Dec 08, 2016 at 17:52 GMT
Originally opened as https://github.com/opensourcerouting/cumulus-private_quagga/issues/9

Regression introduced by commit 6a3b35 ("Zebra: Handle IPv6 address status during initialization").

More specifically, link-local addresses might not meet the following condition on some kernel versions:
https://github.com/opensourcerouting/cumulus-private_quagga/commit/6a3b35#diff-219fcf863f5de80131a9fd6c16919be1R663

Kernel version where this problem is known to happen: 4.4.0-51-generic #72-Ubuntu
Kernel version where this problem is known not to happen: 3.13.0-77-generic #121-Ubuntu

The draft-ietf-idr-shutdown (https://tools.ietf.org/html/draft-ietf-idr-shutdown) document specifies a mechanism to transmit a short freeform message across the wire as part of an Administrative Shutdown Cease NOTIFICATION message. This message serves to inform the neighbor why the BGP session was shut down. This is useful to communicate for instance a ticket reference, contact person or other information to the neighbor.

Issue by rwestphal
Thursday Dec 15, 2016 at 11:35 GMT
Originally opened as https://github.com/opensourcerouting/cumulus-private_quagga/issues/18

This only happens when we are in configure mode and start the command with "do ...". All daemons are affected as well (when we telnet to them directly).

Bug can be reproduced on the 'master' branch.

Backtrace bellow:
ubuntu# conf t
ubuntu(config)# do sh mpl2016/12/15 09:27:35 unknown: Assertion `last_token' failed in file command_match.c, line 373, function command_complete
2016/12/15 09:27:35 unknown: Backtrace for 17 stack frames:
2016/12/15 09:27:35 unknown: [bt 0] /usr/local/lib/libzebra.so.0(zlog_backtrace+0x34) [0x7fa9cc848d8d]
2016/12/15 09:27:35 unknown: [bt 1] /usr/local/lib/libzebra.so.0(_zlog_assert_failed+0xe1) [0x7fa9cc849576]
2016/12/15 09:27:35 unknown: [bt 2] /usr/local/lib/libzebra.so.0(command_complete+0x1f1) [0x7fa9cc8230bf]
2016/12/15 09:27:35 unknown: [bt 3] /usr/local/lib/libzebra.so.0(+0x2a816) [0x7fa9cc825816]
2016/12/15 09:27:35 unknown: [bt 4] /usr/local/lib/libzebra.so.0(cmd_complete_command+0xed) [0x7fa9cc825a86]
2016/12/15 09:27:35 unknown: [bt 5] vtysh() [0x405f0d]
2016/12/15 09:27:35 unknown: [bt 6] /lib/x86_64-linux-gnu/libreadline.so.6(rl_completion_matches+0x96) [0x7fa9cc5d1436]
2016/12/15 09:27:35 unknown: [bt 7] vtysh() [0x405f99]
2016/12/15 09:27:35 unknown: [bt 8] /lib/x86_64-linux-gnu/libreadline.so.6(+0x1c527) [0x7fa9cc5d1527]
2016/12/15 09:27:35 unknown: [bt 9] /lib/x86_64-linux-gnu/libreadline.so.6(rl_complete_internal+0x132) [0x7fa9cc5d1702]
2016/12/15 09:27:35 unknown: [bt 10] /lib/x86_64-linux-gnu/libreadline.so.6(_rl_dispatch_subseq+0x260) [0x7fa9cc5c8990]
2016/12/15 09:27:35 unknown: [bt 11] /lib/x86_64-linux-gnu/libreadline.so.6(readline_internal_char+0x92) [0x7fa9cc5c8e12]
2016/12/15 09:27:35 unknown: [bt 12] /lib/x86_64-linux-gnu/libreadline.so.6(readline+0x55) [0x7fa9cc5c9545]
2016/12/15 09:27:35 unknown: [bt 13] vtysh() [0x403abe]
2016/12/15 09:27:35 unknown: [bt 14] vtysh(main+0x720) [0x4043f3]
2016/12/15 09:27:35 unknown: [bt 15] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7fa9cc20c830]
2016/12/15 09:27:35 unknown: [bt 16] vtysh(_start+0x29) [0x403819]
2016/12/15 09:27:35 unknown: Current thread not known/applicable
log: showing active allocations in memory group libzebra
log: memstats: Vector : 46157 * 16
log: memstats: Vector index : 46157 * (variably sized)
log: memstats: Link List : 4 * 40
log: memstats: Link Node : 17 * 24
log: memstats: VTY : 3 * (variably sized)
log: memstats: Graph : 38 * 8
log: memstats: Graph Node : 23038 * 32
log: memstats: Command Tokens : 5 * (variably sized)
log: memstats: String vector : 3 * (variably sized)
log: memstats: Command desc : 8811 * (variably sized)
log: memstats: Buffer : 1 * 24
log: memstats: Hash : 39 * 40
log: memstats: Hash Bucket : 2972 * 24
log: memstats: Hash Index : 39 * (variably sized)
log: memstats: Temporary memory : 16861 * (variably sized)
log: showing active allocations in memory group vtysh
Aborted (core dumped)

This issue is a question.
due to the multiple commits pushed on stable/2.0, and what is inside master branch, we can observe some changes:

• in the API ( vty)
• in the internals ( the vty engine)
• some features/ bug fixes

is there a strategy integration process currently to push stable/2.0 into master ?
if not, should we trigger one, and putting a deadline for that ?
each stakeholder taking its commit and trying to push to the master branch ?

I ask this question, because I am involved in vpnvx developments, and I am impacted by some modifications done on stable/2.0 and not done on master.
so I would be happy to help on this task, but I want to be sure that there is no strategy integration in parallel being processed.

Regards,

Seen in wireshark, not sure where/when this broke. Testing fix now...

rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -rf ./.deps
rm -f Makefile
make[1]: Leaving directory '/root/frr/vtysh'
Making distclean in ospfclient
make[1]: Entering directory '/root/frr/ospfclient'
Makefile:562: ../ospfd/.deps/ospf_api.Plo: No such file or directory
Makefile:563: ../ospfd/.deps/ospf_dump_api.Plo: No such file or directory
make[1]: *** No rule to make target '../ospfd/.deps/ospf_dump_api.Plo'. Stop.
make[1]: Leaving directory '/root/frr/ospfclient'
Makefile:469: recipe for target 'distclean-recursive' failed
make: *** [distclean-recursive] Error 1

Issue by mwinter-osr
Monday Dec 12, 2016 at 09:24 GMT
Originally opened as https://github.com/opensourcerouting/cumulus-private_quagga/issues/14

Tested based on stable/2.0, commit 2580192 (Dec 8, 2016)

Test results point this to be a common zebra issue (Seen similar failure on ISIS/OSPF/BGP4), but description here is based on BGP4

A new route gets installed correctly to the Kernel, but an update with a new nexthop is not installed.
Example Tests:

• ANVL BGP4-9.5 (and others)
• BGPTOOL (git https://git.netdef.org/scm/netdef/bgptool.git, test test_2ibgp_localpref)

Running the test_2ibgp_localpref from the bgptool will send the same route from 2 peers, with the 2nd announcement having a higher local pref and a different nexthop. The 1st route gets installed into the kernel, but the 2nd route is not installed in the kernel

testroute is 30.0.9.0/24:

comp2-dut# sh ip bgp
BGP table version is 2, local router ID is 192.168.1.101
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
			  i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i30.0.9.0/24      192.168.2.1                   160      0 i
* i                 192.168.1.1                   150      0 i

Displayed  1 out of 2 total prefixes

and

comp2-dut# sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
	   O - OSPF, I - IS-IS, B - BGP, P - PIM, T - Table, v - VNC,
	   V - VPN,
	   > - selected route, * - FIB route

C>* 1.1.1.0/24 is directly connected, eth1
B>* 30.0.9.0/24 [200/0] via 192.168.2.1, eth3, 00:00:03
C>* 192.168.0.101/32 is directly connected, lo
C>* 192.168.1.0/24 is directly connected, eth2
C>* 192.168.2.0/24 is directly connected, eth3
C>* 192.168.3.0/24 is directly connected, eth4
C>* 192.168.122.0/23 is directly connected, eth0

But FreeBSD Kernel shows:

root@comp2-dut:~# netstat -rn 
Routing tables

Internet:
Destination        Gateway            Flags      Netif Expire
1.1.1.0/24         link#2             U          eth1
1.1.1.2            link#2             UHS          lo
30.0.9.0/24        192.168.1.1        UG1        eth2
127.0.0.1          link#7             UH           lo
192.168.0.101      link#7             UH           lo
[...]

From bgpd.log:

2016/12/12 01:21:16 BGP: 192.168.1.1 rcvd UPDATE w/ attr: nexthop 192.168.1.1, origin i, localpref 150, path 
2016/12/12 01:21:16 BGP: 192.168.1.1 rcvd UPDATE wlen 0 attrlen 21 alen 4
2016/12/12 01:21:16 BGP: 192.168.1.1 rcvd 30.0.9.0/24
2016/12/12 01:21:17 BGP: Tx IPv4 route add VRF 0 30.0.9.0/24 metric 0 tag 0 count 1
2016/12/12 01:21:17 BGP:   IPv4 [nexthop 1] 192.168.1.1
2016/12/12 01:21:23 BGP: 192.168.1.1 KEEPALIVE rcvd
2016/12/12 01:21:23 BGP: 192.168.1.1 KEEPALIVE rcvd
2016/12/12 01:21:27 BGP: 192.168.2.1 rcvd UPDATE w/ attr: nexthop 192.168.2.1, origin i, localpref 160, path 
2016/12/12 01:21:27 BGP: 192.168.2.1 rcvd UPDATE wlen 0 attrlen 21 alen 4
2016/12/12 01:21:27 BGP: 192.168.2.1 rcvd 30.0.9.0/24
2016/12/12 01:21:27 BGP: Tx IPv4 route add VRF 0 30.0.9.0/24 metric 0 tag 0 count 1
2016/12/12 01:21:27 BGP:   IPv4 [nexthop 1] 192.168.2.1

and zebra.log:

2016/12/12 01:21:17 ZEBRA: zebra message comes from socket [13]
2016/12/12 01:21:17 ZEBRA: zebra message received [ZEBRA_IPV4_ROUTE_ADD] 25 in VRF 0
2016/12/12 01:21:17 ZEBRA: 0:30.0.9.0/24: Inserting route rn 0x8025d5600, rib 0x8025d0860 (type 9) existing 0x0
2016/12/12 01:21:17 ZEBRA: 0:30.0.9.0/24: Adding route rn 0x8025d5600, rib 0x8025d0860 (type 9)
2016/12/12 01:21:17 ZEBRA: kernel_rtm_ipv4: 30.0.9.0/24: successfully did NH 192.168.1.1
2016/12/12 01:21:17 ZEBRA: 0:30.0.9.0/24: Redist update rib 0x8025d0860 (type 9), old 0x0 (type -1)
2016/12/12 01:21:17 ZEBRA: 0:192.168.1.1/32: Evaluate RNH, type 0 
2016/12/12 01:21:17 ZEBRA: 0:192.168.2.1/32: Evaluate RNH, type 0 
2016/12/12 01:21:17 ZEBRA: Kernel: Len: 200 Type: RTM_ADD
2016/12/12 01:21:17 ZEBRA: Kernel: UP GATEWAY DONE PROTO1 
2016/12/12 01:21:17 ZEBRA: Kernel: message seq 19
2016/12/12 01:21:17 ZEBRA: Kernel: pid 41959, rtm_addrs 0x7
2016/12/12 01:21:17 ZEBRA: rtm_read: got rtm of type 1 (RTM_ADD)
2016/12/12 01:21:17 ZEBRA: rtm_read: RTM_ADD 30.0.9.0/24: done Ok
2016/12/12 01:21:17 ZEBRA: rib_lookup_and_dump: rn 0x8025d5600, rib 0x8025d0860: NOT removed, selected
2016/12/12 01:21:17 ZEBRA: rib_lookup_and_dump: dumping RIB entry 0x8025d0860 for 30.0.9.0/24 vrf 0
2016/12/12 01:21:17 ZEBRA: rib_lookup_and_dump: refcnt == 0, uptime == 1481534477, type == 9, instance == 0, table == 0
2016/12/12 01:21:17 ZEBRA: rib_lookup_and_dump: metric == 0, mtu == 0, distance == 200, flags == 25, status == 10
2016/12/12 01:21:17 ZEBRA: rib_lookup_and_dump: nexthop_num == 1, nexthop_active_num == 1, nexthop_fib_num == 0
2016/12/12 01:21:17 ZEBRA: rib_lookup_and_dump: NH 192.168.1.1 with flags ACTIVE FIB 
2016/12/12 01:21:17 ZEBRA: rib_lookup_and_dump: dump complete
2016/12/12 01:21:18 ZEBRA: Kernel: Len: 168 Type: RTM_MISS
2016/12/12 01:21:18 ZEBRA: Kernel: DONE 
2016/12/12 01:21:18 ZEBRA: Kernel: message seq 0
2016/12/12 01:21:18 ZEBRA: Kernel: pid 0, rtm_addrs 0x1
2016/12/12 01:21:18 ZEBRA: Unprocessed RTM_type: 7
2016/12/12 01:21:18 ZEBRA: Kernel: Len: 168 Type: RTM_MISS
2016/12/12 01:21:18 ZEBRA: Kernel: DONE 
2016/12/12 01:21:18 ZEBRA: Kernel: message seq 0
2016/12/12 01:21:18 ZEBRA: Kernel: pid 0, rtm_addrs 0x1
2016/12/12 01:21:18 ZEBRA: Unprocessed RTM_type: 7
2016/12/12 01:21:27 ZEBRA: zebra message comes from socket [13]
2016/12/12 01:21:27 ZEBRA: zebra message received [ZEBRA_IPV4_ROUTE_ADD] 25 in VRF 0
2016/12/12 01:21:27 ZEBRA: 0:30.0.9.0/24: Inserting route rn 0x8025d5600, rib 0x8025d08c0 (type 9) existing 0x8025d0860
2016/12/12 01:21:27 ZEBRA: rib_delnode: 0:30.0.9.0/24: rn 0x8025d5600, rib 0x8025d0860, removing
2016/12/12 01:21:27 ZEBRA: 0:30.0.9.0/24: Updating route rn 0x8025d5600, rib 0x8025d08c0 (type 9) old 0x8025d0860 (type 9)
2016/12/12 01:21:27 ZEBRA: kernel_rtm_ipv4: odd command RTM_DELETE for flags 1
2016/12/12 01:21:27 ZEBRA: kernel_rtm_ipv4: No useful nexthops were found in RIB entry 0x8025d08c0
2016/12/12 01:21:27 ZEBRA: kernel_rtm_ipv4: No useful nexthops were found in RIB entry 0x8025d08c0
2016/12/12 01:21:27 ZEBRA: 0:30.0.9.0/24: Redist update rib 0x8025d08c0 (type 9), old 0x8025d0860 (type 9)
2016/12/12 01:21:27 ZEBRA: rib_process: 0:30.0.9.0/24: rn 0x8025d5600, removing rib 0x8025d0860
2016/12/12 01:21:27 ZEBRA: rib_unlink: 0:30.0.9.0/24: rn 0x8025d5600, rib 0x8025d0860
2016/12/12 01:21:27 ZEBRA: 0:192.168.1.1/32: Evaluate RNH, type 0 
2016/12/12 01:21:27 ZEBRA: 0:192.168.2.1/32: Evaluate RNH, type 0 
2016/12/12 01:21:27 ZEBRA: Kernel: Len: 200 Type: RTM_ADD
2016/12/12 01:21:27 ZEBRA: Kernel: UP GATEWAY PROTO1 
2016/12/12 01:21:27 ZEBRA: Kernel: message seq 20
2016/12/12 01:21:27 ZEBRA: Kernel: pid 41959, rtm_addrs 0x7
2016/12/12 01:21:28 ZEBRA: Kernel: Len: 168 Type: RTM_MISS
2016/12/12 01:21:28 ZEBRA: Kernel: DONE 
2016/12/12 01:21:28 ZEBRA: Kernel: message seq 0
2016/12/12 01:21:28 ZEBRA: Kernel: pid 0, rtm_addrs 0x1
2016/12/12 01:21:28 ZEBRA: Unprocessed RTM_type: 7
2016/12/12 01:21:28 ZEBRA: Kernel: Len: 168 Type: RTM_MISS
2016/12/12 01:21:28 ZEBRA: Kernel: DONE 
2016/12/12 01:21:28 ZEBRA: Kernel: message seq 0
2016/12/12 01:21:28 ZEBRA: Kernel: pid 0, rtm_addrs 0x1
2016/12/12 01:21:28 ZEBRA: Unprocessed RTM_type: 7

Just a small valgrind nit here.

==18558== Conditional jump or move depends on uninitialised value(s)
==18558==    at 0x4E5C1AB: command_match_r (command_match.c:214)
==18558==    by 0x4E5BFB8: command_match (command_match.c:115)
==18558==    by 0x4E5F49A: cmd_execute_command_real (command.c:794)
==18558==    by 0x4E5F7E4: cmd_execute_command_strict (command.c:922)
==18558==    by 0x4E5F835: command_config_read_one_line (command.c:951)
==18558==    by 0x40570B: vtysh_config_from_file (vtysh.c:661)
==18558==    by 0x40A6EA: vtysh_read_file (vtysh_config.c:373)
==18558==    by 0x40A783: vtysh_read_config (vtysh_config.c:398)
==18558==    by 0x403EED: main (vtysh_main.c:371)
==18558==
==18558== Conditional jump or move depends on uninitialised value(s)
==18558==    at 0x4E5C1AB: command_match_r (command_match.c:214)
==18558==    by 0x4E5C357: command_match_r (command_match.c:293)
==18558==    by 0x4E5C357: command_match_r (command_match.c:293)
==18558==    by 0x4E5C357: command_match_r (command_match.c:293)
==18558==    by 0x4E5BFB8: command_match (command_match.c:115)
==18558==    by 0x4E5F49A: cmd_execute_command_real (command.c:794)
==18558==    by 0x4E5F7E4: cmd_execute_command_strict (command.c:922)
==18558==    by 0x4E5F835: command_config_read_one_line (command.c:951)
==18558==    by 0x40570B: vtysh_config_from_file (vtysh.c:661)
==18558==    by 0x40A6EA: vtysh_read_file (vtysh_config.c:373)
==18558==    by 0x40A783: vtysh_read_config (vtysh_config.c:398)
==18558==    by 0x403EED: main (vtysh_main.c:371)
==18558==

We need to rename the installed libraries to something appropriate so that quagga and frr can co-exist side by side

Per #122 (comment)
exptract.pl can't handled macros (#defines) in DEFUNs. The limits standard c syntax and code extendability.

installing frr deb causes core files to be generated at startup. Stacks follow:

bgpd

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by /usr/lib/frr/bgpd --daemon -A 127.0.0.1'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f1c0068723e in vty_log_fixed ( buf=buf@entry=0x7ffe94a98e09 "BGP: Received signal 11 at 1486365436 (si_addr 0x0, PC 0x7f1c006871a1); aborting...", len=len@entry=83) at vty.c:2572 2572 vty.c: No such file or directory. (gdb) bt #0 0x00007f1c0068723e in vty_log_fixed ( buf=buf@entry=0x7ffe94a98e09 "BGP: Received signal 11 at 1486365436 (si_addr 0x0, PC 0x7f1c006871a1); aborting...", len=len@entry=83) at vty.c:2572 #1 0x00007f1c006a10d5 in zlog_signal (signo=<optimized out>, action=action@entry=0x7f1c006c619b "aborting...", siginfo=<optimized out>, program_counter=0x7f1c006871a1 <vty_log+79>) at log.c:499 #2 0x00007f1c006ab9d0 in core_handler (signo=<optimized out>, siginfo=<optimized out>, context=<optimized out>) at sigevent.c:235 #3 <signal handler called> #4 vty_log (level=0x0, proto_str=proto_str@entry=0x7ffe94a99538 "BGP: ", format=format@entry=0x7f1c006c01ec "Assertion %s' failed in file %s, line %u, function %s",
ctl=ctl@entry=0x7ffe94a99558, va=va@entry=0x7ffe94a995d8) at vty.c:2543
#5 0x00007f1c006a0b3b in vzlog (zl=0x1441590, priority=,
format=0x7f1c006c01ec "Assertion %s' failed in file %s, line %u, function %s", args=args@entry=0x7ffe94a995d8) at log.c:260 #6 0x00007f1c006a12d9 in zlog (zl=zl@entry=0x0, priority=priority@entry=2, format=format@entry=0x7f1c006c01ec "Assertion %s' failed in file %s, line %u, function %s") at log.c:677
#7 0x00007f1c006a1809 in _zlog_assert_failed (assertion=assertion@entry=0x7f1c006c71d5 "mt->n_alloc",
file=file@entry=0x7f1c006c71cc "memory.c", line=line@entry=43,
function=function@entry=0x7f1c006c7268 <func.8042> "mt_count_free") at log.c:722
#8 0x00007f1c006836c3 in mt_count_free (mt=) at memory.c:43
#9 0x00007f1c006b19a2 in mt_count_free (mt=) at memory.c:87
#10 qfree (mt=, ptr=) at memory.c:89
#11 0x00007f1c00693151 in thread_master_free (m=0x143b120) at thread.c:523
#12 0x000000000041552d in bgp_exit (status=0) at bgp_main.c:309
#13 sigint () at bgp_main.c:225
#14 0x00007f1c006aba24 in quagga_sigevent_process () at sigevent.c:111
#15 0x00007f1c006936a1 in thread_fetch (m=0x143b120, fetch=fetch@entry=0x7ffe94a99850) at thread.c:1172
#16 0x0000000000414210 in main (argc=4, argv=0x7ffe94a999e8) at bgp_main.c:570
(gdb)

zebra:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by /usr/lib/frr/zebra -s 90000000 --daemon -A 127.0.0.1'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f00649c923e in vty_log_fixed ( buf=buf@entry=0x7ffc42b88809 "ZEBRA: Received signal 11 at 1486365436 (si_addr 0x0, PC 0x7f00649c91a1); aborting...", len=len@entry=85) at vty.c:2572 2572 vty.c: No such file or directory. (gdb) bt #0 0x00007f00649c923e in vty_log_fixed ( buf=buf@entry=0x7ffc42b88809 "ZEBRA: Received signal 11 at 1486365436 (si_addr 0x0, PC 0x7f00649c91a1); aborting...", len=len@entry=85) at vty.c:2572 #1 0x00007f00649e30d5 in zlog_signal (signo=<optimized out>, action=action@entry=0x7f0064a0819b "aborting...", siginfo=<optimized out>, program_counter=0x7f00649c91a1 <vty_log+79>) at log.c:499 #2 0x00007f00649ed9d0 in core_handler (signo=<optimized out>, siginfo=<optimized out>, context=<optimized out>) at sigevent.c:235 #3 <signal handler called> #4 vty_log (level=0x0, proto_str=proto_str@entry=0x7ffc42b88f38 "ZEBRA: ", format=format@entry=0x7f0064a021ec "Assertion %s' failed in file %s, line %u, function %s",
ctl=ctl@entry=0x7ffc42b88f58, va=va@entry=0x7ffc42b88fd8) at vty.c:2543
#5 0x00007f00649e2b3b in vzlog (zl=0xce5040, priority=,
format=0x7f0064a021ec "Assertion %s' failed in file %s, line %u, function %s", args=args@entry=0x7ffc42b88fd8) at log.c:260 #6 0x00007f00649e32d9 in zlog (zl=zl@entry=0x0, priority=priority@entry=2, format=format@entry=0x7f0064a021ec "Assertion %s' failed in file %s, line %u, function %s") at log.c:677
#7 0x00007f00649e3809 in _zlog_assert_failed (assertion=assertion@entry=0x7f0064a091d5 "mt->n_alloc",
file=file@entry=0x7f0064a091cc "memory.c", line=line@entry=43,
function=function@entry=0x7f0064a09268 <func.8042> "mt_count_free") at log.c:722
#8 0x00007f00649c56c3 in mt_count_free (mt=) at memory.c:43
#9 0x00007f00649f39a2 in mt_count_free (mt=) at memory.c:87
#10 qfree (mt=, ptr=) at memory.c:89
#11 0x00007f00649d5151 in thread_master_free (m=0xce86e0) at thread.c:523
#12 0x00000000004105f6 in sigint () at main.c:228
#13 0x00007f00649eda24 in quagga_sigevent_process () at sigevent.c:111
#14 0x00007f00649d56a1 in thread_fetch (m=0xce86e0, fetch=fetch@entry=0x7ffc42b89280) at thread.c:1172
#15 0x000000000040ca64 in main (argc=6, argv=0x7ffc42b89418) at main.c:481
(gdb)

Showed to Donald and he thinks he knows the issue and suggested assigning to him.

Issue by mwinter-osr
Tuesday Nov 29, 2016 at 20:01 GMT
Originally opened as https://github.com/opensourcerouting/cumulus-private_quagga/issues/6

LDPd needs some cleanup to support a snap package.

Part of the snap security policy is that they can’t write outside of their $SNAP_DATA (which is a unknown location at compile time)

Other daemons are modified to support an option for vty socket location override.

See here
https://github.com/opensourcerouting/cumulus-private_quagga/commit/9c9af95394546560c80280a14fe88fd5161d1536

Running the LDP, I see it still uses a socket at /run/ldpd.sock - which is the LDPD_SOCKET
It's not clear (to me) on what this socket is used for. I assume this is for the communication between the different ldp processes?

Any suggestion on adding a CLI option to override this (similar to —vty_socket ?)

double free in qfree of mt

3181	vty_terminate (void)

• 3182 {

• 3183 if (vty_cwd)

• 3184 XFREE (MTYPE_TMP, vty_cwd);
  3185

• 3186 if (vtyvec && Vvty_serv_thread)
  3187 {

• 3188 vty_reset ();

• 3189 vector_free (vtyvec);

• 3190 vector_free (Vvty_serv_thread);
  3191 }

• 3192 }

  58 void
  59 vector_free (vector v)

• 60 {

• 61 XFREE (MTYPE_VECTOR_INDEX, v->index);

• 62 XFREE (MTYPE_VECTOR, v);

• 63 }
  64

  85 void
  86 qfree (struct memtype *mt, void *ptr)

• 87 {

• 88 if (ptr)

• 89 mt_count_free (mt);

• 90 free (ptr);

• 91 }
  92

Issue to track #107 (review):

1. define VRF_UNKNOWN as VRF_MAX and VRF_MAX be some less than 2^16-1
2. that special values be defined above VRF_MAX
3. that the config interface prevent config of >= VRF_MAX

We should fail the build if we do not have libxml to properly build ldpd

This is not exactly a memory leak but releasing all memory explicitly on exit is always a good idea.

root@ubuntu:/# zebra -f /etc/frr/zebra.conf 
^Czebra: showing active allocations in memory group libzebra
zebra: memstats:  Vector                        :   4350 *         16
zebra: memstats:  Vector index                  :   4350 * (variably sized)
zebra: memstats:  Graph Node                    :   2175 *         32
zebra: memstats:  Command Tokens                :     21 * (variably sized)
zebra: memstats:  Command desc                  : 18446744073709547757 * (variably sized)
zebra: memstats:  Temporary memory              :   3618 * (variably sized)

Issue by mwinter-osr
Thursday Dec 15, 2016 at 11:51 GMT
Originally opened as https://github.com/opensourcerouting/cumulus-private_quagga/issues/19

In a BGP multi-view setup, the nexthops are claimed to be unreachable (and no bestpath is selected because of this.

Example Multi-View Config:

interface r1-eth0
 description to PE router - vlan1
 ip address 172.16.1.254/24
 no link-detect
!
interface r1-stub
 description Stub Network
 ip address 172.20.0.1/28
 no link-detect
!
router bgp 100 view 1
 bgp router-id 172.30.1.1
 timers bgp 60 180
 neighbor 172.16.1.1 remote-as 65001
 neighbor 172.16.1.2 remote-as 65002
 neighbor 172.16.1.5 remote-as 65005

GIves the following output from show ip bgp view 1:

mininet1# show ip bgp view 1
BGP table version is 0, local router ID is 172.30.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
			  i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
   10.0.1.0/24      172.16.1.5                             0 65005 i
					172.16.1.2                             0 65002 i
					172.16.1.1                             0 65001 i
   10.101.0.0/24    172.16.1.1             100             0 65001 i
   10.101.1.0/24    172.16.1.1             100             0 65001 i
   10.101.2.0/24    172.16.1.1             100             0 65001 i
   10.101.3.0/24    172.16.1.1             100             0 65001 i
   10.101.4.0/24    172.16.1.1             100             0 65001 i
   10.101.5.0/24    172.16.1.1             100             0 65001 i
   10.101.6.0/24    172.16.1.1             100             0 65001 i
   10.101.7.0/24    172.16.1.1             100             0 65001 i
[...]

and show ip bgp view 1 10.101.0.0/24 shows:

mininet1# show ip bgp view 1 10.101.0.0/24
BGP routing table entry for 10.101.0.0/24
Paths: (1 available, no best path)
  Not advertised to any peer
  65001
	172.16.1.1 (inaccessible) from 172.16.1.1 (172.16.1.1)
	  Origin IGP, metric 100, localpref 100, invalid, external
	  Community: 1:1
	  AddPath ID: RX 0, TX 5
	  Last update: Thu Dec 15 02:53:34 2016

but the nexthop is connected:

mininet1# show ip route 172.16.1.1
Routing entry for 172.16.1.0/24
  Known via "connected", distance 0, metric 0, best
  * directly connected, r1-eth0

Changing this all from a multi-view config to a "normal" single-view works fine, accepts the next-hop and does the best-path selection:

mininet1# sh ip bgp
BGP table version is 32, local router ID is 172.30.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
			  i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  10.0.1.0/24      172.16.1.5                             0 65005 i
*                   172.16.1.2                             0 65002 i
*>                  172.16.1.1                             0 65001 i
*> 10.101.0.0/24    172.16.1.1             100             0 65001 i
*> 10.101.1.0/24    172.16.1.1             100             0 65001 i
*> 10.101.2.0/24    172.16.1.1             100             0 65001 i
*> 10.101.3.0/24    172.16.1.1             100             0 65001 i
*> 10.101.4.0/24    172.16.1.1             100             0 65001 i

The following popped up during a full valgrind regression run:

==19919== 1 errors in context 1 of 2:
==19919== Conditional jump or move depends on uninitialised value(s)
==19919== at 0x52E7A1: vty_close (vty.c:2275)
==19919== by 0x52FF86: vty_reset (vty.c:2999)
==19919== by 0x5303FD: vty_terminate (vty.c:3130)
==19919== by 0x41EAF7: bgp_exit (bgp_main.c:297)
==19919== by 0x41E961: sigint (bgp_main.c:225)
==19919== by 0x560C6D: quagga_sigevent_process (sigevent.c:111)
==19919== by 0x53AF91: thread_fetch (thread.c:1172)
==19919== by 0x41F413: main (bgp_main.c:570)
==19919== Uninitialised value was created by a stack allocation
==19919== at 0x52E5D5: vty_close (vty.c:2231)
==19919==
==19919== 90 errors in context 2 of 2:
==19919== Conditional jump or move depends on uninitialised value(s)
==19919== at 0x52E7A1: vty_close (vty.c:2275)
==19919== by 0x52D298: vty_read (vty.c:1602)
==19919== by 0x53B605: thread_call (thread.c:1303)
==19919== by 0x41F3F3: main (bgp_main.c:571)
==19919== Uninitialised value was created by a stack allocation
==19919== at 0x52E5D5: vty_close (vty.c:2231)
==19919==

BGPD segfaults on startup due to missing qobj_init().

Edit: nevermind, already fixed

We are seeing ambiguous commands in the
address-family ipv4 uni|mul
address-family ip6 uni|mul

commands

Failure to enable bgp debugging using a sample configuration below.
It seems appending debug does not work, whereas it was working with quagga 1.x.

config file tried
hostname bgpd
password sdncbgpc
log stdout
service advanced-vty

line vty
exec-timeout 0 0
debug bgp

error message
*** Error occurred processing line 9, below:
debug bgp

2017/01/06 15:19:18 BGP: *** Error occurred processing line 9, below:
debug bgp

2017/01/06 15:19:18 BGP: BGPd 2.0.999 starting: vty@2605, bgp@:179
2017/01/06 15:19:21 BGP: Vty connection from ::1

(gdb) bt
#0 0x00007f8a5c930067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8a5c931448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f8a5c96e1b4 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007f8a5c97398e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007f8a5c974696 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#5 0x000055dda631e615 in lsp_clear_data (lsp=lsp@entry=0x55dda73daaa0) at isis_lsp.c:123
#6 0x000055dda631e731 in lsp_destroy (lsp=0x55dda73daaa0) at isis_lsp.c:154
#7 0x000055dda6322ea9 in lsp_tick (thread=) at isis_lsp.c:2670
#8 0x00007f8a5d74539d in thread_call (thread=0x7ffde5c4a0c8) at thread.c:1462
#9 0x000055dda631d070 in main (argc=4, argv=, envp=) at isis_main.c:390
(gdb)

[6:35]

2016/12/14 23:27:32.188829 ISIS: lan hello on non broadcast circuit
2016/12/14 23:27:32.189054 ISIS: %ADJCHANGE: Adjacency to 1921.6810.0009 (swp1) changed from Unknown to Initializing, unspecified
2016/12/14 23:27:32.189064 ISIS: %ADJCHANGE: Adjacency to 1921.6810.0009 (swp1) changed from Initializing to Up, unspecified
2016/12/14 23:27:37.186777 ISIS: ISIS-Upd (FOO): LSP 0000.0000.0000.00-00 seq 0x00000001 with confused checksum received.
2016/12/14 23:27:37.186876 ISIS: ISIS-Spf: TENT is empty SPF-root:r10
2016/12/14 23:27:37.247257 ISIS: ISIS-Upd (FOO): LSP 1921.6810.0009.00-00 invalid LSP is type 0
2016/12/14 23:27:49.675359 ISIS: ISIS-Spf: TENT is empty SPF-root:r10
2016/12/14 23:27:50.250427 ISIS: ISIS-Spf: TENT is empty SPF-root:r10
2016/12/14 23:27:51.189042 ISIS: ISIS-Spf: TENT is empty SPF-root:r10
2016/12/14 23:28:02.189823 ISIS: ISIS-Spf: TENT is empty SPF-root:r10
2016/12/14 23:28:03.252071 ISIS: ISIS-Spf: TENT is empty SPF-root:r10
2016/12/14 23:28:38.532282 ISIS: ISIS-Upd (FOO): L1 LSP 0000.0000.0000.00-00 seq 0x00000001 aged out
2016/12/14 23:30:39.319943 ZEBRA: client 12 disconnected. 9 isis routes removed from the rib
2016/12/14 23:31:09.433950 ZEBRA: Terminating on signal
2016/12/14 23:31:09.433991 ZEBRA: IRDP: Received shutdown notification.

[6:35]

 r6 ---- r9 --- r10
 |\      |       |
 | \     |       |
 |  \    r8 --- r11
 |   r7
 r5  |
 | \ |
 |  r3 --- r2
 | /        |
 r4        r1

[6:36]
In the above topology we are seeing crashes in isis on r11, r4, and r7

[6:36]
config on r10:

[6:37]

interface lo
ip router isis FOO
isis circuit-type level-1
isis passive
!
interface swp1
ip router isis FOO
isis circuit-type level-1
isis network point-to-point
!
interface swp2
ip router isis FOO
isis circuit-type level-1
isis network point-to-point
!
router isis FOO
net 49.0003.1921.6810.0010.00
metric-style wide
is-type level-1
log-adjacency-changes
!```

[6:37]  
oh yeah crash on r10 aswell