03-10-2016 11:30 PM - edited 03-05-2019 03:32 AM
Dear community
I've a BGP question.
I've a router peering with a customer of mine, plain EBGP no MPLS, see following chain as example:
myrouterA --ebgp-- myrouterB --ebgp-- myrouterC --ebgp-- mycustomerA --ebgp-- mycustomer_BGP_worldwide_network
Among myrouterX I use EBGP with private AS, now I've mycustomerA router that in its BGP path is injecting me a private AS already present in my network and I'm getting routes discarded for that at the end of the chain.
I tried to use:
- remove_private_as on myrouterC towards my network in egress but it seems that it's able to remove only if there are private AS in the path and at the first not private it stops removing;
- as_override but it works only under a vrf environment and it's not the case
I'm wondering if you see another feasible solution...
Cheers
03-11-2016 12:19 AM
Hi James,
If your router C is running 15.1(2)T or newer, you can use neighbor remove-private-as all command which will replace all occurrences of a private ASN in the AS_PATH:
Or you could have your customer A configure its router toward your router C with neighbor allowas-in:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mpls/command/mp-cr-book/mp-m4.html#wp2021165699
Best regards,
Peter
03-11-2016 12:19 AM
Hi Peter,
the first option would be nice but once applied the router says that it's not possible to use it if you have a local private AS...
Cheers
03-11-2016 12:26 AM
Hi James,
Yeah, that's logical because then the AS_PATH would possibly remain empty which is not possible on eBGP peerings.
I am wondering if a trick could be used with neighbor local-as using which you would act as a router of a different ASN to the customer. It would still need to be combined with remove-private-as but perhaps it would allow you to actually use the remove-private-as in the first place. The use of local-as would, however, necessitate a configuration change on the customer's router as your apparent ASN would change.
Best regards,
Peter
03-11-2016 01:27 AM
Hi Peter
tested the trick but no success, the same as before :-(
Cheers
03-12-2016 04:27 AM
Hi Jim,
I am sorry to hear that.
Unfortunately, I am afraid we are running out of options. The primary problem is that you are using a private ASN for a transit AS. Private ASNs were never meant to be used that way; they were intended to be used by end customers of single upstream SPs. By having a transit AS use a private ASN, we're now basically facing problems caused by a bad design.
The only option left, as far as I can see, is to use the neighbor allowas-in on those routers that are dropping the update because they see their own ASN in the AS_PATH.
Best regards,
Peter
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: