[BGPCEP-865] BGP advertizes Route Target Entries even when it has not advertized it Created: 11/Mar/19 Updated: 19/Mar/19 Resolved: 12/Mar/19 |
|
| Status: | Resolved |
| Project: | bgpcep |
| Component/s: | BGP |
| Affects Version/s: | None |
| Fix Version/s: | Neon, Sodium |
| Type: | Bug | Priority: | Highest |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Description |
|
In CSIT (https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/bgpcep-csit-1node-userfeatures-all-neon/208/exa6.log.gz ) we have the following error: 09:24:56 | 17061 | peer-1 | << UPDATE #9 09:24:56 | 17061 | peer-1 | UPDATE #9 nlri ( 11) eor 2/1 (ipv6 unicast) 09:24:56 | 17061 | outgoing-7 | received TCP payload ( 19) FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 001D 02 09:24:56 | 17061 | outgoing-7 | received TCP payload ( 10) 0000 0006 800F 0300 0184 09:24:56 | 17061 | outgoing-7 | << message of type UPDATE 09:24:56 | 17061 | parser | parsing UPDATE ( 10) 0000 0006 800F 0300 0184 09:24:56 | 17061 | parser | withdrawn NLRI none 09:24:56 | 17061 | parser | attribute mp-unreach-nlri flag 0x80 type 0x0f len 0x03 payload 0001 84 09:24:56 | 17061 | outgoing-7 | sending TCP payload ( 63) FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 003F 0303 0070 7265 7365 6E74 6564 2061 206E 6F6E 2D6E 6567 6F74 6961 7465 6420 6661 6D69 6C79 2069 7076 3420 7274 63 09:24:56 | 17061 | outgoing-7 | >> NOTIFICATION (3,0,"presented a non-negotiated family ipv4 rtc") 09:24:56 | 17061 | outgoing-7 | peer reset, message [notification sent (3,0)] error[UPDATE message error / Unspecific / presented a non-negotiated family ipv4 rtc] 09:24:56 | 17061 | outgoing-7 | outgoing-7 127.0.0.6-10.30.171.1, closing connection which means we are forwarding route target even when we have not sent the capability. |
| Comments |
| Comment by Robert Varga [ 11/Mar/19 ] |
|
It seems this is coming from EffectiveRibInWriter.onDataTreeChanged() via RibOutRefresh.refreshTable() to RIBImpl, where it gets routed to the LocRibWriter. In LocRibWriter, though, the peerId parameter gets interpreted as 'toPeer' and we only check if the peer has advertized support for RTC, not if we advertized support – and therefore we emit RTC even though we did not advertise the capability, which we are caught doing by ExaBGP. |