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

[Nick Hilliard]

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