Let's say, that an organization has two geographically diverse DFZ sites named site-A and site-B. In site-A, the network is in use and in site-B the network is used. Normally, the site-A-r1 router sees the via iBGP over the circuit connecting the two sites. Same applies to site-B-r1 router, which sees the via iBGP over the same circuit.

Now let's say that the circuit breaks:

allowas-in example diagram

If both site-A-r1 and site-B-r1 are configured to accept prefixes with its own AS number in as-path(Allow AS in Cisco terminology), then the connectivity between the two sites would remain working over the Internet.

Is it possible to ensure, for example with BGP import filters, that the received by site-A-r1 is actually from site-B and the, received by site-B-r1, is actually from site-A? I guess one option would be to check if the first AS of the AS path is 64496 and the second AS is the ASN of the site ISP. However, I guess this doesn't provide much security as anyone can announce the same prefix and prepend the AS numbers to AS path.

In case there is no need to ensure the connectivity between the sites at the time when the circuit is down, then one could simply reject the and in eBGP import filters in site-A-r1 and site-B-r1 routers, respectively.

1 Answer 1


As you point out, you normally can't do this. BGP (eBGP) does not allow its own AS in the path - that's part of the loop prevention. But people have since "tweaked" that; no one should!

Having dealt with this very issue decades ago, there were two solutions:

  • tunnel (virtual interface)
  • BGP multi-hop

We went with a tunnel as it provides the greatest flexibility... we know what's going where, it can be encrypted (and was), and it's an iBGP link. Multihop would also work, but I don't trust the inherently insecure BGP protocol over the general internet. (although in our case, it was across a transit provider network, not the Big Bad Internet)

BGP was never designed with security in mind. (everyone could trust each other back then) RPKI is the only functional band-aid allowing one to authenticate an announcement. Without a crypto signature, anyone can claim to be anyone. (and sometimes it's helpful to do so.)

  • 1
    Most BGP implementations support if not TCP-AO signatures, then at least TCP-MD5 ones, don't they? I really don't understand this argument – it's like saying that no features can be added post-factum, ever. HTTP, for example, was never designed with security in mind, either, but nobody seems to take it as an issue that it bundles TLS instead of having its own security features. Commented May 27 at 4:36
  • 2
    A tunnel would also be my preferred option, as that just makes it a backup link replacing the existing one, and should not require any changes to the BGP config.
    – jcaron
    Commented May 27 at 8:40
  • 1
    MD% might've been a reasonable band-aid in the 80's, but hasn't been for over a decade. There are plenty of ways to defeat MD5. TCP-AO is effectively IPSec - TCP layer encryption. Both only secure the overall communications channel, it does nothing to authenticate an announcement - any configured peer can still lie, or pass along a lie. OP wants a way to have "iBGP" beyond their own network. TCP-AO could secure that peering, but it would still require BGP multi-hop across someone else's network - possibly a questionable one.
    – Ricky
    Commented May 27 at 12:58
  • @Ricky Am I correct, that you built the tunnel between the IP addresses from the p2p networks assigned by the ISPs for eBGP?
    – Martin
    Commented May 28 at 21:02
  • 1
    Correct. The VTI uses the "outside" transit provider interfaces. Being a "provider edge" router, every interface is public and reachable from any other interface. It's tied to a single transit provider, but could easily be unpinned should that provider have an issue too.
    – Ricky
    Commented May 28 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.