ldpd: json support for show commands #13

dwalton76 · 2016-12-17T20:56:01Z

Signed-off-by: Daniel Walton [email protected]

Signed-off-by: Daniel Walton <[email protected]>

dwalton76 · 2016-12-17T20:57:15Z

superm-redxp-05# show mpls ldp interface 
AF   Interface   State  Uptime   Hello Timers  ac
ipv4 swp1        ACTIVE 00:02:04 5/15           1
ipv4 swp2        ACTIVE 00:02:04 5/15           1
ipv4 swp3        ACTIVE 00:02:04 5/15           1
ipv4 swp4        ACTIVE 00:02:04 5/15           1

superm-redxp-05# 

superm-redxp-05# show mpls ldp interface json

{
  "swp1":{
    "addressFamily":"ipv4",
    "state":"ACTIVE",
    "uptime":"00:02:08",
    "helloInterval":5,
    "holdtime":15,
    "adjacencyCount":1
  },
  "swp2":{
    "addressFamily":"ipv4",
    "state":"ACTIVE",
    "uptime":"00:02:08",
    "helloInterval":5,
    "holdtime":15,
    "adjacencyCount":1
  },
  "swp3":{
    "addressFamily":"ipv4",
    "state":"ACTIVE",
    "uptime":"00:02:08",
    "helloInterval":5,
    "holdtime":15,
    "adjacencyCount":1
  },
  "swp4":{
    "addressFamily":"ipv4",
    "state":"ACTIVE",
    "uptime":"00:02:08",
    "helloInterval":5,
    "holdtime":15,
    "adjacencyCount":1
  }
}
superm-redxp-05#

dwalton76 · 2016-12-17T20:57:33Z

superm-redxp-05# show mpls ldp binding 
6.0.0.3/32
        Local binding: label: imp-null
        Remote bindings:
            Peer                Label
            -----------------   ---------
            6.0.0.7             24
            6.0.0.8             24
            6.0.0.9             23
            6.0.0.10            23
6.0.0.4/32
        Local binding: label: 20
        Remote bindings:
            Peer                Label
            -----------------   ---------
            6.0.0.7             18
            6.0.0.8             18
            6.0.0.9             16
            6.0.0.10            16
6.0.0.5/32
        Local binding: label: 21
        Remote bindings:
            Peer                Label
            -----------------   ---------
            6.0.0.7             16
            6.0.0.8             16
            6.0.0.9             17
            6.0.0.10            17
6.0.0.6/32
        Local binding: label: 22
        Remote bindings:
            Peer                Label
            -----------------   ---------
            6.0.0.7             19
            6.0.0.8             17
            6.0.0.9             18
            6.0.0.10            18
6.0.0.7/32
        Local binding: label: 16
        Remote bindings:
            Peer                Label
            -----------------   ---------
            6.0.0.7             imp-null
            6.0.0.8             19
            6.0.0.9             19
            6.0.0.10            19
6.0.0.8/32
        Local binding: label: 17
        Remote bindings:
            Peer                Label
            -----------------   ---------
            6.0.0.7             17
            6.0.0.8             imp-null
            6.0.0.9             20
            6.0.0.10            20
6.0.0.9/32
        Local binding: label: 18
        Remote bindings:
            Peer                Label
            -----------------   ---------
            6.0.0.7             20
            6.0.0.8             20
            6.0.0.9             imp-null
            6.0.0.10            21
6.0.0.10/32
        Local binding: label: 19
        Remote bindings:
            Peer                Label
            -----------------   ---------
            6.0.0.7             22
            6.0.0.8             21
            6.0.0.9             21
            6.0.0.10            imp-null
10.0.0.0/22
        Local binding: label: imp-null
        No remote bindings
20.0.9.0/24
        Local binding: label: 23
        Remote bindings:
            Peer                Label
            -----------------   ---------
            6.0.0.7             21
            6.0.0.8             22
            6.0.0.9             imp-null
            6.0.0.10            22
20.0.10.0/24
        Local binding: label: 24
        Remote bindings:
            Peer                Label
            -----------------   ---------
            6.0.0.7             23
            6.0.0.8             23
            6.0.0.9             22
            6.0.0.10            imp-null
192.168.0.0/24
        Local binding: label: -
        Remote bindings:
            Peer                Label
            -----------------   ---------
            6.0.0.7             imp-null
            6.0.0.8             imp-null
            6.0.0.9             imp-null
            6.0.0.10            imp-null

superm-redxp-05#



superm-redxp-05# show mpls ldp binding json

