Solved: BGP routing with duplicate AS# in the path. Is this possible?

robin99 · ‎09-09-2013

I have a challenging BGP routing requirement which I thought someone has done this before and able to share the solution. The BGP AS# topology is as follow:

#7778 --- #7777 ---- #65000 ---- #5555 ---- #5556 ---- #7777 ---- #65001

I need to enable routing between two endpoints that has two separate BGP AS# cloud (but they are having same AS# (#7777 in the above example). There is no duplicate IP address range. So I need to enable connectivity between hosts in AS#7778 and hosts in AS#65001.
The AS path in between has two entries for AS$7777. I do NOT have change permission on routers in AS#7777.
Can I use BGP allow-as in feature on the #65000 AND #5556 routers to make the routing works? I will still apply the route filter to prevent routing loops. Can someone share his/her experience with the above setup?
Thanks

Peter Paluch · ‎09-10-2013

Hi Robin and Alain,

I completely agree with Alain. The routes from AS 7777 on the left won't be accepted by the AS 7777 on the right (and vice versa), so the border routers in both instances of AS 7777 will need to be configured with neighbor allowas-in command.

If there is no way to change routers in AS 7777 then the other solution would be to use neighbor as-override command in AS 5556. However, as this command is only available for BGP neighbors defined in address-family ipv4 vrf ..., this would require AS 5556 to carry the transit traffic between 5555 and 7777 in a VRF, possibly necessitating the need of running MPLS.

If this is not an option, either, then I see two other ways of doing this with limited applicability:

Aggregating routes in BGP using aggregate-address command without the as-set will remove the set of original AS_PATH elements from the aggregate route. Hence, if the networks from left and right AS 7777 were aggregated into two or more non-overlapping prefixes somewhere on the path inbetween (ASes 65000, 5555, 5556), they would lose the AS_PATH element 7777 from their new AS_PATH. This could allow them to be accepted by opposite AS 7777. The gotcha here is to make sure that the aggregate address is broad enough to cover all prefixes in that AS while not infringing on any other's AS address space.
Creating a GRE tunnel that interconnects selected ASes while skipping at least one of the AS 7777 so that the routes advertised through this tunnel never get dropped because of AS 7777 seeing its own AS number in the AS_PATH. This is a very dirty solution, though, with lots of negative side effects.

Best regards,

Peter

View solution in original post

Jose Jara · ‎09-10-2013

Hi Robin,

I agree with Cadet. Also, great explanation by Peter.

I see these options here:

- Create Aggregates without the as-set option as Peter said.

- Inject the same prefixes that you are receiving from AS 7777 with bgp inject-map. Even though this is used for de-aggregation, it could be used here to create copies of the same prefixes that you are receving and, as you are doing this locally, it will appear without the original AS_PATH. You should not use the copy-attributes keyword.

- Inject the default route in one direction with neighbor default-originate and the aggregates in the other one. It depends on the scenario. I used this once in a MPLS/VPN environment for a CPE which had the same provider for the domestic network and same for the international network. I sent the aggregates with aggregate-address summary-only towards the international VPN and the default via neighbor default-originate conditionally and it worked perfectly.

- Use AS-Override in AS 65000 peering with 7777 and in the session of 5556 peering to 7777. It is mandatory to create a VRF, however, as VRF's have local meaning it does not matter. You do not need to run MPLS... The next router that you are peering does not need to have a VRF configured.

I would go with the simpler solution.

Best Regards,

Jose.

View solution in original post

Jose Jara · ‎09-12-2013

Hi Robin,

the use of bgp inject-maps is good if there are not a lot of prefixes, because you have to create exact copies of the prefixes. So, in your example it will not work as you are not specifying what prefixes you want to inject, just a range.

Also, for the filtering of these injected prefixes, be aware that BGP only advertises the best path, so it will not send duplicate copies. However, you should avoid that the prefixes created locally (injected) be advertised back to the AS that sent it. You could do it in the route-map ORIGINATE setting a community and then filter with another route-map applied to neighbor that is sending the original update, everything that is marked with this community.

Another thing to take into account is the attributes that the injected paths insert in the prefix by default, which are: origin incomplete, empty AS_PATH, weight 0 (unlike locally originated routes via network or aggregates, which is 32768). Then, remember that for this to work, this prefix must be better than the original one, otherwise you will send the original. So, you may change the attributes in the route-map ORIGINATE to make always the injected path better.

Last but not least, the bgp inject-map feature is controlled by the BGP scanner timer, so take this into account for the convergence time expected.

Best Regards,

Jose.

View solution in original post

cadet alain · ‎09-09-2013

Hi,

The allow-as in is only valid on a BGP peer which has the same AS.The devices in AS 65000 won't reject the eBGP update if they don't see their own AS number in it and as they are not in AS 777 it is not a problem.

You must do this on the devices in AS 777.

Regards

Alain

Don't forget to rate helpful posts.

Peter Paluch · ‎09-10-2013

Hi Robin and Alain,

I completely agree with Alain. The routes from AS 7777 on the left won't be accepted by the AS 7777 on the right (and vice versa), so the border routers in both instances of AS 7777 will need to be configured with neighbor allowas-in command.

If there is no way to change routers in AS 7777 then the other solution would be to use neighbor as-override command in AS 5556. However, as this command is only available for BGP neighbors defined in address-family ipv4 vrf ..., this would require AS 5556 to carry the transit traffic between 5555 and 7777 in a VRF, possibly necessitating the need of running MPLS.

If this is not an option, either, then I see two other ways of doing this with limited applicability:

