cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1172
Views
35
Helpful
21
Replies

Moving providers

Bab L
Level 1
Level 1

Hi.

We are in the process of moving WAN providers.

This will happen on site to site basis with over 100 sites to complete.

Once each site moves it will still need to communicate with the other site via our DCs.

In order to avoid loops, is tagging the best method or is there a better way of doing it?

Any input will be helpful.

Thank you

2 Accepted Solutions

Accepted Solutions

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Bab L,

>> 

This will happen on site to site basis with over 100 sites to complete.

Once each site moves it will still need to communicate with the other site via our DCs

>>

yes the use of route tags is recommended. Eventually if eBGP is involved you may need to use BGP community in place of a route tag when importing into BGP.

Hope to help

Giuseppe

View solution in original post

Well, not necessarilly, I'm afraid.

As you are migrating from one provider to the second, so when the site is migrated, its subnet is moved from one provider network to the second provider network.

So even when different routing protocols woud be used per provider, the subnet will only be originated within one of them.

So no matter of AD, it should be redistributed to the second routing protocol to assure the site is still reachable from both provider networks.

And to avoid routing loops, it shoud be tagged when redistributed and those tagged prefixes should not be redistributed back to the original protocol.

Best regards,

Milan

View solution in original post

21 Replies 21

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Bab L,

>> 

This will happen on site to site basis with over 100 sites to complete.

Once each site moves it will still need to communicate with the other site via our DCs

>>

yes the use of route tags is recommended. Eventually if eBGP is involved you may need to use BGP community in place of a route tag when importing into BGP.

Hope to help

Giuseppe

Hi,

if BGP involved, I'd also check which AS numbers are used by each provider.

AS numbers in clash might cause an issue eventually.

Best regards,

Milan

Thanks for your feedback both.

Will manual administrative distance do the trick?

We are using eigrp and bgp in some cases.

Well, not necessarilly, I'm afraid.

As you are migrating from one provider to the second, so when the site is migrated, its subnet is moved from one provider network to the second provider network.

So even when different routing protocols woud be used per provider, the subnet will only be originated within one of them.

So no matter of AD, it should be redistributed to the second routing protocol to assure the site is still reachable from both provider networks.

And to avoid routing loops, it shoud be tagged when redistributed and those tagged prefixes should not be redistributed back to the original protocol.

Best regards,

Milan

Ok. Thanks.

So, tagging looks like the best way. It's just that we are looking at the more dynamic way of doing this rather than configuring tagging every time we move a site.

Is there anything else that can be done to avoid the loops? e.g. vrf etc....

Hi,

I don't think you would have to configure tagging every time you move a site.

I'd just once configure a route-map tagging all prefixes being redistributed from one routing protocol to the other on your central site/

Best regards,

Milan

Hi Milan,

thank you for your feedback.

My understanding is that that if for example you want to move site 1.1.1.0/24 from one provider to the other, then you tag that subnet range.

How else can you do it?

Hi,

to give an exact answer I'd need to know more details about your redistribution.

Let's take a simple example:

I suppose you've got your sites connected to two provider "clouds" and the only interconnecting point is your DC where your routers are providing mutual prefix redistribution between the provider "clouds"?

So when a particular site is moved from one provider to the other, its prefix(es) disappers from the "old" cloud, appears in the "new" cloud and needs to be redistributed to the "old" cloud?

And you need a route-map tagging the prefixes when being redistributed.

Let's say the prefixes redistributed from cloud 1 to cloud 2 would be tagged as " 1", prefixes redistributed from cloud 2 to 1 would be tagged as "2".

So the route-maps used for the redistribution would have to deny prefixes tagged as "1" to be redistributed back to cloud 1 from cloud 2 (and vice versa, prefixes tagged as "2" must not be redistributed back to cloud 2 from cloud 1).

To be precise, the route-map used for the redistribution from cloud 1 to cloud 2 should first deny the prefixes tagged as "2" already and then to tag the remaining prefixes as "1".

So in this simple example you don't need to tag each prefix manually.

Your topology might be more complex, of course, and you might need to handle the DC prefixes a different way, e.g.

Best regards,

Milan

   

Hi Milan,

thank you for your reply.

I suppose you've got your sites connected to two provider "clouds" and the only interconnecting point is your DC where your routers are providing mutual prefix redistribution between the provider "clouds"?

Correct. That's is exactly what's going to happen.

So when a particular site is moved from one provider to the other, its prefix(es) disappers from the "old" cloud, appears in the "new" cloud and needs to be redistributed to the "old" cloud?

Not exactly. When one site moves it will be gone from one provider, but it will need to communicate with the other sites that haven't moved yet plus the sites that have moved. I guess the issue here is that we have 3 DCs that routing can go through. So, when one moved site tries to communicate with a non-moved site, than it has to follow the correct route. Dc's are in different continents.

Let's say the prefixes redistributed from cloud 1 to cloud 2 would be tagged as " 1", prefixes redistributed from cloud 2 to 1 would be tagged as "2".

So, you're saying by tagging this way we won't need to tag it every time we move? We still need to tag all subnets though don't we?

Thank you

Hi,

all I'm saying is you can tag ALL redistributed prefixes by one route-map configured only once.

If you want to discuss further details, you would need to say how exactly is you redistribution configured. 

Best regards,

Milan

Hi Milan,

we haven't started the migration yet. We are still in planning phase.

So you're saying to add all prefixes into one route map? Don't we need to remove those prefixes once the site is moved?

So, for example if we have sites 1.1.1.0, 2.2.2.20, 3.3.3.0 in a route map with tagging, and 1.1.1.0 moves, don't we have to remove it from the route map?

I just can't see not doing manual configuration after each site moves.

Regards,

Bab

Tag all routes in to our out from the WAN provider without specifying individual prefixes.

I don't think this document exactly matches your scenario but it's some good info that might help.

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/28784-bgp-community.html

Thanks Tod.

This document supports what I'm saying that all sites will be configured individually when moved. So, every time we move a site we have to change the tag on each DC router for that specific prefix.. So, when a site is ready to move, we have to add the tags to this subnet.

Thanks for your input. I can't see how this can be done dynamically.

Bab

Hi Bab,

what I'm saying is:

You don't need to list particular subnets (per site) in your route-map defining which prefixes shoud be redistributed.

An example:

Let's say all your branch sites can be covered by 10.10.0.0/16 aggregate prefix.

Some of them are still connected to the old Provider 1, some of them already migrated to the new Provider 2.

So you can configure on your DC router connected to both providers:

ip prefix-list branches seq 5 permit 10.10.0.0/16 le 32

!

route-map to-provider2 deny 10

  match tag 2

route-map to-provider2 permit 20

  match ip address prefix-list branches

  set tag 1

!

route-map to-provider1 deny 10

  match tag 1

route-map to-provider1 permit 20

  match ip address prefix-list branches

  set tag 2

!

And use those route-maps when redistributing prefixes between the providers (the exact syntax depends on routing protocols used, of course).

So what happens when a site using 10.10.1.0/24 is moved from Provider1 to Provider2?

When you disconnect it from Provider1, the prefix 10.10.1.0/24 stops to be advertised to Provider1 backbone, your DC router stops receiveing it and stops redistributing it to Provider2.

Then you connect it to Provider2, the same prefix starts to be advertised to Provider2 backbone and your DC router starts to redistribute it to Provider1.

And you don't need to reconfigure anything at the moment a single site is being migrated!

I know this is a simple example but I hope it clarifies the principle?

Best regards,

Milan

Review Cisco Networking for a $25 gift card