{
  "6.0.0.3\/32":{
    "localLabel":"imp-null",
    "remoteLabel":[
      {
        "nexthop":"6.0.0.7",
        "label":"24"
      },
      {
        "nexthop":"6.0.0.8",
        "label":"24"
      },
      {
        "nexthop":"6.0.0.9",
        "label":"23"
      },
      {
        "nexthop":"6.0.0.10",
        "label":"23"
      }
    ]
  },
  "6.0.0.4\/32":{
    "localLabel":"20",
    "remoteLabel":[
      {
        "nexthop":"6.0.0.7",
        "label":"18"
      },
      {
        "nexthop":"6.0.0.8",
        "label":"18"
      },
      {
        "nexthop":"6.0.0.9",
        "label":"16"
      },
      {
        "nexthop":"6.0.0.10",
        "label":"16"
      }
    ]
  },
  "6.0.0.5\/32":{
    "localLabel":"21",
    "remoteLabel":[
      {
        "nexthop":"6.0.0.7",
        "label":"16"
      },
      {
        "nexthop":"6.0.0.8",
        "label":"16"
      },
      {
        "nexthop":"6.0.0.9",
        "label":"17"
      },
      {
        "nexthop":"6.0.0.10",
        "label":"17"
      }
    ]
  },
  "6.0.0.6\/32":{
    "localLabel":"22",
    "remoteLabel":[
      {
        "nexthop":"6.0.0.7",
        "label":"19"
      },
      {
        "nexthop":"6.0.0.8",
        "label":"17"
      },
      {
        "nexthop":"6.0.0.9",
        "label":"18"
      },
      {
        "nexthop":"6.0.0.10",
        "label":"18"
      }
    ]
  },
  "6.0.0.7\/32":{
    "localLabel":"16",
    "remoteLabel":[
      {
        "nexthop":"6.0.0.7",
        "label":"imp-null"
      },
      {
        "nexthop":"6.0.0.8",
        "label":"19"
      },
      {
        "nexthop":"6.0.0.9",
        "label":"19"
      },
      {
        "nexthop":"6.0.0.10",
        "label":"19"
      }
    ]
  },
  "6.0.0.8\/32":{
    "localLabel":"17",
    "remoteLabel":[
      {
        "nexthop":"6.0.0.7",
        "label":"17"
      },
      {
        "nexthop":"6.0.0.8",
        "label":"imp-null"
      },
      {
        "nexthop":"6.0.0.9",
        "label":"20"
      },
      {
        "nexthop":"6.0.0.10",
        "label":"20"
      }
    ]
  },
  "6.0.0.9\/32":{
    "localLabel":"18",
    "remoteLabel":[
      {
        "nexthop":"6.0.0.7",
        "label":"20"
      },
      {
        "nexthop":"6.0.0.8",
        "label":"20"
      },
      {
        "nexthop":"6.0.0.9",
        "label":"imp-null"
      },
      {
        "nexthop":"6.0.0.10",
        "label":"21"
      }
    ]
  },
  "6.0.0.10\/32":{
    "localLabel":"19",
    "remoteLabel":[
      {
        "nexthop":"6.0.0.7",
        "label":"22"
      },
      {
        "nexthop":"6.0.0.8",
        "label":"21"
      },
      {
        "nexthop":"6.0.0.9",
        "label":"21"
      },
      {
        "nexthop":"6.0.0.10",
        "label":"imp-null"
      }
    ]
  },
  "10.0.0.0\/22":{
    "localLabel":"imp-null",
    "remoteLabel":[
    ]
  },
  "20.0.9.0\/24":{
    "localLabel":"23",
    "remoteLabel":[
      {
        "nexthop":"6.0.0.7",
        "label":"21"
      },
      {
        "nexthop":"6.0.0.8",
        "label":"22"
      },
      {
        "nexthop":"6.0.0.9",
        "label":"imp-null"
      },
      {
        "nexthop":"6.0.0.10",
        "label":"22"
      }
    ]
  },
  "20.0.10.0\/24":{
    "localLabel":"24",
    "remoteLabel":[
      {
        "nexthop":"6.0.0.7",
        "label":"23"
      },
      {
        "nexthop":"6.0.0.8",
        "label":"23"
      },
      {
        "nexthop":"6.0.0.9",
        "label":"22"
      },
      {
        "nexthop":"6.0.0.10",
        "label":"imp-null"
      }
    ]
  },
  "192.168.0.0\/24":{
    "localLabel":"-",
    "remoteLabel":[
      {
        "nexthop":"6.0.0.7",
        "label":"imp-null"
      },
      {
        "nexthop":"6.0.0.8",
        "label":"imp-null"
      },
      {
        "nexthop":"6.0.0.9",
        "label":"imp-null"
      },
      {
        "nexthop":"6.0.0.10",
        "label":"imp-null"
      }
    ]
  }
}
superm-redxp-05#

dwalton76 · 2016-12-17T20:57:45Z

superm-redxp-05# show mpls ldp discovery 
Local LDP Identifier: 6.0.0.3:0
Discovery Sources:
  Interfaces:
    swp1: xmit/recv
      LDP Id: 6.0.0.7:0, Transport address: 6.0.0.7
          Hold time: 15 sec
    swp2: xmit/recv
      LDP Id: 6.0.0.8:0, Transport address: 6.0.0.8
          Hold time: 15 sec
    swp3: xmit/recv
      LDP Id: 6.0.0.9:0, Transport address: 6.0.0.9
          Hold time: 15 sec
    swp4: xmit/recv
      LDP Id: 6.0.0.10:0, Transport address: 6.0.0.10
          Hold time: 15 sec
  Targeted Hellos:

