cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
234
Views
5
Helpful
2
Replies

Policy Based Routing for staged Migration

BlueyVIII
Level 1
Level 1

I have a site with around 100 VLAN's and layer 3 SVI's (running on a 6509E VSS) that I need to migrate a new WAN provider. At the moment the default route of the switch is the legacy WAN Providers  routers address (192.168.254.1) The new WAN providers IP Address is 192.168.254.2.

I've been asked to minimise disruption to the site and migrate on a per VLAN basis and the only way I can think of to do this is to use policy based routing to set the next hop address.  On it's own this would be straight forward enough, however, I also need to maintain local routing on site to ensure local traffic remains routed on the local 6509E and not routed to the WAN providers router. This is because there is a data centre on site (in the 192.168.0.0/24 and 192.168.1.0/24 subnets) and we don't want the WAN Providers router to become a bottleneck to the data centre.

Unfortunately other parts of the 192.168.0.0 address space is used on other sites throughout the WAN so summarising the subnets is not possible.

I've attached the ACL and Policy config I'm proposing. Essentially the ACL 'denies' packets with a destination to an on-site subnet so packets remaining on-site won't apply to the policy and therefore will be subject to normal routing. Packets with a source address of an on-site subnet are then 'permitted' so that the policy applies a match and sets the next hop address to the new WAN providers router (hope that makes sense?)

My strategy is to add the ACL and Policy config and then apply the Policy to each SVI on a case-by-case basis so we can control the migration in a phased manner. Once the migration is complete I plan to change the default route of the switch to the new WAN providers router (192.168.254.2) and then remove the ACL and Policy config.

I've attached the config I'm planning but am unsure of a few things :-

1. Is there a better way to do this. I'm conscious that the access-list is long and complex

2. Will processing the access-list & Policy have a noticeable affect on the switch performance, routing performance, traffic flows, etc?

Any help gratefully received :)

2 Replies 2

chrihussey
VIP Alumni
VIP Alumni

Based on what you need to accomplish, I think the use of PBR is the way to go. It's unfortunate that your IP subnet allocation makes this so difficult, but that is not in your control.

The access list is long and you may be able to cut it in half by simply using "permit ip 192.168.0.0 0.0.255.255 any" instead of listing all the 192.168.x.x networks again after the denys. After all, aside from the 195.107.238.0/24, all the packets sourced on the other interfaces will be coming from from that range. Hope that makes sense.

I really can't comment with facts about performance, but I personally think the hit would be negligible and you should be OK.  Just my thoughts.

That's a really good point, thanks for your help :)

As all of the SVI's will be addressed 192.168.x.x I could summarise the permit statement on the ACL as I'll only be applying it on an SVI by SVI basis as the migration progresses. I can't see any reason to specifically list the source subnets...

I guess that will reduce the impact on performance too...Hopefully someone will be able to advise the performance overhead this policy is likely to have..

Getting Started

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: