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

PFRv3: Traffic classes don't preempt back to active routes (by EIGRP metric)

Nadav
Level 7
Level 7

Hi everyone,

 

I have a dual HUB PFRv3 setup with a number of spokes. The WAN transport protocol is EIGRP. The routers are ASR-1001x's with the latest code (16.6.3).

 

Master Hub is Hub A (H1), Transit site is Hub B (H2). Each have two BRs.

There are two spoke sites, each with two BRs: Spoke A (S1) and Spoke B (S2).

Each are connected to the dual hubs.

image.png

 

EIGRP metric-wise, H1 is the preferred path for all traffic from the spokes. It is only when H1 has no active connections to the spoke does a spoke communicate via H2. This is done via changing the delays of the tunnels and cross interfaces between BRs at the Hubs and Spokes.

 

When traffic from S1 is destined to S2 when both H1 and H2 are available, it flows like this:

 

S1 -> H1 -> S2

 

During failover testing I disconnected S1 from H1. The traffic then flows like this:

S1 -> H2 -> S2

 

So far so good. However, when I return the connection between S1 and H1 the traffic classes continue to use H2 as their datapath.

 

It is only when I clear the traffic-classes at S1 that the TC's learn to use H1 as their Hub. 

 

I checked the routing table including the PFR overrides, H1 is recognized as the preferred route. However, the traffic-classes never preempt back from H2 to H1.

 

Any ideas how this can be resolved, even if using a timer?

 

Thanks!

 

 

 

 

2 Replies 2

Renan Abreu
Cisco Employee
Cisco Employee
Can you show the "traffic-classes" for the flow you are taking about? If you can also send your "domain" configuration it would make it easier to understand (show run | sec domain) With iWAN, your delay configuration on EIGRP may not mean much, the EIGRP routes are there more to make sure you have a parent route on the BR, so it will be able to generate probes on the link. They way your traffic will be handled is based on the policies you have defined, so let's say you have it configured for MPLS link and then the INET link. You probably have INET for both H1 and H2, so even when EIGRP shows a better metric to INET on H1 compared to MPLS to H2, iWAN will route that traffic to H2. There are multiple ways to configure iWAN so I not going to comment much about them here. I think first we need to understand exactly how it is working now and how you want it to work. We can then think of configuring different Path names or Path-IDs on H1/H2.

Hi,

 

Sorry for the delayed reply. I'll examine this issue shortly, some other issues are taking up my time at the moment.

 

I was wondering, do you have any idea if Spoke to Spoke PFRv3 is supported? I haven't found any documentation to suggest that PFRv3 works as designed between spoke to spoke, only spoke to hub or transit. 

Review Cisco Networking for a $25 gift card