superm-redxp-05# 
superm-redxp-05# 
superm-redxp-05# show mpls ldp discovery json
{
  "interfaces":{
    "swp1":{
      "transmit":true
    },
    "swp2":{
      "transmit":true
    },
    "swp3":{
      "transmit":true
    },
    "swp4":{
      "transmit":true
    }
  },
  "adjacencyLink":[
    {
      "id":"6.0.0.7",
      "transportAddress":"6.0.0.7",
      "holdtime":15
    },
    {
      "id":"6.0.0.8",
      "transportAddress":"6.0.0.8",
      "holdtime":15
    },
    {
      "id":"6.0.0.9",
      "transportAddress":"6.0.0.9",
      "holdtime":15
    },
    {
      "id":"6.0.0.10",
      "transportAddress":"6.0.0.10",
      "holdtime":15
    }
  ],
  "id":"6.0.0.3"
}
superm-redxp-05#

dwalton76 · 2016-12-17T20:58:25Z

superm-redxp-05# show mpls ldp neighbor 
Peer LDP Identifier: 6.0.0.7:0
  TCP connection: 6.0.0.3:646 - 6.0.0.7:44386
  Session Holdtime: 180 sec
  State: OPERATIONAL; Downstream-Unsolicited
  Up time: 00:06:51
  LDP Discovery Sources:
    IPv4:
      Interface: swp1

Peer LDP Identifier: 6.0.0.8:0
  TCP connection: 6.0.0.3:646 - 6.0.0.8:41463
  Session Holdtime: 180 sec
  State: OPERATIONAL; Downstream-Unsolicited
  Up time: 00:06:51
  LDP Discovery Sources:
    IPv4:
      Interface: swp2

Peer LDP Identifier: 6.0.0.9:0
  TCP connection: 6.0.0.3:646 - 6.0.0.9:60726
  Session Holdtime: 180 sec
  State: OPERATIONAL; Downstream-Unsolicited
  Up time: 00:06:51
  LDP Discovery Sources:
    IPv4:
      Interface: swp3

Peer LDP Identifier: 6.0.0.10:0
  TCP connection: 6.0.0.3:646 - 6.0.0.10:39119
  Session Holdtime: 180 sec
  State: OPERATIONAL; Downstream-Unsolicited
  Up time: 00:06:51
  LDP Discovery Sources:
    IPv4:
      Interface: swp4

superm-redxp-05# 
superm-redxp-05# 
superm-redxp-05# show mpls ldp neighbor  json
{
  "6.0.0.7":{
    "peerId":"6.0.0.7",
    "tcpLocalAddress":"6.0.0.3",
    "tcpLocalPort":646,
    "tcpRemoteAddress":"6.0.0.7",
    "tcpRemotePort":44386,
    "holdtime":180,
    "state":"OPERATIONAL",
    "downstreamUnsolicited":true,
    "upTime":"00:06:53",
    "adjacencyLink":[
      "swp1"
    ]
  },
  "6.0.0.8":{
    "peerId":"6.0.0.8",
    "tcpLocalAddress":"6.0.0.3",
    "tcpLocalPort":646,
    "tcpRemoteAddress":"6.0.0.8",
    "tcpRemotePort":41463,
    "holdtime":180,
    "state":"OPERATIONAL",
    "downstreamUnsolicited":true,
    "upTime":"00:06:53",
    "adjacencyLink":[
      "swp2"
    ]
  },
  "6.0.0.9":{
    "peerId":"6.0.0.9",
    "tcpLocalAddress":"6.0.0.3",
    "tcpLocalPort":646,
    "tcpRemoteAddress":"6.0.0.9",
    "tcpRemotePort":60726,
    "holdtime":180,
    "state":"OPERATIONAL",
    "downstreamUnsolicited":true,
    "upTime":"00:06:53",
    "adjacencyLink":[
      "swp3"
    ]
  },
  "6.0.0.10":{
    "peerId":"6.0.0.10",
    "tcpLocalAddress":"6.0.0.3",
    "tcpLocalPort":646,
    "tcpRemoteAddress":"6.0.0.10",
    "tcpRemotePort":39119,
    "holdtime":180,
    "state":"OPERATIONAL",
    "downstreamUnsolicited":true,
    "upTime":"00:06:53",
    "adjacencyLink":[
      "swp4"
    ]
  }
}
superm-redxp-05#

dwalton76 · 2016-12-17T21:01:48Z

@rwestphal can you take a look at this one

rwestphal · 2016-12-19T14:59:42Z

A few additional issues:

1 - There's no "json" option for the L2VPN commands (which are only two by now).

2 - This is the output of "show mpls ldp neighbor json" on my dual-stack ldpd test network:

ubuntu# show mpls ldp neighbor json 
  "3.3.3.3":{
    "peerId":"3.3.3.3",
    "tcpLocalAddress":"2001:db8:1000::2",
    "tcpLocalPort":646,
    "tcpRemoteAddress":"2001:db8:1000::3",
    "tcpRemotePort":42501,
    "holdtime":180,
    "state":"OPERATIONAL",
    "downstreamUnsolicited":true,
    "upTime":"00:00:11",
    "adjacencyLink":[
      "rt2-eth1",
      "rt2-eth1",
      "rt2-eth2",
      "rt2-eth2"
    ]
  },
(...)

We are not showing the address-family of the adjacencies.

I guess we could change this:

"adjacencyLink":[
   "rt2-eth1",
   "rt2-eth1",
   "rt2-eth2",
   "rt2-eth2"
]

To this (*):

"discoverySources":[  
   ipv4:[  
      "interface: rt2-eth1",
      "interface: rt2-eth2",
      "targetedHello: 1.1.1.1"
   ],
   ipv6:[  
      "interface: rt2-eth1",
      "interface: rt2-eth2"
   ]
]

