[BGPCEP-514] need to be able to announce IPv4 unicast as NLRI as well as MP-NLRI Created: 12/Aug/16  Updated: 03/Mar/19  Resolved: 26/Oct/16

Status: Resolved
Project: bgpcep
Component/s: BGP
Affects Version/s: Bugzilla Migration
Fix Version/s: Bugzilla Migration

Type: Bug
Reporter: Giles Heron Assignee: Milos Fabian
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Attachments: File mptest.pcap    
External issue ID: 6401

 Description   

As far as I can tell ODL currently only announces IPv4 unicast routes using MP-NLRI.

it receives NLRIs ok.

Ideally we need a per-peer switch in ODL BGP so that for IPv4 unicast we can announce them as:
1) NLRI
2) MP-NLRI
3) both

 Comments   
Comment by Ajay L [ 17/Aug/16 ]

I just tried and verified that if peer does not announce multi-protocol capability for ipv4/unicast address family, ODL does use NLRI to announce routes. Is a config knob orthogonal to the capability exchange being requested? and if so, curious to know the use-case

Comment by Giles Heron [ 17/Aug/16 ]

ok - that's odd. How did you verify it? Did you try getting a peer to announce IPv4/unicast using NLRI and announce another AFI/SAFI using MP-NLRIs?

Comment by Ajay L [ 17/Aug/16 ]

I have a simulator announcing multi-protocol support for ipv6/unicast but not for ipv4 unicast. Then I injected a ipv4 and ipv6 route through application-peer and can see ODL advertising ipv4 route using NLRI and ipv6 route using MP-NLRI. Please find the packet capture attached for reference [10.18.162.90 is ODL and 10.18.162.241 is simulator]

Comment by Ajay L [ 17/Aug/16 ]

Attachment mptest.pcap has been added with description: packet capture with different multi-protocol capability advertised for ipv4 and ipv6

Comment by Milos Fabian [ 23/Aug/16 ]

Giles,
If remote peer does not advertise IPv4-Unicast MP capability, ODL is packaging routes to classic BGP-4 NLRI attribute, otherwise in MP_REACH attribute.
Of course, such routes are stored in a common IPv4-Unicast route table.
Also ODL peer can be configured to not advertise the capability - simply exclude IPv4-Unicast from table-type in the configuration.
ODL can handle (parse) IPv4 prefixes in both NLRI/withdraw and MP_REACH/UNREACH path attributes, no matter what MP capability was advertised.
Carrying the same prefix in both attributes should not happen - see the last paragraph in the section https://tools.ietf.org/html/rfc4760#section-3

Thanks Ajay for tryout.

Comment by Giles Heron [ 25/Aug/16 ]

definitely didn't work for me - and I have the traces to prove it

I think the issue might be that I was doing v4-unicast and v4-flowspec. I keep meaning to test again to verify this (using v4-unicast and v6-unicast on my XE box and then v4-unicast and v4-flowspec) but have run out of time.

Comment by Milos Fabian [ 07/Sep/16 ]

Hi, re-tested this functionality with latest Boron and it was working ok.
Please, if you found the case when it is not working, provide some logs.

Generated at Wed Feb 07 19:13:18 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.