CiscoTestAutomation / genieparser

sub-component of Genie that parse the device output into structured datastructure
Apache License 2.0
248 stars 384 forks source link

[IOS-XE] show ip bgp {address_family} all neighbors {neighbor} received-routes not retreiving prefix without CIDR #878

Open nouser5 opened 4 weeks ago

nouser5 commented 4 weeks ago

Some prefix in the output may not contain CIDR notation, these are not retrieved by the parser: 0.0.0.0 {neighbor} 0 {path} i 10.0.0.0 {neighbor} 0 {path} i 10.50.1.0/26 {neighbor} 0 {path} ? 10.50.2.0/26 {neighbor} 0 {path} ? 10.64.0.0/16 {neighbor} 0 {path} i

command = "show ip bgp vpnv4 all neighbors {neighbor} received-routes" received_routes = device.parse(command) prefixes=received_routes["vrf"]["default"]["neighbor"][neighbor]["address_family"]["vpnv4 RD {rd}"]["received_routes"]

if "0.0.0.0" in prefixes: ... print("parsed") ... if "0.0.0.0/0" in prefixes: ... print("parsed") ... if "10.64.0.0/16" in prefixes: ... print("parsed") ... parsed

SohanTirpude commented 3 weeks ago

Hello @nouser5,

Kindly provide the complete raw output for this command as well as kindly share the more light on CIDR notation. Also, it would be great if you can highlight the actual scenario and what should be the ideal scenario.

Thank you.

nouser5 commented 3 weeks ago

'show ip bgp vpnv4 all neighbors 10.82.15.252 received-routes' received_routes = device.parse(command)

2024-08-19 09:49:09,443: %UNICON-INFO: +++ temp_git with via 'cli': executing command 'show ip bgp vpnv4 all neighbors 10.82.15.252 received-routes' +++ show ip bgp vpnv4 all neighbors 10.82.15.252 received-routes BGP table version is 18, local router ID is {id} Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, L long-lived-stale, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found

 Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: {RD} (default for vrf WAN_VRF)

Total number of prefixes 3 temp_git#

2024-08-19 09:49:09,834: %UNICON-INFO: +++ temp_git with via 'cli': executing command 'show bgp all neighbors | i BGP neighbor' +++ show bgp all neighbors | i BGP neighbor BGP neighbor is 10.82.15.252, vrf WAN_VRF, remote AS 65400, local AS 64912 no-prepend replace-as, external link External BGP neighbor configured for connected checks (single-hop no-disable-connected-check) BGP neighbor is 10.82.24.9, vrf WAN_VRF, remote AS 65346, external link External BGP neighbor may be up to 1 hop away. External BGP neighbor configured for connected checks (single-hop no-disable-connected-check) BGP neighbor is 10.82.24.10, vrf WAN_VRF, remote AS 65346, external link External BGP neighbor may be up to 1 hop away. External BGP neighbor configured for connected checks (single-hop no-disable-connected-check) BGP neighbor is 10.82.24.254, vrf WAN_VRF, remote AS 64570, external link External BGP neighbor configured for connected checks (single-hop no-disable-connected-check) temp_git#

pprint.pprint(received_routes) {'vrf': {'default': {'neighbor': {'10.82.15.252': {'address_family': {'vpnv4': {'bgp_table_version': 18, 'local_router_id': '100.127.142.250', 'received_routes': {}}, 'vpnv4 RD 65357:201': {'bgp_table_version': 18, 'default_vrf': 'WAN_VRF', 'local_router_id': '100.127.142.250', 'received_routes': {'10.1.1.0/24': {'index': {1: {'metric': 0, 'next_hop': '10.82.15.252', 'origin_codes': '?', 'path': '65400 ' '65359', 'status_codes': '', 'weight': 0}}}, '10.1.2.0/24': {'index': {1: {'metric': 0, 'next_hop': '10.82.15.252', 'origin_codes': '?', 'path': '65400 ' '65359', 'status_codes': '', 'weight': 0}}}}, 'route_distinguisher': '65357:201'}}}}}}}

As you can see in the received_routes output, the 0.0.0.0 route isn't present. The ideal scenario would be to have this route in the output displayed as 0.0.0.0/0. This scenario occurs for other routes such as 10.0.0.0 which would need to be 10.0.0.0/8

CIDR notation represents an IP address and a suffix that indicates network identifier bits in a specified format. For example, you could express 192.168. 1.0 with a 22-bit network identifier as 192.168. 1.0/22.

ParimiNeeraja commented 3 weeks ago

Hello,

I understand that first scenario to display 0.0.0.0/0 for 0.0.0.0 route. Can you please explain more on another scenario for other routes such as 10.0.0.0 which would need to be 10.0.0.0/8 that, how can parser recognize suffix with an IP address.

nouser5 commented 3 weeks ago

This is based on IP Classes: https://www.tecmint.com/network-ip-addressing-range/

10.0.0.0 falls within Class A (1-126) and thus needs a mask of 10.0.0.0/8 128-191 falls within Class B which would have a /16 mask (172.50.0.0 --> 172.50.0.0/16) and so on..

I get that adding information that wasn't really parsed isn't great. At least parsing the routes without CIDR and putting them in the output would allow for correcting this outside of the parser

ParimiNeeraja commented 2 weeks ago

Hello @nouser5 ,

I have checked with team as now we are not handling with CIDR. I have added support for 0.0.0.0, please check and confirm

expected_output = {
    "vrf": {
        "default": {
            "neighbor": {
                "10.82.15.252": {
                    "address_family": {
                        "vpnv4": {
                            "received_routes": {},
                            "bgp_table_version": 18,
                            "local_router_id": "100.127.142.250"
                        },
                        "vpnv4 RD 65357:201": {
                            "bgp_table_version": 18,
                            "local_router_id": "100.127.142.250",
                            "route_distinguisher": "65357:201",
                            "default_vrf": "WAN_VRF",
                            "received_routes": {
                                "0.0.0.0": {
                                    "index": {
                                        1: {
                                            "status_codes": "",
                                            "next_hop": "10.82.15.252",
                                            "origin_codes": "i",
                                            "weight": 0,
                                            "path": "0 65500 65340"
                                        }
                                    }
                                },
                                "10.1.1.0/24": {
                                    "index": {
                                        1: {
                                            "status_codes": "",
                                            "next_hop": "10.82.15.252",
                                            "origin_codes": "?",
                                            "weight": 0,
                                            "path": "0 65500 65340"
                                        }
                                    }
                                },
                                "10.1.2.0/24": {
                                    "index": {
                                        1: {
                                            "status_codes": "",
                                            "next_hop": "10.82.15.252",
                                            "origin_codes": "?",
                                            "weight": 0,
                                            "path": "0 65500 65340"
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}
ParimiNeeraja commented 1 week ago

Above changes are merged and changes will reflect you from next pyats version. Thank you.