ip_route_details*and *ip_address_details both have a new prefix field of type vl_api_prefix_t which is supposed to contain an interface’s IP address in the CIDR notation. But the following code in vpp_format.py ensures that the IP address is converted to the underlying network address:

 

 

def unformat_api_prefix_t(o):

    if isinstance(o.address, ipaddress.IPv4Address):

        return ipaddress.IPv4Network((o.address, o.len), False)

    if isinstance(o.address, ipaddress.IPv6Address):

        return ipaddress.IPv6Network((o.address, o.len), False)

 

For example, the IPv4 address, 10.195.131.80/27, will get converted into the underlying network address, 10.195.131.64/27, by the above code:

 

>>> ipaddress.IPv4Network(u'10.195.131.80/27', False)

IPv4Network(u'10.195.131.64/27')

>>>

 

This is the correct behaviour as far as the ipaddress.[IPv4/IPv6]Network class is concerned but that was not what is intended by the vl_api_prefix_t type IMO.

 

 

I ran the following test on VPP 19.08 which confirms it:

 

vpp# create loopback interface

loop0

vpp# set interface ip address loop0 10.0.0.1/8

vpp# set interface ip address loop0 192.168.10.1/24

vpp# sh int addr

TwentyGigabitEthernet7/0/0 (up):

local0 (dn):

loop0 (dn):

  L3 10.0.0.1/8

  L3 192.168.10.1/24

vpp#

 

Creating a PAPI session and invoking ip_address_details on loop0 gives:

 

root@cmp003:~# python simple_papi_client.py

19.08-rc2~12-g1c586de~b38

[ip_address_details(_0=225, context=2, sw_if_index=2, prefix=IPv4Network(u'10.0.0.0/8')), ip_address_details(_0=225, context=2, sw_if_index=2, prefix=IPv4Network(u'192.168.10.0/24'))]

 

Of course, it works as expected on 19.04.