Re: Routing Path

hs08 · ‎08-08-2023

Hello,

I have topology like below picture, i have 2 location connected over WAN. All Core and Router using EIGRP and previously both WAN have same bandwidth 10Mbps. Now we will upgrade one of WAN so WAN-2 will have bandwidth 50Mbps and we want this WAN-2 for connection from LAN2 with subnet 10.105.0.0/16 only to LAN-1 for some host under subnet 10.103.248.0/24 (let say host 10.103.248.1 and 10.103.248.2)

I believe i can make static route from R2 with command

ip route 10.103.248.1 via WAN-2 gateway

ip route 10.103.248.2 via WAN-2 gateway

My question is :

It's enough to full fill my requirement by adding static route on R2 like above command?
If host under subnet 10.105.0.0/16 initate traffic to host 10.103.248.1 via WAN-2, will host 10.103.248.1 reply in same path?
If host 10.103.248.1 initiate the connection, will this host choose WAN-2 to reach subnet 10.105.0.0/16?

Peter Paluch · ‎08-08-2023

Hello @hs08 ,

What you require goes beyond traditional destination-based routing. With static routes, you influence the path selection based purely on the destination of the traffic, regardless of the traffic source.

If you need to also consider the traffic source when doing the path selection, you need to use Policy Based Routing (PBR).

PBR is a more powerful version of static routing that allows you to define path selection rules based on more criteria than just the traffic destination. For example, you can choose the path based on the packet's source, or L4 protocol and port.

You will need to set up the PBR on both R1 and R2 precisely because you want the traffic path to be symmetric - the same in both directions.

This would be the sample configuration on R1:

ip access-list extended TrafficForWAN2
 permit ip host 10.103.248.1 10.105.0.0 0.0.255.255
 permit ip host 10.103.248.2 10.105.0.0 0.0.255.255
!
route-map PBR permit 10
 match ip address TrafficForWAN2
 set ip next-hop <WAN-2-gateway>
!
interface <LAN>
 ip policy route-map PBR

And this would be the sample configuration on R2:

ip access-list extended TrafficForWAN2
 permit ip 10.105.0.0 0.0.255.255 host 10.103.248.1
 permit ip 10.105.0.0 0.0.255.255 host 10.103.248.2
!
route-map PBR permit 10
 match ip address TrafficForWAN2
 set ip next-hop <WAN-2-gateway>
!
interface <LAN>
 ip policy route-map PBR

This configuration needs to be applied on the LAN-facing interfaces on R1 and R2. Using the ACL, it will select the traffic flows that require the special treatment, and forward them through a specified next hop. All other traffic not selected by the ACL will follow your normal routing table as usual.

Please feel welcome to ask further!

Best regards,
Peter

hs08 · ‎08-09-2023

hello @Peter Paluch

i successfully configure PBR fo R2 and i traceroute from host 10.105.62.100 to 10.103.248.1 and the traffic goes to WAN-2, traceroute to other host (10.103.248.100) the traffic goes to WAN-1. I believe the PRB configuration on R2 is done and succesfull.

Then i try to make PBR on R2 and the PBR is not working, let me explain my mysuspicions :

R2 using ISR4321 and connected to C1 via g0/1/0. Module 1 on R2 is external module using NIM-ES2-4 and this is L2 module. here my config on g0/1/0

interface GigabitEthernet0/1/0
switchport access vlan 303
switchport mode access
end

and here my config on vlan 303

interface Vlan303
ip address 10.103.255.139 255.255.255.0
ip policy route-map PBR_WAN2
end

I just want to know is PBR on R1 not working because i set the route-map on vlan interface?

Peter Paluch · ‎08-09-2023

Hello @hs08 ,

PBR on a SVI (interface Vlan) should be supported and you have applied it correctly. There must be another explanation.

You wrote earlier that you have tested the traceroute from 10.105.62.100 to 10.103.248.1 and this traceroute works as expected. But then you described that the traffic in the other direction which is still following the WAN-1 connection, and have shown me the interface Vlan303 configuration on R1. Checking this interface, this one is in the network 10.103.255.0/24, not 10.103.248.0/24. I believe you wanted to apply the route-map to another SVI that is connected to 10.103.248.0/24.

Can you double-check the correctness of your configuration in this manner? Also please make sure that the ACL referenced by the route-map correctly describes the source-destination pairs for which you need the special routing.

