EIGRP routing data TCP to the right, UDP to the left

[simoesmarco8626982]

Hi all,

Hope to find everyone well

I was asked to do the following by a consultant of my costumer but I don't know if that is even possible. Basically I have eigrp applied and it has its routes elected and he wants me to send TCP traffic let's say to the left and UDP traffic to the right...

Is this even possible??

I can do uneven load balancing with eigrp and that's the only way I'm seeing of sending traffic both ways of the ring, but discerning, this traffic goes left and this traffic goes right being routed with eigrp... 

Any help is much appreciated

Thank you

[Joseph W. Doherty]

PBR

[simoesmarco8626982]

Thank you Joseph, was totally unaware of this. This is not even mentioned in CCNA.

I have one doubt tough, with this I specifically tell the path to follow, if that path fails the system automatically sends the data to another path? 

Thank you

[Joseph W. Doherty]

"I have one doubt tough, with this I specifically tell the path to follow, if that path fails the system automatically sends the data to another path? "

Not sure if still true with later IOS versions, but recall (?) with PBR you had to "configure" how to direct traffic in failure situations.

[Giuseppe Larosa · Accepted solution]

Hello @simoesmarco8626982 ,

in PBR if the specfied next-hop fails traffic will be routed in the standard way using destination based routing and using any alternate path available.

So the key point to avoid traffic black holing is to that the device performing PBR has to be able to detect next-hop failure.

You may need to add set ip next-hop verify-availability in the route-map to be sure in case you are using SVIs and not routed links in your ring topology.

Be also aware that  not all platforms support verify availability and that there are two different implementations of it:

the older one is simply as stated above.

The more modern implementation can use IP SLA and object tracking like it is done with static routes to check the next--hop reachability

Hope to help

Giuseppe

[Georg Pauwen · Accepted solution]

Hello,

I was just testing this in my lab when Joseph already provided the answer. Either way, since I have it, I might as well post the working PBR config I have come up with:

hostname R1
!
ip dhcp excluded-address 192.168.1.1
!
ip dhcp pool LAN
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 8.8.8.8
!
interface GigabitEthernet0/0
description ISP_1_WAN
ip address 1.1.1.1 255.255.255.252
!
interface GigabitEthernet0/1
description ISP_2_WAN
ip address 2.2.2.1 255.255.255.252
!
interface GigabitEthernet0/2
description LAN
ip address 192.168.1.1 255.255.255.0
ip policy route-map TCP_UDP_RM
!
router eigrp 1
network 0.0.0.0
!
route-map TCP_UDP_RM permit 10
match ip address 101
set ip next-hop 1.1.1.2
!
route-map TCP_UDP_RM permit 20
match ip address 102
set ip next-hop 2.2.2.2
!
access-list 101 permit tcp any any
access-list 102 permit udp any any

[paul driver]

Hello

Just like to point out out this PBR will in most probably incurr asymmetric routing for your return traffic 

[Georg Pauwen]

@paul driver Not if you do it on both sides I guess (that was the idea)...

[simoesmarco8626982]

Thank you Georg!! 

This is extremely helpfull! I will see if I implement this

Just a doubt, if one side drops the connection, eigrp will grab the data and send it the other way correct?

Also, in the expertise of everyone, the following makes sense? I have a consultant requesting this for a site where I have a ring connection of 7 independent sites where 6 will send TCP and UDP data to the 7th site (the receiving point). Does it make sense to put all 6 independent sites to send UDP only clockwise and then having the TCP data going counterclockwise for this type of network? The prevalent data will be UDP but from time to time TCP will be used as well. Honestly, I don't like this idea, since I'm going to have traffic having to pass 6 hops and overloading some links more when I could have it going straight and passing through fewer hops. Do you guys agree with this? What do you think?

Thank you

[paul driver · Accepted solution]

Hello

---

@simoesmarco8626982 wrote:

This is extremely helpfull! I will see if I implement this

Just a doubt, if one side drops the connection, eigrp will grab the data and send it the other way correct?

---

No it wont it will blockhole traffic, you could add a secondary next hop other then the default route in the routing table but again you need to verify  reachability with set ip next-hop verify-availability command in conjunction with IPSLA tracking for it to failover

example:

ip sla 1
icmp-echo xxxx ( tracked destination)
ip sla schedule 1 life forever start-time now

track 10 sla 1 reachability

route-map pbr 
match ip address xx
set ip next-hop verify-availability x.x.x.1 track 10

[Elliot Dierksen]

---

route-map pbr 
match ip address xx
set ip next-hop verify-availability x.x.x.1 track 10

---

When did the "next-hop verify-availability" option come in? I wasn't aware of that. I guess I should also admit that I have never been a big fan of PBR, but that option perhaps makes it a bit more palatable.

[paul driver]

Hello

my understanding you can utilise this option 2 ways

using object tracking and IPSLA  -(as shown) or 

just rely on the connected nexthop being able to support CDP as such you would just specify the next-hop but no ipsla 

[simoesmarco8626982]

Thank you all!

If anyone knows by head, does the Catalyst 9300 with Security Essentials support PBR with next-hop verify-availability?

Thank you

[marce1000]

 - I don't think  so , check  attachment obtained  from the feature navigator : https://cfnng.cisco.com/

  M.

[simoesmarco8626982]

Só only on the ISR and ASR and on those specific models. 

Thank you mace1000