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
Sorry, I dont understand what you mean. But is for my english.
Can you explain it in dummy english?
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'.
Yeah that's what happens here too but just wondering if it's everywhere, answer seems yes
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.
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.
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
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
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.
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.
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.