https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/BGPCEP-514 bgpcep <p>As far as I can tell ODL currently only announces IPv4 unicast routes using MP-NLRI.</p> <p>it receives NLRIs ok.</p> <p>Ideally we need a per-peer switch in ODL BGP so that for IPv4 unicast we can announce them as:<br/> 1) NLRI<br/> 2) MP-NLRI<br/> 3) both</p> <p>Operating System: All<br/> Platform: All</p> BGPCEP-514

need to be able to announce IPv4 unicast as NLRI as well as MP-NLRI

Bug Resolved Cannot Reproduce Milos Fabian Giles Heron Fri, 12 Aug 2016 15:11:50 +0000 Sun, 3 Mar 2019 11:49:50 +0000 Wed, 26 Oct 2016 08:38:36 +0000 Bugzilla Migration Bugzilla Migration BGP 0 2 <p>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</p> <p>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?</p> <p>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 <span class="error">&#91;10.18.162.90 is ODL and 10.18.162.241 is simulator&#93;</span></p> <p>Attachment mptest.pcap has been added with description: packet capture with different multi-protocol capability advertised for ipv4 and ipv6</p> <p>Giles,<br/> 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.<br/> Of course, such routes are stored in a common IPv4-Unicast route table.<br/> Also ODL peer can be configured to not advertise the capability - simply exclude IPv4-Unicast from table-type in the configuration.<br/> ODL can handle (parse) IPv4 prefixes in both NLRI/withdraw and MP_REACH/UNREACH path attributes, no matter what MP capability was advertised.<br/> Carrying the same prefix in both attributes <b>should not</b> happen - see the last paragraph in the section <a href="https://tools.ietf.org/html/rfc4760#section-3" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc4760#section-3</a></p> <p>Thanks Ajay for tryout.</p> <p>definitely didn't work for me - and I have the traces to prove it <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/wink.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>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.</p> <p>Hi, re-tested this functionality with latest Boron and it was working ok.<br/> Please, if you found the case when it is not working, provide some logs.</p> Development External issue ID 6401 External issue URL Issue Type Rank 0|i02crb: