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