Policy Based Routing - Doubt

[simoesmarco8626982]

hi all,

I've done some config with PBR and prepared the config ready to be applied to several L3 Switches 9300 and applied the next-hop verify-availability and sla but I have one doubt though. Having in account the image attached, I have the TCP traffic going clockwise and the UDP going anticlockwise, this is all good but if one link stops working, OSPF will take over and send the traffic the other way and if I have PBR applied on the other switches interfaces that link switch to switch (like I have), the traffic will enter and the switch will see that it's TCP or UDP and depending of the PBR will forward the traffic the same way where the traffic came from since in it's PBR it's saying that UDP or TCP has to go that way. Am I correct?

For what I understand if I remove the PBR from the links linking the switches, they won't follow the PBR but the switches will do PBR to all the other interfaces (configured like this), but if I don't apply PBR to the interface that links the switches, one switch will send the data to the other in accordance to the PBR but when the traffic enters the next switch because no PBR is present in the link between switches, OSPF will take over and depending on how the routing table is it can forward the traffic again to where it came from. 

Am I correct in assuming all of this? What's the best way to deal/configure the switches to deal with this please?

This is an example of the configuration I have applied to the switches:

ip sla 1
icmp-echo 10.6.254.1
frequency 10
!
ip sla schedule 1 life forever start-time now
!
ip sla 2
icmp-echo 10.1.254.2
frequency 10
!
ip sla schedule 2 life forever start-time now
!
track 1 ip sla 1 reachability
track 2 ip sla 2 reachability
!
route-map TCP_UDP_RM permit 10
match ip address 101
set ip next-hop verify-availability 10.6.254.1 track 1
!
route-map TCP_UDP_RM permit 20
match ip address 100
set ip next-hop verify-availability 10.1.254.2 track 2
!
ip access-list extended 100
10 permit udp any any
!
ip access-list extended 101
10 permit tcp any any

Thank you

[balaji.bandi]

as per the diagram not sure PBR is the right direction for you.

you looking to apply PBR on every switch or device ?

[simoesmarco8626982]

Hi Balaji,

yes that's correct, PBR in every 9300 Switch. The 9300 will be the core of the network and the intention is to put the traffic TCP to flow in one direction and UDP to flow in another but if one of the links fail the traffic needs to be re routed by OSPF.

What would you please recommend?

Thank you

[balaji.bandi]

as per the diagram the switches are daisy chained loop, if the loop breaks there is only one path in the network right ?

[simoesmarco8626982]

Yes that's correct, if it breaks all the traffic will have to flow one way.

Example in the image attached 

Thank you

[paul driver]

Hello

what you are asking isn’t optimal- you need to think about traffic originating from each device So even if all those devices are performing routing then it makes no sense for traffic originating from sw/rtr 2 via route sw/rtr  3 -4-5-etc to reach sw/rtr1  also you would incur blacking holing if you using PBR on each device as it would only take one device to fail and the other would have now way of being notified about the failure and continue to policy route the wrong way.

if you are set on doing this path manipulation at L3 then using a routing process would be more  appropriate. 

And if they are not all routing then PBR isn’t even applicable as then you would need to manipulate via L2 spanning-tree 

[balaji.bandi]

as mentioned earlier, deploying PBR in each device not a good solution here.. never seen this kind of requirement, we do see traffic engineering in the path.

[simoesmarco8626982]

Thank you Paul and Balaji!

This had been a requirement from the costumer/consultant for me to use PBR specifically, but I wasn't seeing a way to deliver this without the traffic falling into a "black hole"... Besides what I told him I used your commentaries as well as evidence to present to the technical consultant and to prove that this wasn't possible and he in the end agreed but even still he his going to try to put PBR to work and to do this somehow...

Paul if I might ask what kind of manipulation and routing process you have in mind and how can I achieve this please? Is it possible to have a brief explanation? Now I'm curious and for me to learn as well

Thank you all

[Joseph W. Doherty]

@simoesmarco8626982 just out of curiosity, do you know why the requirement for UDP and TCP to take different paths?

Reason I ask, I've sometimes seen this requirement to "guarantee" bandwidth for a particular class of traffic (which often fails when one path is broken and all traffic must go across the remaining path).

If such a requirement, if might be better addressed using QoS features to "guarantee" bandwidth (which might be less complex than PBR, and also might do better in a failure of one path situation).

[simoesmarco8626982]

Hi Joseph,

Basically, the traffic in this network will be mainly exclusively UDP video traffic, and the objective would be to send all the video traffic one way while freeing the TCP traffic requests, like file transfers to backup footage, etc to be able to have the full speed of the link without sharing it with the UDP video traffic. This was the reason behind PBR 

I have applied QoS but the consultant was not happy with only that and wanted a system like the above to have always full speed

[Joseph W. Doherty]

". . . to be able to have the full speed of the link without sharing it with the UDP video traffic. This was the reason behind PBR"

Well that's certainly true.  However, you still have the competition issue if one path fails and with two paths active, you might have more overall bandwidth available for both traffic types.  Regardless, using QoS to guarantee bandwidth allowance if one path fails, might still be worth considering.

Also, if using both paths, ideally something like Cisco's PfR can dynamically load balance and also take into consideration QoS needs, but your equipment might not support that feature.

[Richard Burts]

I agree with other responses that this requirement results in a sub-optimal implementation. And I hope that the consultant can be convinced that there are better options. But the original question asks a valid question about implementing PBR when there are multiple routers involved. And the answer is that if you are implementing PBR to achieve some result and there are multiple L3 devices along the path then PBR must be implemented on EVERY one of the devices. (and should be implemented not only on the device to device interfaces, but should be implemented on the interfaces where traffic enters the network.)

[simoesmarco8626982]

Hi Richard, he was convinced but he told me he would do labs to try to put this to work somehow, he won't be able to as we know but he needs to reach that conclusion himself. 

I had applied PBR in every single interface and router where traffic was entering and It took me some time to check everything and program everything accordingly. But after programming, I started looking and thinking that this would never work as intended in case a link fails (that's when I asked the question in the forum). In the end all my work and time spent went down the drain but well learned something out of it 

[Richard Burts]

Glad that you can look at this from the perspective that it turned out to be a good learning experience. I believe that frequently I learn more when I work on something that does not work than I do from working on something that does work. So when something does not work it is not necessarily a bad thing.

[simoesmarco8626982]

Thank you Joseph, I'm going to have a look at PfR, not for this implementation since the equipment and licenses don't support it but for some time in the future.