By the way, it is possible to attach the same route-map for PBR to multiple SVIs at the same time so if you need to subject traffic from multiple VLANs to the same PBR rules. That is perfectly okay, just make sure you have applied the route-map to all SVIs where you need to route the incoming traffic based on PBR rules.

Best regards,
Peter

hs08 · ‎08-09-2023

Hi @Peter Paluch

Connection from C1 to R1 using VLAN 303 this is because interface on the R1 is L2, so that why we use VLAN.

IP Addr VLAN 303 on the core is 10.103.255.2

IP Addr VLAN 303 on the R1 is 10.103.255.139

subnet 10.103.248.0/24 is one VLAN on the core.

Here my PBR config on the R1

interface GigabitEthernet0/1/1
description "CONNECTED-TO-NEXUS-01"
switchport access vlan 303
switchport mode access

ip access-list extended ACL_WAN2
permit ip host 10.103.248.1 10.105.0.0 0.0.255.255
permit ip host 10.103.248.2 10.105.0.0 0.0.255.255

route-map PBR_WAN2 permit 10
match ip address ACL_WAN2
set ip next-hop 10.103.242.50

interface Vlan303
ip address 10.103.255.139 255.255.255.0
ip policy route-map PBR_WAN2

but this is not work since all hosts beside 10.103.248.1 and 10.103.248.2 still use WAN-2 and not use WAN-1. Any input?

Peter Paluch · ‎08-09-2023

Hello,

The diagram is helpful, thank you.

Do you run EIGRP over both WAN links? If so, I suspect that EIGRP understands that WAN-2 is faster, and prefers to use that link instead of WAN-1 - so it makes everyone use WAN-2 instead of WAN-1. That's why PBR on R1 doesn't seem to have an effect because the PBR sends some traffic through WAN-2, and EIGRP's routing sends every traffic through WAN-2. So there's no difference.

I wonder what would be the more systematic solution here because we have more ways of doing this. What is exactly that you want to achieve - have only selected hosts communicate over WAN-2 and the rest over WAN-1? If so, I would keep the PBR in place but in addition, I would increase the EIGRP metric of the WAN-2 link so that EIGRP still prefers WAN-1 to WAN-2. To do this, use the "delay" interface parameter on the WAN-2 interfaces on R1 and R2; don't touch the "bandwidth" setting. We would need to set the "delay" high enough so that WAN-2 starts being more costly than WAN-1 to EIGRP.

Would this make sense?

Best regards,
Peter

hs08 · ‎08-09-2023

Hi @Peter Paluch

yes you right R1 and R2 using EIGRP and after i add delay on WAN 2 all traffic beside 10.103.248.1 and 10.103.248.2 now goes to WAN-1. My understanding is when there are traffic not match with access-list in the PBR, the EIGRP or OSPF will make decision to which link the traffic will be pass. Am i right?

Joseph W. Doherty · ‎08-10-2023

@Peter Paluch wrote:

What is exactly that you want to achieve - have only selected hosts communicate over WAN-2 and the rest over WAN-1?

Peter, oops, missed this earlier. So, you too, were also asking about what exactly was to be accomplished.

Giuseppe Larosa · ‎08-09-2023

Hello @hs08 ,

if WAN2 is the link with the highest speed if you have configured

bandwdith 50000

in interface mode for WAN2 facing links on R1, R2

and you have configured

bandwidth 10000

under interfaces to WAN1 on R1, R2

WAN2 is the primary path for EIGRP and it would be used in both directions for all traffic and WAN1 would become a backup path.

So my question is why you want to have only selected IP flows from hosts 10.103.248.1 and 10.103.248.2 to travel on the link with the highest speed ?

I would expect you to try to use PBR to send selected flows on the backup path WAN1 not the opposite.

Note:

if you haven't modified the bandwidth on interfaces to WAN1 , WAN2 they default to the port speeds so EIGRP might be not able to detect the increased speed on WAN2 link.

Hope to help

Giuseppe

hs08 · ‎08-10-2023

Hi..

I have high activity from 10.105.0.0/16 to both servers and i prefer to user WAN-2 with high bandwidth to accommodate traffic.

General traffic to other hosts preferred using WAN-1 so this will not disturb both servers.

Joseph W. Doherty · ‎08-10-2023

@hs08 wrote:

I have high activity from 10.105.0.0/16 to both servers and i prefer to user WAN-2 with high bandwidth to accommodate traffic.

