New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
How to use a Single ASN across multiple locations for BGP session.
- If multiple locations are administered by a single entity, how we use single ASN for BGP session.
- How the prefix can be announced to different peering ASN's (public) at multiple locations.
- How this works on an incoming request.
- Are we expected to get an issues
Please share your views and suggestions.
Comments
You just setup BGP sessions in each location.
That's something called Anycast. Requests are routed to the closest location.
It's not a problem that you are using the same AS at multiple locations. The only problem could be that the different locations would not be able to see each other if there are no direct connections between the locations. To overcome this, you can do two things:
Both would work well.
The smallest block you can announce per location is a /24, using the same ASN though, yes.
I guess same IP prefix is advertised from multiple locations in anycast and user requests are routed based on routing protocol costs / 'health'. My case is like One ASN, different prefix from multiple geo location.
Thanks, Yes visibility among locations should be taken care.
Right
Could there be any thing more to be considered.
Other than heaving a messy setup, harder diagnostic in case of routing issues, and messing with all the BGP optimisers that some networks use, there are no issues in using the same ASN across many unconnected locations.
Why a messy setup? I do the same since 1.5 years and I don't see anything that is harder to debug/configure. The only thing you have to configure is allow-asin.
Nailed it
Mind explaining the two options?
If you have a fulltable and receive a route with your own ASN in the path, BGP usually drops this route (loop protection). That would mean, you cannot reach the second location as the route will not be installed. To prevent that, you can turn on allow-asin, then the route will be accepted.
If you have a default route, that's not a problem as this route covers all traffic.
Example situation:
If I want to optimise routing between us, I will use communities. Traffic engineering communities are per ASN, and not per prefix, which makes it much harder or impossible to work towards better lately or avoiding packet loss between our networks if the 'default' route is problematic.
Example 2:
BGP optimisers using AS historical data to plan routing, by using the same AS in a non-anycasted network you break this feature too.
How do you mean communities are per asn? I can set communities for each single prefix (example if I want to blackhole prefix 1.2.3.0/24 at level3, I set 3356:9999 on this prefix by route map / filter). Works perfect.
Yes. But when I want Level3 to prep end 3 times to you as I can see that you have problems with your Level3 connection, or there is a problem within Lecel3 between us I can't do it as it would also affects other PoPs.
Level3 BGP traffic engineering communities (some of them)
65001:0 - prepend once to all peers
65001:XXX - prepend once at peerings to AS XXX
65002:0 - prepend twice to all peers
65002:XXX - prepend twice at peerings to AS XXX
65003:0 - prepend 3x to all peers
65003:XXX - prepend 3x at peerings to AS XXX
65004:0 - prepend 4x to all peers
65004:XXX - prepend 4x at peerings to AS XXX
As you can see 'the other end', the community action is ASN dependant.
Same if I see that my outgoing route to you is problematic. I won't engineer per single prefix, I will engineer per ASN. For example, Virgin Media has a problem with their peering at LINX today. Whatever is announced via Virgin Media's AS send via NTT.
Setup that shares the ASN across many locations unconnected with each other is simply disturbing, or makes it impossible to engineer and may break the connection all together if say you have 7 locations and one of them is single homed to Level3 and I set a community to not announce my subnet to your ASN via Level3.
There is a reason why you have different ASN's. If there wouldn't be, why wouldn't we just randomly select numbers, or simply ditch the ASN's all together?
Their sole purpose is to identify network, and if you have 10 unconnected networks, you still have 10 Autonomus Systems, to make it neat and clean you should have a single ASN per each of your network that has a different network policy, especially that, for example in the RIPE region they are free.
Yes, that's true. But it will never be reality that all ASN operators will announce a consistent set of routes at all locations to all peers.