Hi Aaron,
Well the BGP enhanced attribute error handling should actually prevent
unnecessary BGP session reset.
It's actually the RRs that are messing things up I think, junipers have nothing
to do with it I guess, remember when RR receives an update it doesn't rely it
unchanged it does a lot of things completely repackaging the update so it's RRs
that should populate originator id correctly as well should put the NLRI at the
beginning of the update msg so that ME3600's have better chance to parse it
successfully.
-I'm wondering if enhanced error is enabled on RRs as well.
-looks like the cmd "update in error-handling basic { ebgp | ibgp } disable"
and " update in error-handling extended" where introduced in 4.2.0 (December
23, 2011) which is around the time when draft-ietf-idr-error-handling-01 was
discussed (btw standardised only in Aug 2015, crazy road it was) oh and the
ops-reqs-for-bgp-error-handling-07 branch is still ongoing...
So yeah there are two possibilities either RRs do understand the message and
relying it further in a good believe that everyone will understand it, but
ME3600's can't parse it correctly because they are trying to do some enhanced
error correction/parsing magic wchich doesn't work leaving only session reset
as a viable solution -this is suggested by the fact that MEs running older code
don't have problem parsing/ignoring the update.
-to test this you can disable the "enhanced-error" on one of the MEs and on RRs
enable separate test group/neighbour with l2vpn enabled only to this one ME (on
ME also define a separate session with l2vpn AF) -to see if the session stays
up or flaps.
Or the other option is that RRs do not quite understand the update and are
messing it up causing MEs to fail to parse it correctly
-you can try setting up direct iBGP session between one ME3600 and one ASR with
this L2VPN/VPLS AF/SAF enabled to get RRs(XR) out of the picture -to see if the
session forms or will keep on flapping.
-fact suggesting that RRs are doing something fishy is the missing
originator-id -but it might be totally unrelated (some other bug).
adam
> -----Original Message-----
> From: Aaron [mailto:[email protected]]
> Sent: Tuesday, November 24, 2015 4:59 PM
> To: Adam Vitkovsky; [email protected];
> [email protected]; [email protected]
> Subject: RE: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS
> interoperability
>
> Thanks Adam,
>
> RR's are both running IOS XR 4.1.2
>
> I see something...
>
> Conf t
> Router bgp 64512
> No bgp enhanced-error
>
> ... to potentially turn off enhanced error handling. I just don't know if
> this is
> what I should do at this point. I mean I don't know if I should cause
> malformed messages to be treated as withdrawals. ??
>
> also, btw, why is this message being seen as malformed in the first place ??
> I
> mean is it the juniper 5048 and 104 that are sending what the cisco me3600
> believes are malformed messages ?
>
> Yeah Adam, it appears that enabled bgp enhanced-error is a default setting.
> http://www.cisco.com/c/en/us/td/docs/ios-
> xml/ios/iproute_bgp/command/irg-cr-book/bgp-a1.html#wp1306388590
>
> Aaron
>
>
> -----Original Message-----
> From: Adam Vitkovsky [mailto:[email protected]]
> Sent: Tuesday, November 24, 2015 4:43 AM
> To: Aaron; [email protected]; [email protected];
> [email protected]
> Subject: RE: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS
> interoperability
>
> Hi Aaron,
>
> > From: Aaron [mailto:[email protected]]
> > Sent: Tuesday, November 24, 2015 4:04 AM
> >
> > Also, I'm pretty sure the way I have my ME3600's configured is,
> > RFC4762 (bgp ad w/ldp sig) and my Juniper's are configured as RFC4761
> (bgp ad w/bgp sig).
> >
> > I pretty much understood this as I was config'ing it the other day,
> > but I didn't think it would matter since all I wanted to do was get
> > the juniper's signaling lsp's with each other... I wonder if that
> > caused problems with the other PE's in my network.
> >
> It could but it really shouldn't, I guess the BGP signalling was added in
> 15.3+
>
> > ME3600 - IOS
> > 15.2(4)S1 - NOT affected
>
> Looks like since 15.2(4)S3 BGP Enhanced Attribute Error Handling feature can
> be enabled (though I'm not sure if it's enabled by default) So I'm wondering
> if it has something to do with this.
> > 15.2(4)S3 - affected
> > 15.2(4)S5 - affected
> >
> > Nov 19 09:19:09: %BGP-3-NOTIFICATION: sent to neighbor 10.101.0.2 3/10
> > (illegal network) 1 bytes 00 Nov 19 09:19:09: %BGP-4-MSGDUMP:
> > unsupported or mal-formatted message received from 10.101.0.2:
> > FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 006A 0200 0000 5340 0101 0040
> > 0200
> > 4005
> > 0400 0000 64C0 1010 0002 FFFF 0000 2774 800A 0502 0000 0064 800A 0400
> > 0000
> > 0180
> > 0904 0000 0000 900E 0020 0019 4104 0A65 0CF8 0000 1500 010A 650C F880
> > 0000
> > 0200
> > 0100 02C3 5001 0100 0200
> >
> This is the culprit's NLRI is AF: L2 VPN, SAFI" VPLS
> RD: 10.101.12.248:32768, CE-ID: 2, Label-Block Offset: 1, Label-Block Size: 2,
> Label Base 800000 (bottom) :
> 001500010a650cf88000000200010002c35001010002
>
> You can use http://bgpaste.convergence.cx/ to decode the message
>
> The NLRI is at the end of message -which makes it even more difficult to
> parse the message correctly (what code ver are you running on the RRs
> please?)
>
> Though not related, one think that got my attention right away was the
> empty ORIGINATOR_ID the RRs should have filled 10.101.12.248 in there.
>
> adam
>
>
>
>
>
> Adam Vitkovsky
> IP Engineer
>
> T: 0333 006 5936
> E: [email protected]
> W: www.gamma.co.uk
>
> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
> of this email are confidential to the ordinary user of the email address to
> which it was addressed. This email is not intended to create any legal
> relationship. No one else may place any reliance upon it, or copy or forward
> all or any of it in any form (unless otherwise notified). If you receive this
> email in error, please accept our apologies, we would be obliged if you would
> telephone our postmaster on +44 (0) 808 178 9652 or email
> [email protected]
>
> Gamma Telecom Limited, a company incorporated in England and Wales,
> with limited liability, with registered number 04340834, and whose registered
> office is at 5 Fleet Place London EC4M 7RD and whose principal place of
> business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>
>
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
