Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zebra: Cl to frr upstream zebra json #17532

Open
wants to merge 106 commits into
base: master
Choose a base branch
from

Conversation

sougata-github-nvidia
Copy link

Added Zebra json

Sindhu Parvathi Gopinathan and others added 2 commits November 28, 2024 21:48
FRR "show evpn es 'esi-id' json" output dont have the 'df' flag.

Modified the code to add the 'df' flag into json output.

Before Fix:

```
torm-11# show evpn es 03:44:38:39:ff:ff:01:00:00:01 json
{
  "esi":"03:44:38:39:ff:ff:01:00:00:01",
  "accessPort":"hostbond1",
  "flags":[
    "local",
    "remote",
    "readyForBgp",
    "bridgePort",
    "operUp",
    "nexthopGroupActive"
	 ====================> df is missing
  ],
  "vniCount":10,
  "macCount":13,
  "dfPreference":50000,
  "nexthopGroup":536870913,
  "vteps":[
    {
      "vtep":"27.0.0.16",
      "dfAlgorithm":"preference",
      "dfPreference":32767,
      "nexthopId":268435460
    },
    {
      "vtep":"27.0.0.17",
      "dfAlgorithm":"preference",
      "dfPreference":32767,
      "nexthopId":268435461
    }
  ]
}
torm-11#
```

After Fix:-

```
torm-11# show evpn es 03:44:38:39:ff:ff:01:00:00:01 json
{
  "esi":"03:44:38:39:ff:ff:01:00:00:01",
  "accessPort":"hostbond1",
  "flags":[
    "local",
    "remote",
    "readyForBgp",
    "bridgePort",
    "operUp",
    "nexthopGroupActive",
    "df" ========================> designated-forward flag added
  ],
  "vniCount":10,
  "macCount":13,
  "dfPreference":50000,
  "nexthopGroup":536870913,
  "vteps":[
    {
      "vtep":"27.0.0.16",
      "dfAlgorithm":"preference",
      "dfPreference":32767,
      "nexthopId":268435460
    },
    {
      "vtep":"27.0.0.17",
      "dfAlgorithm":"preference",
      "dfPreference":32767,
      "nexthopId":268435461
    }
  ]
}
torm-11#

```

Ticket:# 3447935

Issue: 3447935

Testing: UT done

Signed-off-by: Sindhu Parvathi Gopinathan's <[email protected]>
Signed-off-by: Chirag Shah <[email protected]>
Add VNI's associated bridge and vlan info in json
output format.

torm-11# show evpn vni detail
VNI: 1008
 Type: L2
 Vlan: 1008
 Bridge: bridge
 ...

Ticket:#3208813
Reviewed By:
Testing Done:

torm-11# show evpn vni detail json
[
  {
    "vni":1008,
    "type":"L2",
    "vlan":1008,     <<< New field
    "bridge":"bridge", <<< New field
    "vrf":"vrf3",
    "vxlanInterface":"vxlan0",
    "ifindex":15,
    "vtepIp":"27.0.0.15",
    "mcastGroup":"239.1.1.108",
    "advertiseGatewayMacip":"No",
    "advertiseSviMacip":"No",
    "numMacs":18,
    "numArpNd":42,
    "numRemoteVteps":[
      "27.0.0.18",
      "27.0.0.17",
      "27.0.0.16"
    ]
  },
]

Signed-off-by: Chirag Shah <[email protected]>
@sougata-github-nvidia
Copy link
Author

CI:rerun

Reorganize common vlxan dump api to handle
both screen rending and json data object.

Testing Done:

    "interfaceType":"Vxlan",
    "vtepIp":"27.0.0.16",
    "vxlanId":{
      "1006":{
        "accessVlan":1006,
        "mcastGroup":"239.1.1.106"
      }
    },
    "linkInterface":"ipmr-lo",
    "masterInterface":"bridge",

SVD interface output:

    "interfaceType":"Vxlan",
    "vtepIp":"27.0.0.16",
    "vxlanId":{
      "1005":{
        "accessVlan":1005,
        "mcastGroup":"0.0.0.0"
      },
      "1001":{
        "accessVlan":1001,
        "mcastGroup":"0.0.0.0"
      },
      "4001":{
        "accessVlan":4001,
        "mcastGroup":"0.0.0.0"
      },
      "1003":{
        "accessVlan":1003,
        "mcastGroup":"0.0.0.0"
      },
      "1007":{
        "accessVlan":1007,
        "mcastGroup":"0.0.0.0"
      }
    },
    "masterInterface":"bridge",

