bgpd: Using no pretty json output for l2vpn-Evpn routes

The output of show bgp all json is inconsistent across Address-families
i.e. ipv4/ipv6 is a no pretty format while l2vpn-evpn is in a pretty
format. For huge scale (lots of routes with lots of paths), it is better
to use no_pretty format.

Before fix:
torm-11# sh bgp all json
{
"ipv4Unicast":{
 "vrfId": 0,
 "vrfName": "default",
 "tableVersion": 1,
 "routerId": "27.0.0.15",
 "defaultLocPrf": 100,
 "localAS": 65000,
 "routes": { } }
,
"l2VpnEvpn":{
"routes":{
  "27.0.0.15:2":{
    "rd":"27.0.0.15:2",
    "[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]":{
      "prefix":"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]",
      "prefixLen":352,
      "paths":[
<SNIP>.............

After fix:
torm-11# sh bgp all json
{
"ipv4Unicast":{
 "vrfId": 0,
 "vrfName": "default",
 "tableVersion": 1,
 "routerId": "27.0.0.15",
 "defaultLocPrf": 100,
 "localAS": 65000,
 "routes": { } }
,
"l2VpnEvpn":{
"routes":{"27.0.0.15:2":{"rd":"27.0.0.15:2","[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]":{"prefix":"[1]:[0]:[03:44:38:39:ff:ff:01:00:00:01]:[128]:[::]:[0]","prefixLen":352,"paths":[[{"valid":true,"bestpath":true,"selectionReason":"First path received","pathFrom":"external","routeType":1,"weight":32768,"peerId":"(unspec)","path":"","origin":"IGP","extendedCommunity"
<SNIP>.............

Issue: 3472865

Ticket:#3472865

Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>

diff --git a/bgpd/bgp_evpn_vty.c b/bgpd/bgp_evpn_vty.c
index 811856bfed6a08a9a5599588d75ffcbaed194bb5..66079cad2228135e98a18d7d7b071c90b3a8e296 100644 (file)
--- a/bgpd/bgp_evpn_vty.c
+++ b/bgpd/bgp_evpn_vty.c
@@ -3217,7 +3217,14 @@ int bgp_evpn_show_all_routes(struct vty *vty, struct bgp *bgp, int type,
        evpn_show_all_routes(vty, bgp, type, json, detail, false);
 
        if (use_json)
-               vty_json(vty, json);
+               /*
+                * We are using no_pretty here because under extremely high
+                * settings (lots of routes with many different paths) this can
+                * save several minutes of output when FRR is run on older cpu's
+                * or more underperforming routers out there. So for route
+                * scale, we need to use no_pretty json.
+                */
+               vty_json_no_pretty(vty, json);
        return CMD_SUCCESS;
 }