* I introduced one targeted adjacency in the output to show how it would fit in there.

3 - In the same command above, I think we can remove this line from the json output:

"downstreamUnsolicited":true

ldpd supports only this mode of operation (which is not really a limitation), so it's a moot piece of information.

4 - The "show mpls ldp interface json" command is not showing all interface/address-family combinations:

ubuntu# show run
(...)
mpls ldp
(...)
 !
 address-family ipv4
  (...)
  !
  interface rt2-eth0
  !
  interface rt2-eth1
  !
  interface rt2-eth2
  !
 !
 address-family ipv6
  (...)
  !
  interface rt2-eth0
  !
  interface rt2-eth1
  !
  interface rt2-eth2
  !
 !
!
(...)
ubuntu# 
ubuntu# show mpls ldp interface json 
{
  "rt2-eth0":{
    "addressFamily":"ipv6",
    "state":"ACTIVE",
    "uptime":"00:02:40",
    "helloInterval":5,
    "holdtime":15,
    "adjacencyCount":1
  },
  "rt2-eth1":{
    "addressFamily":"ipv6",
    "state":"ACTIVE",
    "uptime":"00:02:40",
    "helloInterval":5,
    "holdtime":15,
    "adjacencyCount":2
  },
  "rt2-eth2":{
    "addressFamily":"ipv6",
    "state":"ACTIVE",
    "uptime":"00:02:40",
    "helloInterval":5,
    "holdtime":15,
    "adjacencyCount":1
  }
}

5 - ldpd segfaults on "show mpls ldp discovery json" if we have any targeted neighbor to display:

ubuntu# show mpls ldp discovery json 
vtysh: error reading from ldpd: Success (0)Warning: closing connection to ldpd because of an I/O error!

dwalton76 · 2016-12-19T19:10:06Z

For #1 since ldpd/ldp_vty_cmds.c is auto-generated can we

delete this file from the repo and add it to .gitignore
have the make do tools/xml2cli.pl ldpd/ldp_vty.xml > ldpd/ldp_vty_cmds.c

RIght now with that file checked in it is very easy to overlook the fact that it should not be edited.

I just tried tools/xml2cli.pl ldpd/ldp_vty.xml > ldpd/ldp_vty_cmds.c but xml2cli.pl does not support the "{}" notation so it is creating another DEFUN where the "json" option is present instead of adding a "{json}" to the end of the existing DEFUN. Now that I think about it since this branch has all of Quentin's parser work it would be "[json]". My PERL is pretty rusty though, can you update xml2cli.pl to have it support the new "[]" format?

dwalton76 · 2016-12-19T19:18:41Z

For #2 the style in all of quagga is a damn mess and is very inconsistent. ldpd is using a style unlike any of the other components :( I'll search and replace all instances of 8 whitespaces and replace them with a TAB though.

rwestphal · 2016-12-19T19:20:06Z

Yes, I thought about creating a make target for the auto-generated files. But the problem with that is that it would add another dependency to build FRR, which can be a problem on some platforms. So, since ldp_vty.xml is barely changed, I think doing that is not worth the hassle.

Regarding the "{}" notation, indeed. xml2cli.pl was written a few years ago and I need to extended it to make use of this new feature. But having a new command just to add the "json" option should not be a "show stopper", it's only dumb and inefficient. I should have a patch for this in a few hours.

dwalton76 · 2016-12-19T19:23:05Z

For #3 yeah that would make more sense...will fix this

dwalton76 · 2016-12-19T19:29:15Z

For #5 (your 2nd #1) right I did not tackle those two for now...we can come back to them later

dwalton76 · 2016-12-19T19:29:52Z

For #6 ack let me try dual-stack, I did not test that.

dwalton76 · 2016-12-19T19:30:21Z

Ack #7 will remove "downstreamUnsolicited":true

dwalton76 · 2016-12-19T19:31:19Z

@rwestphal can you send me your dual-stack config with target neighbors?

rwestphal · 2016-12-19T19:34:30Z

Sure, will send by email now.

dwalton76 · 2016-12-19T19:39:06Z

Wow this interface is tough for having multiple conversations...I think if you start a review you can click on "+" to leave a comment and then we can reply to each other. That may be a little easier for both of us :)

Agreed xml2cli.pl isn't a show stopper but if it is something you think you can knock out really quick I'll hold off and wait for it. If not I'm fine with it putting in the extra DEFUNs.

Having xml2cli.pl run as part of the build and removing ldp_vty_cmds.c from the repo seems like a must though. We already depend on PERL for building (extract.pl) so it wouldn't be adding a new dependancy.

rwestphal

So, just clicked on "Add your review". Not really sure if this changes anything regarding the interface for conversation.

Regarding xml2cli.pl. please give me 10 minutes and I should have something ready.

rwestphal · 2016-12-19T22:11:52Z

@dwalton76 I've just sent to the list a patch to extend xml2cli.pl as you requested.

Now, for each command, you need to modify the XML file as follows:

@@ -272,7 +272,9 @@
    <!-- exec mode commands -->
   <subtree name="ldp_show_af">
