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

TableLookupPrefix Inconsistencies Between VRF and Global RIBs #2870

Open
crankynetman opened this issue Jan 16, 2025 · 2 comments
Open

TableLookupPrefix Inconsistencies Between VRF and Global RIBs #2870

crankynetman opened this issue Jan 16, 2025 · 2 comments

Comments

@crankynetman
Copy link

Hello!

When using the ListPathRequest RPC on a VRF, the TableLookupPrefix seems to be ignored and all prefixes are returned for the provided address family. Using this example in python, you can see the difference between the Global RIB and a VRF RIB when sending the same query and both tables have the same contents for example, given these two tables, global and the VRF named "ipt" respectively:

$ docker compose exec gobgp gobgp global rib -a ipv4
   Network              Next Hop             AS_PATH              Age        Attrs
*> 192.2.0.0/32         0.0.0.0                                   00:49:09   [{Origin: ?}]
*> 192.2.0.1/32         0.0.0.0                                   00:49:14   [{Origin: ?}]
$ docker compose exec gobgp gobgp vrf ipt rib -a ipv4
   Network              Next Hop             AS_PATH              Age        Attrs
*  192.2.0.0/32         0.0.0.0                                   01:14:48   [{Origin: ?}]
*  192.2.0.1/32         0.0.0.0                                   01:14:46   [{Origin: ?}]

Since these tables have essentially the same contents, if I issue a ListPathRequest RPC and filter the TableLookupPrefix to 192.2.0.0/32 I would expect to get back exactly one match per table. Given this example code, I get 2 responses (the entire table) when querying the VRF, but only the one (correct) response when querying the Global RIB:

Example Code:

import gobgp_pb2
import gobgp_pb2_grpc
import grpc
import ipaddress

ip = ipaddress.ip_interface("192.2.0.0/32")


_TIMEOUT_SECONDS = 1000
stub = gobgp_pb2_grpc.GobgpApiStub(grpc.insecure_channel("gobgp:50051"))

prefixes = [gobgp_pb2.TableLookupPrefix(prefix=str(ip))]
family_afi = gobgp_pb2.Family.AFI_IP

result = stub.ListPath(
    gobgp_pb2.ListPathRequest(
        table_type=gobgp_pb2.VRF,
        name="ipt",
        prefixes=prefixes,
        family=gobgp_pb2.Family(afi=family_afi, safi=gobgp_pb2.Family.SAFI_UNICAST),
    ),
    _TIMEOUT_SECONDS,
)

print(len(list(result)))

prefixes = [gobgp_pb2.TableLookupPrefix(prefix=str(ip))]
family_afi = gobgp_pb2.Family.AFI_IP

result2 = stub.ListPath(
    gobgp_pb2.ListPathRequest(
        table_type=gobgp_pb2.GLOBAL,
        prefixes=prefixes,
        family=gobgp_pb2.Family(afi=gobgp_pb2.Family.AFI_IP, safi=gobgp_pb2.Family.SAFI_UNICAST),
    ),
    _TIMEOUT_SECONDS,
)

print(len(list(result2)))

Response:

2
1

This is using GoBGP 3.33.0:

$ docker compose exec gobgp gobgp --version
gobgp version 3.33.0

Am I doing something wrong here? I've tried adding in RDs to the TableLookupPrefix as well, but to no avail. Any help is greatly appreciated, thank you very much in advance!

@crankynetman
Copy link
Author

I've done a bit more testing on this, including trying out the newer API protobufs that @Tuetuopay has been working on to try and see if I've just been holding TableLookupPrefix wrong. Unfortunately, I still get the same issue.. I have an updated test script that I shoved into our repo that uses GoBGP:

https://github.com/esnet-security/SCRAM/blob/topic/chriscummings/test-gobgp-oneof-stuff/translator/test_file_thingy.py

Unfortunately, using the cleaner API defs didn't give any more credence to me holding TableLookupPrefix wrong, so I think that this is likely a bug (hopefully I'm wrong and I'm just not holding things right!)

@fujita
Copy link
Member

fujita commented Jan 27, 2025

I think that LookupPrefix isn't supported on a VRF.

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

No branches or pull requests

2 participants