BGP ASN Path issue

[kmelchior]

I am facing a BGP AS Path loop prevention issue.

I have three circuits (SP A internet, SP A MPLS and SP B MPLS) but for the purposes of this topic we only care about the two SP A circuits. We have a Palo Alto connected to the SP A internet circuit.. Our side is ASN 2 with SP A side as an eBGP peer on ASN 1. The Palo Alto is then an eBGP peer with both of our MPLS routers (SP A and SP B) on ASN 3. The MPLS router learn the default route from the Palo Alto and then advertise it out to the two MPLS clouds. However SP A uses ASN 1 on MPLS as well.

The issue I foresee with this is a BGP loop prevention behavior. The SP A MPLS PE will see ASN 1 in the AS path for the default route and drop that route.

PS A (ASN 1) My Internet (ASN 2) My MPLS CE (ASN 3) SP A MPLS PE (ASN 1)

I know I can resolve this by having SP A configure allowas-in or replace-as however they claim neither command is supported on their PE at this time. I am not sure why, these are pretty common configurations in BGP.

What are my other options to resolve this? Will as-override work? That is what SP A is suggesting but obviously it would have to replace a downstream ASN. They also suggested using default-originate, which I am hesitant to use. My understanding is that default-originate will advertise the default route even if one does not exist in the routing table. I will need failover for this as well.

Any thoughts or suggestions would be much appreciated.

[milan.kulik]

Hi,

I don't see any easy way of AS_PATH manipulation here without a support from the provider side.

Couldn't you use a different protocol (OSPF, e.g.) to peer between your router and A MPLS?

Redistributing prefixes to/from OSPF would remove the whole AS_PATH info.

Best regards,

Milan

 

[kmelchior]

Hi Milan,

BGP is my only option. I was afraid this would not be easy, but I can;t be their only customer with this issue. So no way as-override on my side will fix the issue? I didn't think it would but they were insistent that it will.

Kevin

[milan.kulik · Accepted solution]

Hi,

I'm afraid  it would be quite a challenge with as-override.

As

a) it's supported only under the VPNv4 address-family configuration mode,

b) it overrides the AS of the neigbor sending you the prefix with your own AS number.

See here for an explanation:

https://supportforums.cisco.com/document/87671/understanding-bgp-override-feature

So  in your case you would have to apply it on peering to both SP A Internet and SP A MPLS neighbors.

And configure them to peer within the same VRF (together with your iBGP connection).

So some kind of VRF-lite configuration on your router?

Quite a complicated configuration to fix a problem on your provider side!

Best regard,

Milan

[kmelchior]

That is what I thought as-override did and would not replace a downstream ASN. Let's not go down that road about it being the SP's issue haha

Thanks!

Kevin

[Jose Jara]

Hi,

I see different options:

- As-Override: be aware that the feature is VRF-Aware so you would need to configure the BGP session in a VRF.

- Default-originate per neighbor: you could do this conditionally, generating the default only as long as you are receiving the original default route from ASN1. I've done this in the past as I had exactly the same problem as you and I think it's the easiest one:

neighbor x.x.x.x default-originate route-map DEFAULT

route-map DEFAULT 

match ip address prefix-list DEFAULT

ip prefix-list DEFAULT permit 0.0.0.0/0

By the way, be aware that when you are applying this command (default-originate), the 0/0 it does not pass by the BGP filters (Adj-RIB-Out ), so in case you are modifying any BGP attribute for path manipulation you should do it in the route-map applied to this command, otherwise it will not work. For example, if you are modifying the MED attribute with a route-map applied to the neighbor, here it's not going to work, do this in the route-map DEFAULT.

- Conditional Route Injection: this approach is very similar to the previous one, you would use an inject map to generate an exact copy of the default route received. However, as you are injecting it (without the command copy-attributes) it will have an empty AS-Path. The difference is that you will inject it in the Local BGP table,having the injected default and the original default route received so be careful and make the injected preferred rather than the original.

- Split the default route, for example in 0/1 and 128/1 and use conditional advertisement. Only in case you receive the default route you will advertise the two supernets.

Hope this helps,

Jose.

[kmelchior]

So as-override needs to be in a vrf or just under an address-family?

router bgp 1

address-family ipv4

 neighbor x.x.x.x as-override

or

router bgp 1

address-family ipv4 vrf xyz

neighbor x.x.x.x as-override

Thank you for the default-originate config. I may end up having to do that.

[Jose Jara · Accepted solution]

As-Override in a vrf 

[kmelchior]

Jose and Milan,

Thank you for your assistance. I built this out in GNS and the conditional default-originate worked well. I really don't want to build out a vrf in order to support as-override so att is point I am going to go with the default-originate unless the SP comes back to me and says they will do allowas-in or replace-as. I still wonder what PE's they are using as they clain they don;t support these features, which are pretty basic comon features in BGP.

Kevin

[milan.kulik]

Hi,

actually as-override would make it working, I believe.

But you would have to put all your neighbors into a VRF to be able to apply the as-override command.

Which would mean a total rebuilding of your config, I'm afraid.

The  default-originate with a route-map matching the default route presence suggested by Jose below is much easier, I guess.

I was thinking about it but was not sure if it would work with matching the default route - so far I used it matching more specific subnets only.

But as Jose says he was using it successfully, it works!

I'd just think about prepending your ASN3 number several times possibly within that route-map? That would make the AS_PATH length similar to the original default route AS_PATH length preventing this default route getting advertised to the MPLS cloud with  AS_PATH too short (not sure if it's important in your case).

Best regards,

Milan

[kmelchior]

Any issues with using default-originate and tracking (the SP's other suggestion)? I really don't want to but if the SP won;t fix the issue on their side I may not have a choice.

If default-originate advertises the default route whether or not one exists in the routing table I fail to see how tracking anything will make a difference with that.