Aggregating routes in BGP using aggregate-address command without the as-set will remove the set of original AS_PATH elements from the aggregate route. Hence, if the networks from left and right AS 7777 were aggregated into two or more non-overlapping prefixes somewhere on the path inbetween (ASes 65000, 5555, 5556), they would lose the AS_PATH element 7777 from their new AS_PATH. This could allow them to be accepted by opposite AS 7777. The gotcha here is to make sure that the aggregate address is broad enough to cover all prefixes in that AS while not infringing on any other's AS address space.
Creating a GRE tunnel that interconnects selected ASes while skipping at least one of the AS 7777 so that the routes advertised through this tunnel never get dropped because of AS 7777 seeing its own AS number in the AS_PATH. This is a very dirty solution, though, with lots of negative side effects.

Best regards,

Peter

Jose Jara · ‎09-10-2013

Hi Robin,

I agree with Cadet. Also, great explanation by Peter.

I see these options here:

- Create Aggregates without the as-set option as Peter said.

- Inject the same prefixes that you are receiving from AS 7777 with bgp inject-map. Even though this is used for de-aggregation, it could be used here to create copies of the same prefixes that you are receving and, as you are doing this locally, it will appear without the original AS_PATH. You should not use the copy-attributes keyword.

- Inject the default route in one direction with neighbor default-originate and the aggregates in the other one. It depends on the scenario. I used this once in a MPLS/VPN environment for a CPE which had the same provider for the domestic network and same for the international network. I sent the aggregates with aggregate-address summary-only towards the international VPN and the default via neighbor default-originate conditionally and it worked perfectly.

- Use AS-Override in AS 65000 peering with 7777 and in the session of 5556 peering to 7777. It is mandatory to create a VRF, however, as VRF's have local meaning it does not matter. You do not need to run MPLS... The next router that you are peering does not need to have a VRF configured.

I would go with the simpler solution.

Best Regards,

Jose.

Peter Paluch · ‎09-11-2013

Hi Jose,

Hmmm... bgp inject-map - haven't thought of that but it's a great idea!

Best regards,

Peter

robin99 · ‎09-11-2013

Dear Jose and Peter.

Thanks very much for sharing your thought. There are two options left in my mind now:

1. Create Aggregates without the as-set option as Peter said.

2. Inject the same prefixes that you are receiving from AS 7777 with bgp inject-map. Even though this is used for de-aggregation, it could be used here to create copies of the same prefixes that you are receving and, as you are doing this locally, it will appear without the original AS_PATH. You should not use the copy-attributes keyword.

Option 1 is simple to do.

Option 2 is interesting and I have some questions. With the sample config below, would the CE router in AS65000 copies ALL the specific routes (such as 10.1.2.1 /32, 10.1.0.0 /24, etc within 10.1.0.0/20 up to /32 range addresses) received from AS7777 to the neighbors behind? Also to prevent DUPLICATE routes sent to AS#5555, can I add BGP outbound route filter based on AS_Path? If this is the case I will go with this option for more granular routing.

Thanks heaps.

router bgp 65000

 bgp inject-map ORIGINATE exist-map LEARNED_PATH

 route-map LEARNED_PATH permit 10

  match ip address prefix-list ROUTE

  match ip route-source prefix-list ROUTE_SOURCE

 route-map ORIGINATE permit 10

 set ip address prefix-list ORIGINATED_ROUTES

ip prefix-list ROUTE permit 10.1.0.0/20 le 32

ip prefix-list ORIGINATED_ROUTES permit 10.1.0.0/20 le 32

 ip prefix-list ROUTE_SOURCE permit 10.2.1.1/32 (this is the BGP neighbor at A#7777)

Jose Jara · ‎09-12-2013

Hi Robin,

the use of bgp inject-maps is good if there are not a lot of prefixes, because you have to create exact copies of the prefixes. So, in your example it will not work as you are not specifying what prefixes you want to inject, just a range.

Also, for the filtering of these injected prefixes, be aware that BGP only advertises the best path, so it will not send duplicate copies. However, you should avoid that the prefixes created locally (injected) be advertised back to the AS that sent it. You could do it in the route-map ORIGINATE setting a community and then filter with another route-map applied to neighbor that is sending the original update, everything that is marked with this community.

Another thing to take into account is the attributes that the injected paths insert in the prefix by default, which are: origin incomplete, empty AS_PATH, weight 0 (unlike locally originated routes via network or aggregates, which is 32768). Then, remember that for this to work, this prefix must be better than the original one, otherwise you will send the original. So, you may change the attributes in the route-map ORIGINATE to make always the injected path better.

Last but not least, the bgp inject-map feature is controlled by the BGP scanner timer, so take this into account for the convergence time expected.

Best Regards,

Jose.

milan.kulik · ‎09-13-2013

Hi Robin,

how many prefixes are we talking about here?

As all the sophisticated solutions discussed so far are suitable for a small number of prefixes only, I'm afraid.

If you need a solution for many prefixes, I'm afraid only a "brutal force" would work.

I did something similar in the past by redistributing the prefixes with unacceptable AS_PATH to OSPF on one router and redistributing them back from OSPF to BGP on another router.

This way the original AS_PATH was removed totally and I was able to create a new AS_PATH by prepending on the second router.

(My solution was more complicated in fact - 4 routers used for redundancy and BGP attributes and ADs manipulated as it had to work both directions. But possibly a simple one-direction solution would be enough in your case?)

Best regards,

Milan

robin99 · ‎09-15-2013

Hey Milan and Jose,

Thanks for your comments. There are about 500 prefixes on CISCO3945 so I belive the inject-map is not feasible anymore for me. I thought the Originated range specified can automatically duplicates all subnets within the stated range

I think. So only the "aggregate-address summary-only" solution work for me.