Signed-off-by: Chirag Shah <[email protected]>
@sougata-github-nvidia
Copy link
Author

CI:rerun

Sindhu Parvathi Gopinathan and others added 4 commits December 3, 2024 15:24
Handles json brief/tiny output for scaled nexthop-group rib entries.

Commands supported:

```
show nexthop-group rib brief json
show nexthop-group rib 117 brief json
show nexthop-group rib singleton ip brief json
show nexthop-group rib singleton ipv6 brief json
show nexthop-group rib zebra brief json
```

Ticket: #3710394

Issue: 3710394

Signed-off-by: Sindhu Parvathi Gopinathan's <[email protected]>
Define a MAC cache to store local MACs upon notification from
the kernel.

Signed-off-by: Vivek Venkatraman <[email protected]>
Add vtysh handler and backend function to display the local
MAC cache.

Signed-off-by: Vivek Venkatraman <[email protected]>
Added json support for 'show evpn local-mac intf vlan.'

Signed-off-by: Ashwini Reddy <[email protected]>
@sougata-github-nvidia
Copy link
Author

CI:rerun

Copy link
Contributor

@mjstapp mjstapp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had some questions.
I really think the new feature proposal should be moved to a separate PR.

}

static void zebra_vxlan_if_vni_hash_dump_vty(struct hash_bucket *bucket,
void *ctxt)
void **args)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, don't change the signature of this callback - you can do the interpretation of the void* inside the function. if you need to pass more context, then you may need to ... pass a context struct, as is done in many places

if (vxlan_info->vtep_ip.s_addr != INADDR_ANY)
vty_out(vty, " VTEP IP: %pI4", &vxlan_info->vtep_ip);
if (vxlan_info->vtep_ip.s_addr != INADDR_ANY &&
inet_ntop(AF_INET, &vxlan_info->vtep_ip, buf, sizeof(buf)) != NULL)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, the existing code is correct

