From 82465ca7f91c36ea06647f24e218231e6c8854de Mon Sep 17 00:00:00 2001 From: Rajasekar Raja Date: Mon, 22 May 2023 14:14:30 -0700 Subject: [PATCH] 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":[ ............. 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" ............. Issue: 3472865 Ticket:#3472865 Signed-off-by: Rajasekar Raja --- bgpd/bgp_evpn_vty.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/bgpd/bgp_evpn_vty.c b/bgpd/bgp_evpn_vty.c index 811856bfed..66079cad22 100644 --- 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; }