SP MPLS-VPN best practices - overlapping BGP ASN?

Started by wintermute000, February 08, 2016, 07:43:55 PM

Previous topic - Next topic

wintermute000

A question for you guys in the SP Space

What's SP best practice for dealing with L3VPN scenarios where the ASN you've chosen on your PEs overlaps with the customer, or, the customer wants multiple IP-VPNs (and obviously wants different carrier ASNs). As in normal IOS/IOS-XE, one BGP process = one ASN.



Do you guys
- have separate 'sets' of PE/RRs with different private ASNs (surely unscalable)
- use the 'standard' methods like local-as or allow-as in (do you offer this level of bespoke complexity to your customers? poor support teams)
- force the customer to use the above methods
- some JUNOS or IOS-XR feature I'm not aware of?


What I'm hearing is that c.) (i.e. customer overwrites the overlapping ASN or otherwise deals with it) is the normal standard, whether directly or via carrier managed CPE

TheGreatDoc

Sorry, I dont understand what you mean. But is for my english.

Can you explain it in dummy english?
a.k.a. Daniel.
I dont have any cert, just learned all by my self.

Reggle

I have no practical experience on the SP side, but here in Europe the SP would simply say 'this is our AS, deal with it'.

wintermute000

Yeah that's what happens here too but just wondering if it's everywhere, answer seems yes

matgar

I had a brief stint in the MPLS provisioning team for an international SP here in Sweden back in 2008.
From what I can remember I did quite a bit of local-as and allow-as in.
But it was a limited position, ie check these boxes, fill in these values and hit commit type of work. If something doesn't work? Escalate and move on.
So I never did get a good understanding of the whole setup and I moved after a few months.

deanwebb

Quote from: TheGreatDoc on February 09, 2016, 01:11:18 AM
Sorry, I dont understand what you mean. But is for my english.

Can you explain it in dummy english?

If there is a conflict in the configuration of the Service Provider (SP) network and the customer network, how is that conflict resolved?

The answer seems to be that the customer will have to change.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

Otanx

I don't work in the SP world, but wouldn't the SP be using a real AS instead of private space on their side? I would also think a SP would have multiple real AS numbers, or maybe this is only the case with the big guys who have merged with others.

-Otanx

TheGreatDoc

But there are different cases!

Customer with private AS - It will never be visible on the BGP routes. This is common sense!

Customer with public AS(1) - It is visible but may be have BGP restrictions (like not allowed to send communities)

Customer with public AS(2) - It is visible and dont have any kind of restrictions on BGP

Customer without AS - Wth are you doing here dude? Move on!

Of what kind of problem are you asking for? :D
a.k.a. Daniel.
I dont have any cert, just learned all by my self.

wintermute000

You're thinking about the internet. I'm referring to L3VPN. The customer will see the ASN of the L3VPN PE routers in the BGP table, unless features such as local-as are used.

Most providers (all?) have a single ASN they use for all L3VPNs, because on a router, a BGP instance has the same ASN for all address families/VRFs. So its impractical to let customer pick the L3VPN ASN.
Some providers sensibly use a public ASN so it never clashes with the customer.
However this does not rule out the second scenario, where a customer  customer has 2x L3VPNs from the same provider and traffic needs to route from one L3VPN to the other via a CE site. This will then mean the ASN from one VPN looks duplicate when the routes are advertised into the other VPN.

routerdork

I've seen carriers use a public AS for this. On the CE side they picked a range of AS's, with the next one in line being used as circuits were turned up. It was not uncommon for us to see 3, 4, or more AS's in a path to some of our international sites.
"The thing about quotes on the internet is that you cannot confirm their validity." -Abraham Lincoln

packetherder

Quote from: matgar on February 09, 2016, 03:28:29 AM
I had a brief stint in the MPLS provisioning team for an international SP here in Sweden back in 2008.
From what I can remember I did quite a bit of local-as and allow-as in.
But it was a limited position, ie check these boxes, fill in these values and hit commit type of work. If something doesn't work? Escalate and move on.
So I never did get a good understanding of the whole setup and I moved after a few months.

Only been a customer, but with a handful of l3vpn providers. Local-as is what they did when a spattering of ASNs wasn't going to work or they just used private ASNs by default.