General traffic to other hosts preferred using WAN-1 so this will not disturb both servers.

That's fine, and PBR, alone, can provide that when both links are active.

What PBR, alone, might not help is preclude disturbing both servers' traffic if you lose one of the WAN connections. It also, possibly precludes, getting the most benefit out of all your WAN bandwidth.

Again, though, when both links are active, if the only goal is to protect those servers' traffic, from other non-servers' traffic, PBR is a fine way to accomplish that.

Giuseppe Larosa · ‎08-10-2023

Hello @hs08 ,

thanks your explanation makes the scenario clear.

>> I have high activity from 10.105.0.0/16 to both servers and i prefer to user WAN-2 with high bandwidth to accommodate traffic.

Best Regards

Giuseppe

Joseph W. Doherty · ‎08-09-2023

If you only want to direct specific host traffic to particular interfaces, PBR, is the way to do that. However, I would question why you want to do that.

PBR can be a bit tricky, dealing with failure situations. Further, unless you only direct just one single flow to just one link, other concurrent flows might upset the effectiveness of whatever purpose you're trying to achieve by directing host flows.

For example, consider, "what if" either WAN link path fails?

If you're looking for deterministic performance, PBR alone, or with something "else", might not be the optimal approach for whatever your goals happen to be.

Peter Paluch · ‎08-09-2023

Joe,

Well, if there is anyone to blame for using PBR then it is me because I first suggested it.

I would also surmise that PBR is not that tricky in failure scenarios since if the next hop specified in the route-map is not directly or recursively reachable, you just fall back to the ordinary routing table. If you keep this in mind, you know what you fall back on.

My two cents - I'm not staunchly defending the PBR here, but if the task is to do path selection based on sources as well as destinations, then classic routing is not going to satisfy the need.

Best regards,
Peter

Joseph W. Doherty · ‎08-09-2023

Peter, "blame", "not staunchly defending the PBR", did my reply appear to negate PBR being a valid solution? If my posting, somehow, so implied, such was not my intent, and I apologize!

For what the OP asked, I thought PBR a very suitable answer. However, the OP also gave me the impression, very possibly incorrectly, that they already had a preconceived idea what they wanted to do, just they were uncertain, the best way to do it. I just wondered what their overall goals might be and if they had a preconception of the "right" solution, they might not have even considered other possibilities, or, perhaps, really thought out what their overall goals are (beyond using the additional bandwidth in some special way).

Regarding my remark about PBR fallback being tricky, I recall (???) much like static routing, if you didn't understand all your failure conditions, your PBR, for some failures, might not work as expected unless you've properly configured for those.

Mind you, it's been years since I've really looked at PBR, so my memory, or even my understanding could be (very) faulty, and/or, that PBR might have improved in the last couple of decades.

But some of the issues I (vaguely) recall included: possible reduced routing performance without ip routing-cache policy (CEF negates need for this too?); failures where route-map entry matches, but it's a black-hole (i.e. link up, but far side next-hop IP non-responsive - possibly handled by PBR route-map statement set next-hop verify-availability - but possibly not supported on all PBR implementations?); you mentioned PBR recursive next-hop, but I see that came out starting with 12.0(28)S and 12.3(14)T, but as above, my PBR usage studies did predate those releases (and I did not keep current with PBR, because, in my experience, I found trying to manage some kind of SLA is better via QoS (my sweetheart - laugh) than trying to manage what flows go to what links.

Completely aside from PBR, I also wondered whether OP had considered using EIGRP UCMP to proportionally use the two links.

Laugh, I'm not the only one, it seems, wondering a bit about what the OP is really trying to accomplish. @Giuseppe Larosa's:

"So my question is why you want to have only selected IP flows from hosts 10.103.248.1 and 10.103.248.2 to travel on the link with the highest speed ?

I would expect you to try to use PBR to send selected flows on the backup path WAN1 not the opposite."

See, again, whether PBR failure mode, is "tricky" or not, what's the significance of a link failure if we're trying to give some traffic different treatment? Without QoS, unless you intentionally drop the less preferred traffic, they are now going to contend for bandwidth on the remaining link. (BTW, I didn't even mention/suggest QoS, in my prior post, because, need to understand OP's goals. If they want to do exactly as they posted, again, sure why not use PBR? In fact, depending on what their goals might be, they might need PBR and QoS or, perhaps, something else. [I'm also rather fond of PfR capabilities.])