[ixpmanager] Fwd: Malformed AS_PATH BGP Error Message from CDN Peer

[Brian Longwe]

Hi Nick,

Thanks for the detailed explainer. It’s a new BGP connection at the IX. I
will keep pushing for them to add the parameter to their BGP config.

Thanks!

Brian

On Fri, 24 Jul 2026 at 7:48 PM, Nick Hilliard via ixpmanager <
ixpmanager at inex.ie> wrote:

> Brian Longwe via ixpmanager wrote on 24/07/2026 16:49:
> > I've been in touch with the CDN and they seem adamant about not changing
> > anything on their side, still getting "Malformed AS_PATH" - is there
> > nothing we can do about this?
>
> Hi Brian,
>
> Route servers work differently to other EBGP systems. Let's take an
> example where you have a regular provider-customer BGP relationship. The
> provider is AS123 and the customer is AS333. Let's say that the provider
> wants to send a BGP prefix of 192.0.2.0/24 to the customer with AS path
> "777 888 999". When it sends BGP UPDATE protocol message to the
> customer, it prepends its own ASN to the AS_PATH, so that the customer
> sees the AS_PATH "123 777 888 999".
>
> This is such a common configuration that some BGP stacks, for example
> Cisco / FRR / Arista, automatically insist that the first ASN in the
> path of any BGP update they receive from a peer must have the peer's ASN
> as the first entry in the AS-PATH. In the example above, if the provider
> sent the update with an AS path of "777 888 999", i.e. without 123
> inserted at the front of it, then a normal cisco configuration would
> reject the BGP UPDATE message and then terminate the session with
> "Malformed AS_PATH".
>
> This approach makes sense for provider-customer EBGP sessions.
>
> A route server is different because it's a BGP UPDATE broker, not a
> router which handles forwarding. For a route server at an IXP, what you
> want is for everyone connecting to the route server not to see the ASN
> of the route server in the AS_PATH of any BGP updates. The reason you
> don't want to see the RS ASN in the AS path is that it causes BGP to
> automatically deprefer prefixes learned from route servers due to the
> longer AS Path.
>
> This means that by default, if you connect a cisco router to an IXP
> route server, it will terminate the BGP session as soon as it receives
> the first BGP UPDATE message from the RS. This is expected behaviour,
> and the way to work around this is for the route server client (i.e.
> Edgenext) to configure "no bgp enforce-first-as" in the router bgp
> stanza, or "bgp enforce-first-as disable" if they're running XR.
>
> There's more information about route servers on the INEX web site:
>
> https://www.inex.ie/technical/route-servers/
>
> If they want formal documentation for this, there's a specification in
> rfc7947:
>
> https://datatracker.ietf.org/doc/html/rfc7947#section-2.2.2.2
>
> If it gives any comfort to Edgenext, adding "no bgp enforce-first-as" to
> an existing configuration is not service affecting, and secondly all
> other CDNs which have ever connected to a route server have also used
> this config command. That includes the usual big names (FAANG, etc).
> I.e. there isn't a particular operational problem with using it on
> IXP-connected routers.
>
> As Salvador said, this specific problem accounts for the overwhelming
> majority of IXP Route Server disconnections due to malformed AS-PATH
> errors. That said, "overwhelming majority" is not all situations, so
> there's a possibility it could be a BGP UPDATE message which has an
> AS-PATH which is malformed in some other way. But it would be wise to
> rule out problems with "enforce-first-as" first because this is easy to
> check and fix.
>
> Was Edgenext's BGP session working before, and did it then stop working?
> Or is this a new BGP session?
>
> Nick
>
> _______________________________________________
> INEX IXP Manager mailing list
> ixpmanager at inex.ie
> Unsubscribe or change options here:
> https://www.inex.ie/mailman/listinfo/ixpmanager
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.inex.ie/pipermail/ixpmanager/attachments/20260724/2cdd5dc3/attachment.htm>