-    <option name="binding" help="Label Information Base (LIB) information" function="ldp_vty_show_binding"/>
+    <option name="binding" help="Label Information Base (LIB) information">
+      <option name="json" arg="json" optional="true" help="JavaScript Object Notation" function="ldp_vty_show_binding"/>
+    </option>
     <option name="discovery" help="Discovery Hello Information" function="ldp_vty_show_discovery"/>
     <option name="interface" help="interface information" function="ldp_vty_show_interface"/>
   </subtree>

Then the new output of the script should be exactly what you want:

@@ -1099,15 +1099,20 @@ DEFUN (ldp_show_mpls_ldp_neighbor,
   return ldp_vty_show_neighbor (vty, args);
 }
 
-DEFUN (ldp_show_mpls_ldp_binding,
-       ldp_show_mpls_ldp_binding_cmd,
-       "show mpls ldp binding",
+DEFUN (ldp_show_mpls_ldp_binding_json,
+       ldp_show_mpls_ldp_binding_json_cmd,
+       "show mpls ldp binding [json]",
        "Show running system information\n"
        "MPLS information\n"
        "Label Distribution Protocol\n"
-       "Label Information Base (LIB) information\n")
+       "Label Information Base (LIB) information\n"
+       "JavaScript Object Notation\n")
 {
-  struct vty_arg *args[] = { NULL };
+  struct vty_arg *args[] =
+    {
+      &(struct vty_arg) { .name = "json", .value = (argc > 4 ? argv[4]->arg : NULL) },
+      NULL
+    };
   return ldp_vty_show_binding (vty, args);
 }

donaldsharp · 2017-01-03T13:11:01Z

@dwalton76 and @rwestphal What can I do to help drive this to completion?

dwalton76 · 2017-01-03T19:01:27Z

sorry, will pick this back up either this week or next and address all of the points that Renato raised

rwestphal · 2017-01-03T20:50:37Z

I'd say that 95% of the work is already done. @dwalton76, if you don't mind I can update your patch to address the points I mentioned earlier, it's only a few things that need to be changed.

dwalton76 · 2017-01-04T18:26:55Z

@rwestphal that is fine with me. Thanks!

The topotest bgp_srv6_sid_explicit generates the crash dump: ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0) The signal is caused by a READ memory access. #0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264 FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611 FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807 FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314 FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67 FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115 FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245 FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313 FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425 FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521 FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011 FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219 FRRouting#12 0x55a58a73079d in main zebra/main.c:550 FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360 FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4) Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs") Signed-off-by: Dmytro Shytyi <[email protected]> Signed-off-by: Philippe Guibert <[email protected]>

The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <[email protected]>

The topotest bgp_srv6_sid_explicit generates the crash dump: ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0) The signal is caused by a READ memory access. #0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264 FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611 FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807 FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314 FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67 FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115 FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245 FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313 FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425 FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521 FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011 FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219 FRRouting#12 0x55a58a73079d in main zebra/main.c:550 FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360 FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4) Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs") Signed-off-by: Dmytro Shytyi <[email protected]> Signed-off-by: Philippe Guibert <[email protected]>

bgp_flowspec.test_bgp_flowspec_topo started to fail (crash) after this. Let's revert it for now. It's freed a bit above already: hash_release(bpm->entry_hash, bpme); bgp_pbr_match_entry_free(bpme); ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x60e00009f8a0 #0 0x7f27d6cb7f04 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:119 #1 0x7f27d6c264f6 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common/sanitizer_stacktrace.h:131 #2 0x7f27d6c264f6 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1058 #3 0x7f27d68254df in mt_count_free lib/memory.c:83 #4 0x7f27d68254df in qfree lib/memory.c:135 #5 0x5637d57b04a2 in bgp_pbr_match_entry_free bgpd/bgp_pbr.c:977 #6 0x5637d57b04a2 in bgp_pbr_flush_entry bgpd/bgp_pbr.c:1737 #7 0x5637d57b40be in bgp_pbr_policyroute_remove_from_zebra_unit bgpd/bgp_pbr.c:1980 #8 0x5637d57bb7c0 in bgp_pbr_policyroute_remove_from_zebra bgpd/bgp_pbr.c:2144 #9 0x5637d57bb7c0 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2781 #10 0x5637d57bb7c0 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2905 #11 0x5637d58d23e1 in bgp_zebra_withdraw_actual bgpd/bgp_zebra.c:1733 #12 0x5637d57ccc9e in bgp_cleanup_table bgpd/bgp_route.c:7300 #13 0x5637d57e27d2 in bgp_cleanup_routes bgpd/bgp_route.c:7318 #14 0x5637d5911b91 in bgp_delete bgpd/bgpd.c:4370 #15 0x5637d56961b4 in bgp_exit bgpd/bgp_main.c:212 #16 0x5637d56961b4 in sigint bgpd/bgp_main.c:162 #17 0x7f27d68af501 in frr_sigevent_process lib/sigevent.c:117 #18 0x7f27d68db77a in event_fetch lib/event.c:1742 #19 0x7f27d68027e4 in frr_run lib/libfrr.c:1251 #20 0x5637d5697c55 in main bgpd/bgp_main.c:569 #21 0x7f27d630c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #22 0x7f27d630c304 in __libc_start_main_impl ../csu/libc-start.c:360 #23 0x5637d5695ac0 in _start (/usr/lib/frr/bgpd+0x2cfac0) 0x60e00009f8a0 is located 0 bytes inside of 160-byte region [0x60e00009f8a0,0x60e00009f940) freed by thread T0 here: #0 0x7f27d6cb76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52 #1 0x7f27d6825500 in qfree lib/memory.c:136 #2 0x5637d57b0366 in bgp_pbr_match_entry_free bgpd/bgp_pbr.c:977 #3 0x5637d57b0366 in bgp_pbr_flush_entry bgpd/bgp_pbr.c:1715 #4 0x5637d57b40be in bgp_pbr_policyroute_remove_from_zebra_unit bgpd/bgp_pbr.c:1980 #5 0x5637d57bb7c0 in bgp_pbr_policyroute_remove_from_zebra bgpd/bgp_pbr.c:2144 #6 0x5637d57bb7c0 in bgp_pbr_handle_entry bgpd/bgp_pbr.c:2781 #7 0x5637d57bb7c0 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2905 #8 0x5637d58d23e1 in bgp_zebra_withdraw_actual bgpd/bgp_zebra.c:1733 #9 0x5637d57ccc9e in bgp_cleanup_table bgpd/bgp_route.c:7300 #10 0x5637d57e27d2 in bgp_cleanup_routes bgpd/bgp_route.c:7318 #11 0x5637d5911b91 in bgp_delete bgpd/bgpd.c:4370 #12 0x5637d56961b4 in bgp_exit bgpd/bgp_main.c:212 #13 0x5637d56961b4 in sigint bgpd/bgp_main.c:162 #14 0x7f27d68af501 in frr_sigevent_process lib/sigevent.c:117 #15 0x7f27d68db77a in event_fetch lib/event.c:1742 #16 0x7f27d68027e4 in frr_run lib/libfrr.c:1251 #17 0x5637d5697c55 in main bgpd/bgp_main.c:569 #18 0x7f27d630c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 This reverts commit d0df550. Signed-off-by: Donatas Abraitis <[email protected]>