hash_iterate(vni_info->vni_table,
zebra_vxlan_if_vni_hash_dump_vty, vty);
(void (*)(struct hash_bucket *,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, don't need to do this

if (vni->access_vlan)
vty_out(vty, " Access VLAN Id %u\n", vni->access_vlan);
if (vty) {
vty_out(vty, "\n VxLAN Id %u", vni->vni);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are you changing the newlines?

if (vni->mcast_grp.s_addr != INADDR_ANY)
vty_out(vty, " Mcast Group %s",
inet_ntop(AF_INET, &vni->mcast_grp, str, sizeof(str)));
if (vni->mcast_grp.s_addr != INADDR_ANY &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you're going to change this, please use %pI4

newline change - again?

@@ -3101,6 +3101,9 @@ static void zebra_evpn_es_show_entry(struct vty *vty, struct zebra_evpn_es *es,
json_array_string_add(json_flags, "local");
if (es->flags & ZEBRA_EVPNES_REMOTE)
json_array_string_add(json_flags, "remote");
if (es->flags & ZEBRA_EVPNES_LOCAL &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit concerned about this: the two flags involved are already represented - do we need to capture this semantic in this way, explicitly? can't the operator decide what the presence or absence of the two flags means?

@@ -38,6 +38,13 @@ struct zebra_l2_bridge_vlan {
struct zebra_evpn_access_bd *access_bd;
};

struct zebra_l2_brvlan_mac {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

umm - this commit adds data structures, but ... where's the code that updates them?
frankly, I think you should separate new feature proposals like this out into a separate PR, and offer just the json-specific changes in this PR

NULL);
if (brief) {
if (zebra_nhg_dependents_is_empty(nhe))
show_nexthop_json_helper(json_nexthops,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the indentation looks wrong in this block - is that just the github webui?

"EVPN\n"
"Local MAC addresses\n"
"Interface Name\n"
"VLAN ID\n" JSON_STR)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

separate line for each help string

return CMD_WARNING;
}

RB_FOREACH (vrf, vrf_name_head, &vrfs_by_name) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I swear - no more of this in-the-clear: let's make a lib api that does this, instead of doing it raw like this all over zebra

@sougata-github-nvidia
Copy link
Author

CI:rerun

@sougata-github-nvidia
Copy link
Author

CI:rerun

1 similar comment
@sougata-github-nvidia
Copy link
Author

CI:rerun

@sougata-github-nvidia
Copy link
Author

CI:rerun

@github-actions github-actions bot added the rebase PR needs rebase label Dec 10, 2024
@mjstapp
Copy link
Contributor

mjstapp commented Dec 10, 2024

please don't add "fix it" commits - please fix the commit that has a problem and rebase your branch

The bgp_bmp and bgp_bmp_vrf tests use similar routines
to test the bmp, but are duplicates. Gather the bgp_bmp
and the bgp_bmp_vrf tests in a single bgp_bmp folder.

- Create a bgpbmp.py library under the bgp_bmp test folder
- The bgp_bmp and bgp_bmp_vrf test are renamed to bgp_bmp_1
and bgp_bmp_2 test.
- Maintain separate folder for config and output results. Adapt
the bgp_bmp library accordingly.
- The json output for bgp_bmp_2 test has no referenc to hostame.

Signed-off-by: Philippe Guibert <[email protected]>
When configuring the bgp_bmp test with an additional
peer that sends empty AS-PATH, the bmp collector is stopping:

> [2024-10-28 17:41:51] Finished dissecting data from ('192.0.2.1', 33922)
> [2024-10-28 17:41:52] Data received from ('192.0.2.1', 33922): length 195
> [2024-10-28 17:41:52] Got message type: <class 'bmp.BMPRouteMonitoring'>
> [2024-10-28 17:41:52] unpack_from requires a buffer of at least 2 bytes for unpacking 2 bytes at offset 0 (actual buffer size is 0)
> [2024-10-28 17:41:52] TCP session closed with ('192.0.2.1', 33922)
> [2024-10-28 17:41:52] Server shutting down on 192.0.2.10:1789

The parser attempts to read an empty AS-path and considers the length
value as a length in bytes, whereas RFC mentions this value as
definining the number of AS-PAths. Fix this in the parser.

Signed-off-by: Philippe Guibert <[email protected]>
ton31337 and others added 14 commits December 16, 2024 09:38
This cannot happen.  No need to test

Signed-off-by: Donald Sharp <[email protected]>
PIMv6 does not implement MSDP, users should use PIMv6 embedded RP
instead.

Signed-off-by: Rafael Zalamena <[email protected]>
Reorganize the MSDP initialization code and configuration writing code
to its appropriated place.

Signed-off-by: Rafael Zalamena <[email protected]>
Guard MSDP code to compile only on IPv4 and remove all MSDP code from
PIMv6.

Signed-off-by: Rafael Zalamena <[email protected]>
Allow user to specify the RP field for the SA messages.

Signed-off-by: Rafael Zalamena <[email protected]>
Import new topology to test originator ID configuration.

Signed-off-by: Rafael Zalamena <[email protected]>
Let user know about new MSDP knob to configure originator ID.

Signed-off-by: Rafael Zalamena <[email protected]>
If we have this construct:

for (pi = bgp_dest_get_bgp_path_info(dest); pi; pi = pi->next) {
     ...
     bgp_process();
}

This can induce an infinite loop.  This happens because bgp_process
will move the unsorted items to the top of the list for handling,
as such it is necessary to hold the next pointer to the side
to actually look at each possible bgp_path_info.

Signed-off-by: Donald Sharp <[email protected]>
Fix crash on `clear ipv6 mroute` when using embedded RP.

Signed-off-by: Rafael Zalamena <[email protected]>
Fix Coverity Scan CID 1602463: make it impossible for the function to fail.

Hardcode the multicast prefix generation instead of calling `str2prefix()`
which caused unnecessary memory allocations and returned error values.

Signed-off-by: Rafael Zalamena <[email protected]>
When debugging a crash I noticed that sometimes we talked about
a zclient connection in relation to the fd associated with it
and sometimes we did not.  Let's just always give the data
associated with the fd.  It will make it a bit easier for me
to follow the transitions.

Signed-off-by: Donald Sharp <[email protected]>
Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.