On 2018-01-31, Andrew Thrift <andrew@networklabs.co.nz> wrote:
> Hi,
>
> I am testing OpenBGPD as a route-reflector, with a view to replacing
> our existing route reflectors. I have a test environment where I have
> multiple vendors equipment peered with OpenBGPD to ensure it can
> handle our use-cases.
>
> I noticed that our Cisco IOS-XE devices have unstable BGP sessions and
> are dropping with the OpenBGPD log message:
>
> "sending notification: error in UPDATE message, optional attribute error"
>
> Upon further inspection, when the Cisco router issues an NLRI update
> and withdraw's a VPNv4 prefix OpenBGPD drops the session.
>
> I found a report of a similar issue, but with a Juniper MX router from
> Hendrik Meyburgh back in 2012, where the problem was with the
> vrf-table-label command on JunOS. I checked our configuration and
> IOS-XE is configured with:
> "mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf" which assigns a
> single label per VRF table, rather than a label per prefix. I
> suspect that this is causing the NLRI updates to be formatted in a way
> that OpenBGPD does not like.
>
> I took a packet capture of the UPDATE causing the session to be
> terminated, there are two instances of it being dropped in the pcap
> available at https://mergesync.btg.co.nz/index.php/s/rvc8mc9RCpTR1Lg
>
> Is there anything we can do to stop OpenBGPD from dropping the
> session? Running per-VRF label's is default on all Juniper
> platforms, and is common on Cisco as well.
>
>
> Regards,
>
>
>
> Andrew
>
>
It's hitting this case:
1265 case AID_VPN_IPv4:
1266 while (mplen > 0) {
1267 if ((pos = rde_update_get_vpn4(mpp, mplen,
1268 &prefix, &prefixlen)) == -1) {
1269 log_peer_warnx(&peer->conf,
1270 "bad VPNv4 nlri prefix");
1271 rde_update_err(peer, ERR_UPDATE,
1272 ERR_UPD_OPTATTR,
1273 mpa.reach, mpa.reach_len);
1274 goto done;
1275 }
>1276 if (prefixlen > 32) {
>1277 rde_update_err(peer, ERR_UPDATE,
>1278 ERR_UPD_OPTATTR,
>1279 mpa.reach, mpa.reach_len);
1280 goto done;
1281 }
Question is why the prefixlen is set this way...
Border Gateway Protocol - UPDATE Message
Marker: ffffffffffffffffffffffffffffffff
Length: 45
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 22
Path attributes
Path Attribute - MP_UNREACH_NLRI
Flags: 0x80, Optional, Non-transitive, Complete
1... .... = Optional: Set
.0.. .... = Transitive: Not set
..0. .... = Partial: Not set
...0 .... = Extended-Length: Not set
.... 0000 = Unused: 0x0
Type Code: MP_UNREACH_NLRI (15)
Length: 19
Address family identifier (AFI): IPv4 (1)
Subsequent address family identifier (SAFI): Labeled VPN Unicast (128)
Withdrawn routes (16 bytes)
BGP Prefix
> Prefix Length: 120
Label Stack: 0 (withdrawn)
Route Distinguisher: 56028:130
MP Unreach NLRI IPv4 prefix: 100.64.0.42
Relevant bit of the pcap sliced off:
begin 644 bgp.pcap.1
MU,.RH0(`!````````````/__```!````-8%Q6N8G#0!W````=P```/)/1[ZT
MK=3*;0$[@`@`1<``:2=W0`#^!G>O9Q,'"&<3!WI810"SC067R&3)9!.@&#]5
MCE```!,2WBX<N/;R/E88$SH2'LO([0``_____________________P`M`@``
M`!:`#Q,``8!X@`````#:W````()D0``J-8%Q6HXJ#0!R````<@```-3*;0$[
M@/)/1[ZTK0@`1<``9"'@0`#_!GQ+9Q,'>F<3!P@`LUA%9,ED$XT%E_6@&/__
MW/X``!,2(?H9D@C-C=]Z+]8NI6/`\@$!_____________________P`H`P,)
M``&`>(``````VMP```""9$``*C6!<5JD*@T`2@```$H```#4RFT!.X#R3T>^
MM*T(`$7``#P1U$``_P:,?V<3!WIG$P<(`+-8163)9#N-!9?UH!'__]S6```3
M$JVF/+LY'?;_<@2PYQ#E]A@!`36!<5IF/PT`2@```$H```#R3T>^M*W4RFT!
M.X`(`$7``#PG>$``_@9WVV<3!PAG$P=Z6$4`LXT%E_5DR60\H!`_+?7K```3
M$J4$!S.*<4<CK17,O)3D9W```#6!<5I6:@T`2@```$H```#R3T>^M*W4RFT!
M.X`(`$7``#PG>4``_@9WVF<3!PAG$P=Z6$4`LXT%E_5DR60\H!D_+7_&```3
M$C'7AD>K6M-#U9:=T`K,M1\``#6!<5J2:@T`2@```$H```#4RFT!.X#R3T>^
MM*T(`$7``#PDYT``_P9Y;&<3!WIG$P<(`+-8163)9#R-!9?VH!#__]S6```3
3$J;7?D4KK0W@@DH8V=$-SL8!`0``
`
end
No comments:
Post a Comment