The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <[email protected]>

The topotest bgp_srv6_sid_explicit generates the crash dump: ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0) The signal is caused by a READ memory access. #0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264 FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611 FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807 FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314 FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67 FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115 FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245 FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313 FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425 FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521 FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011 FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219 FRRouting#12 0x55a58a73079d in main zebra/main.c:550 FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360 FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4) Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs") Signed-off-by: Dmytro Shytyi <[email protected]> Signed-off-by: Philippe Guibert <[email protected]>

This commit addresses a leak where temporary memory allocated earlier by the `prefix_copy` function for AF_FLOWSPEC prefixes was not being freed. To ensure proper memory management, we now release this temporary memory by calling `prefix_flowspec_ptr_free`. The ASan leak log for reference: ``` *********************************************************************************** Address Sanitizer Error detected in bgp_flowspec.test_bgp_flowspec_topo/r1.asan.bgpd.11539 ================================================================= ==11539==ERROR: LeakSanitizer: detected memory leaks Direct leak of 56 byte(s) in 2 object(s) allocated from: #0 0x7feaa956ad28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) FRRouting#1 0x7feaa8f670da in qcalloc lib/memory.c:105 FRRouting#2 0x7feaa8fac1d4 in prefix_copy lib/prefix.c:346 FRRouting#3 0x7feaa8ff43e8 in route_node_get lib/table.c:274 FRRouting#4 0x56247cc798c0 in bgp_node_get bgpd/bgp_table.h:236 FRRouting#5 0x56247cc798c0 in bgp_afi_node_get bgpd/bgp_route.c:145 FRRouting#6 0x56247cc92622 in bgp_update bgpd/bgp_route.c:4188 FRRouting#7 0x56247ce55b21 in bgp_nlri_parse_flowspec bgpd/bgp_flowspec.c:193 FRRouting#8 0x56247cc4cdd8 in bgp_nlri_parse bgpd/bgp_packet.c:350 FRRouting#9 0x56247cc4f37c in bgp_update_receive bgpd/bgp_packet.c:2153 FRRouting#10 0x56247cc591e2 in bgp_process_packet bgpd/bgp_packet.c:3214 FRRouting#11 0x7feaa9005b99 in event_call lib/event.c:1979 FRRouting#12 0x7feaa8f4a379 in frr_run lib/libfrr.c:1213 FRRouting#13 0x56247cb51b21 in main bgpd/bgp_main.c:510 FRRouting#14 0x7feaa7f8dc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 56 byte(s) leaked in 2 allocation(s). *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <[email protected]> (cherry picked from commit a7fe30e) Conflicts: bgpd/bgp_table.c lib/prefix.c lib/prefix.h lib/table.c Signed-off-by: Louis Scalbert <[email protected]> Signed-off-by: Philippe Guibert <[email protected]>

Upon examining this Indirect leak: Indirect leak of 160 byte(s) in 4 object(s) allocated from: #0 0x7fe4f40b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x7fe4f3c24c1d in qcalloc lib/memory.c:111 #2 0x7fe4f3c03441 in list_new lib/linklist.c:49 #3 0x564c81d076f9 in ospf_spf_vertex_copy ospfd/ospf_spf.c:335 #4 0x564c81d0bff2 in ospf_spf_copy ospfd/ospf_spf.c:378 #5 0x564c81d158e8 in ospf_ti_lfa_generate_p_space ospfd/ospf_ti_lfa.c:787 #6 0x564c81d162f5 in ospf_ti_lfa_generate_p_spaces ospfd/ospf_ti_lfa.c:923 #7 0x564c81d16532 in ospf_ti_lfa_compute ospfd/ospf_ti_lfa.c:1101 #8 0x564c81d0e942 in ospf_spf_calculate_area ospfd/ospf_spf.c:1811 #9 0x564c81d0eaa6 in ospf_spf_calculate_areas ospfd/ospf_spf.c:1840 #10 0x564c81d0eda2 in ospf_spf_calculate_schedule_worker ospfd/ospf_spf.c:1871 #11 0x7fe4f3cdd7c3 in event_call lib/event.c:2009 #12 0x7fe4f3c027e9 in frr_run lib/libfrr.c:1252 #13 0x564c81c95191 in main ospfd/ospf_main.c:307 #14 0x7fe4f370c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 It was noticed that the vertex has another list that is not being cleanedup. Let's allow this to happen. Signed-off-by: Donald Sharp <[email protected]>

Upon examining this Indirect leak: Indirect leak of 160 byte(s) in 4 object(s) allocated from: #0 0x7fe4f40b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x7fe4f3c24c1d in qcalloc lib/memory.c:111 #2 0x7fe4f3c03441 in list_new lib/linklist.c:49 #3 0x564c81d076f9 in ospf_spf_vertex_copy ospfd/ospf_spf.c:335 #4 0x564c81d0bff2 in ospf_spf_copy ospfd/ospf_spf.c:378 #5 0x564c81d158e8 in ospf_ti_lfa_generate_p_space ospfd/ospf_ti_lfa.c:787 #6 0x564c81d162f5 in ospf_ti_lfa_generate_p_spaces ospfd/ospf_ti_lfa.c:923 #7 0x564c81d16532 in ospf_ti_lfa_compute ospfd/ospf_ti_lfa.c:1101 #8 0x564c81d0e942 in ospf_spf_calculate_area ospfd/ospf_spf.c:1811 #9 0x564c81d0eaa6 in ospf_spf_calculate_areas ospfd/ospf_spf.c:1840 #10 0x564c81d0eda2 in ospf_spf_calculate_schedule_worker ospfd/ospf_spf.c:1871 #11 0x7fe4f3cdd7c3 in event_call lib/event.c:2009 #12 0x7fe4f3c027e9 in frr_run lib/libfrr.c:1252 #13 0x564c81c95191 in main ospfd/ospf_main.c:307 #14 0x7fe4f370c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 It was noticed that the vertex has another list that is not being cleanedup. Let's allow this to happen. Signed-off-by: Donald Sharp <[email protected]> (cherry picked from commit 2d0f460)

The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <[email protected]>

The topotest bgp_srv6_sid_explicit generates the crash dump: ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0) The signal is caused by a READ memory access. #0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264 FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611 FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807 FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314 FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67 FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115 FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245 FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313 FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425 FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521 FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011 FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219 FRRouting#12 0x55a58a73079d in main zebra/main.c:550 FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360 FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4) Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs") Signed-off-by: Dmytro Shytyi <[email protected]> Signed-off-by: Philippe Guibert <[email protected]>

The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <[email protected]>

The topotest bgp_srv6_sid_explicit generates the crash dump: ERROR: SEGV on unknown address 0x5110002dba30 (pc 0x55a58a813379 bp 0x7ffd2cc8ec50 sp 0x7ffd2cc8ec00 T0) The signal is caused by a READ memory access. #0 0x55a58a813379 in alloc_srv6_sid_func_explicit zebra/zebra_srv6.c:1264 FRRouting#1 0x55a58a815138 in get_srv6_sid_explicit zebra/zebra_srv6.c:1611 FRRouting#2 0x55a58a8166bb in get_srv6_sid zebra/zebra_srv6.c:1807 FRRouting#3 0x55a58a8191ef in srv6_manager_get_sid_internal zebra/zebra_srv6.c:2314 FRRouting#4 0x55a58a80c0aa in hook_call_srv6_manager_get_sid zebra/zebra_srv6.c:67 FRRouting#5 0x55a58a80c671 in srv6_manager_get_sid_call zebra/zebra_srv6.c:115 FRRouting#6 0x55a58a78e956 in zread_srv6_manager_get_srv6_sid zebra/zapi_msg.c:3245 FRRouting#7 0x55a58a78f1d8 in zread_srv6_manager_request zebra/zapi_msg.c:3313 FRRouting#8 0x55a58a799321 in zserv_handle_commands zebra/zapi_msg.c:4425 FRRouting#9 0x55a58a92473c in zserv_process_messages zebra/zserv.c:521 FRRouting#10 0x781c0f978970 in event_call lib/event.c:2011 FRRouting#11 0x781c0f843d11 in frr_run lib/libfrr.c:1219 FRRouting#12 0x55a58a73079d in main zebra/main.c:550 FRRouting#13 0x781c0f22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 FRRouting#14 0x781c0f22a28a in __libc_start_main_impl ../csu/libc-start.c:360 FRRouting#15 0x55a58a6ec2b4 in _start (/usr/lib/frr/zebra+0x1d02b4) Fixes: 4e4588fa8f ("zebra: Add functions to alloc/release SRv6 SIDs") Signed-off-by: Dmytro Shytyi <[email protected]> Signed-off-by: Philippe Guibert <[email protected]>

The following crash happens on a BGP setup with SRv6 used, when locator is updated with the func-bits value moving from 32 bits to 16 bits. > FRRouting#6 0x000061582b486b5c in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) > at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 > FRRouting#7 vpn_leak_from_vrf_update (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > path_vrf=path_vrf@entry=0x6158364ef110) at bgpd/bgp_mplsvpn.c:2010 > FRRouting#8 0x000061582b48758b in vpn_leak_from_vrf_update_all (to_bgp=to_bgp@entry=0x6158364a0340, from_bgp=from_bgp@entry=0x6158364c1040, > afi=<optimized out>) at bgpd/bgp_mplsvpn.c:2215 > FRRouting#9 0x000061582b48774d in vpn_leak_postchange (afi=afi@entry=AFI_IP, bgp_vpn=bgp_vpn@entry=0x6158364a0340, > bgp_vrf=bgp_vrf@entry=0x6158364c1040, direction=BGP_VPN_POLICY_DIR_TOVPN) at ./bgpd/bgp_mplsvpn.h:313 > FRRouting#10 0x000061582b489b4b in vpn_leak_postchange (bgp_vrf=0x6158364c1040, bgp_vpn=0x6158364a0340, afi=AFI_IP, direction=BGP_VPN_POLICY_DIR_TOVPN) > at ./bgpd/bgp_mplsvpn.h:273 > FRRouting#11 vpn_leak_postchange_all () at bgpd/bgp_mplsvpn.c:3978 > FRRouting#12 0x000061582b5219d5 in bgp_zebra_process_srv6_locator_delete (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, > vrf_id=<optimized out>) at bgpd/bgp_zebra.c:3874 > FRRouting#13 0x0000766887b391ee in zclient_read (thread=<optimized out>) at lib/zclient.c:4804 > FRRouting#14 0x0000766887b2245e in event_call (thread=thread@entry=0x7ffc86531a30) at lib/event.c:2005 > FRRouting#15 0x0000766887ac2ed8 in frr_run (loop=0x615835c46fd0) at lib/libfrr.c:1252 > FRRouting#16 0x000061582b428163 in main (argc=<optimized out>, argv=0x7ffc86531cf8) at bgpd/bgp_main.c:565 > (gdb) > Actually, the SID allocated has been freed after the locator deleted event. Protect this part of code by checking the availability of the sid pointer. Signed-off-by: Philippe Guibert <[email protected]>

ldpd: json support for show commands

ba1c21c

Signed-off-by: Daniel Walton <[email protected]>

donaldsharp requested a review from rwestphal December 17, 2016 21:06

rwestphal requested changes Dec 19, 2016

View reviewed changes

dwalton76 closed this Jan 13, 2017

dwalton76 deleted the ldp-json branch February 1, 2017 13:58

dslicenc mentioned this pull request Feb 6, 2017

zebra and bgp crash at startup in master #170

Closed

anithanarasimhamurthy mentioned this pull request May 17, 2017

nhrpd crash on unconfig of nhrp event socket #570

Closed

This was referenced Sep 5, 2017

large-community regex crash #1103

Closed

ospfv3 is failing in topotests #1135

Closed

donaldsharp mentioned this pull request Oct 7, 2025

ospfd: On cleanup, actually free vertexes #19686

Merged

mergify bot mentioned this pull request Oct 7, 2025

ospfd: On cleanup, actually free vertexes (backport #19686) #19687

Closed

This was referenced Oct 7, 2025

ospfd: On cleanup, actually free vertexes (backport #19686) #19688

Closed

ospfd: On cleanup, actually free vertexes (backport #19686) #19689

Closed

soumyar-roy mentioned this pull request Oct 29, 2025

bgpd: Crash due to usage of freed up evpn_overlay attr #19879

Merged

ldpd: json support for show commands #13

ldpd: json support for show commands #13

Uh oh!

Conversation

dwalton76 commented Dec 17, 2016

Uh oh!

dwalton76 commented Dec 17, 2016

Uh oh!

dwalton76 commented Dec 17, 2016

Uh oh!

dwalton76 commented Dec 17, 2016

Uh oh!

dwalton76 commented Dec 17, 2016

Uh oh!

dwalton76 commented Dec 17, 2016

Uh oh!

rwestphal commented Dec 19, 2016

Uh oh!

dwalton76 commented Dec 19, 2016

Uh oh!

dwalton76 commented Dec 19, 2016

Uh oh!

rwestphal commented Dec 19, 2016

Uh oh!

dwalton76 commented Dec 19, 2016

Uh oh!

dwalton76 commented Dec 19, 2016

Uh oh!

dwalton76 commented Dec 19, 2016

Uh oh!

dwalton76 commented Dec 19, 2016

Uh oh!

dwalton76 commented Dec 19, 2016

Uh oh!

rwestphal commented Dec 19, 2016

Uh oh!

dwalton76 commented Dec 19, 2016

Uh oh!

rwestphal left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwestphal commented Dec 19, 2016

Uh oh!

donaldsharp commented Jan 3, 2017

Uh oh!

dwalton76 commented Jan 3, 2017

Uh oh!

rwestphal commented Jan 3, 2017

Uh oh!

dwalton76 commented Jan 4, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rwestphal left a comment •

edited

Loading