cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6312
Views
0
Helpful
3
Replies

PFRv3 DOMAIN-5-TCA System Message

HI All,

I'm working on a PFRv3 / IWAN implementation.  It is currently in a lab state.  Four sites and each site has dual routers.   HUB-R1 is MC / BR (Tunnel /DMVPN 100), HUB-R2 is BR (Tunnel/DMVPN 200).  Each of the MC routers on each site all log the following message.  They all reference the second Tunnel 200.  The same message will be listed for each of the source site ID in the config and the destination is always the  hub master IP.

*Mar  7 17:17:15.148: %DOMAIN-5-TCA: UNREACHABLE Received. Details: Instance id=0: VRF=default: Source Site ID=<BRANCH Master IP>: Destination Site ID=<HUB MASTER IP>: TCA-ID=599: TCA-Origin=<HUB Border IP>(R): Exit=[CHAN-ID=172, BR-IP=<BRANCH Border IP>, DSCP=4[4], Interface=Tunnel200, Path=MPLS-2[label=0:0 | 0:0 [0x0]]

I'm not sure on how to read that message.  Is it a normal expected message or is there some issue that I am not seeing.

All of the 'sh domain iwan master status, border status, and many of the other verification cli report everything as good.

 

Thanks in advance

1 Accepted Solution

Accepted Solutions

Hello.

The message (as far as logged on Hub), says, that outage was detected on the path between Hub and branch.

It may come from different causes:

  • unsupported design (routing flaw or QoS remarking on WAN interface or backdoor link);
  • packet loss on Tunnel200 between Hub and the branches;
  • poor Qos policy  (if issue is for DSCP 4 only);

PS: if you have a contract for any of the boxes involved into PFR domain, please open TAC case (between 8:00 AM and 4:00 PM UTC+1) and I'll help you, as we need much more outputs (like network diagram, running configuration and "show domain ... master tech" and "... border tech".

PS2: for unsupported designs - please make sure you are following latest CVD.

PS3: very basic thing you could do - check in which direction the issue is seen - collect "show domain ... border channel" and see is it "RX" or "Tx" unreachable (you masked the logs and no network topology, so I may just guess).

View solution in original post

3 Replies 3

Hello.

The message (as far as logged on Hub), says, that outage was detected on the path between Hub and branch.

It may come from different causes:

  • unsupported design (routing flaw or QoS remarking on WAN interface or backdoor link);
  • packet loss on Tunnel200 between Hub and the branches;
  • poor Qos policy  (if issue is for DSCP 4 only);

PS: if you have a contract for any of the boxes involved into PFR domain, please open TAC case (between 8:00 AM and 4:00 PM UTC+1) and I'll help you, as we need much more outputs (like network diagram, running configuration and "show domain ... master tech" and "... border tech".

PS2: for unsupported designs - please make sure you are following latest CVD.

PS3: very basic thing you could do - check in which direction the issue is seen - collect "show domain ... border channel" and see is it "RX" or "Tx" unreachable (you masked the logs and no network topology, so I may just guess).

The Devil is in the details.  Your reply helped me focus and discover the root cause, so thank you very much.  I was only seeing RX in the Initial State.  TX was Reachable.  Not sure how that added up to me checking the routing config but it did.  One of those 'you look are the config 100 times but still seem to miss what you missed'  I have been through the CVD and many other references but you still miss things.  This is my first real exposure to PfR (any version) and from what I have heard v3 is far easier the previous versions.  

The root cause was that I missed a route-map on the second BR that tags all routes as the loopback / routerID IP.  

router eigrp IWAN
!
address-family ipv4 unicast autonomous-system 1001
!
af-interface Tunnel200
summary-address 10.16.40.0 255.255.252.0
summary-address 10.18.0.0 255.255.252.0
hello-interval 20
hold-time 60
no next-hop-self
no split-horizon
exit-af-interface
!
af-interface GigabitEthernet0/0/0.3
passive-interface
exit-af-interface
!
af-interface GigabitEthernet0/0/0.4
passive-interface
exit-af-interface
!
af-interface GigabitEthernet0/0/0.5
passive-interface
exit-af-interface
!
topology base

##### missing corresponding route-map for distribution-list below  ####

distribute-list route-map SET-TAG-ALL out Tunnel200

distribute-list route-map BLOCK-DMVPN1 in GigabitEthernet0/0/0.2
distribute-list route-map SET-TAG-DMVPN2 out GigabitEthernet0/0/0.2
exit-af-topology
network 10.18.0.0 0.0.0.255
network 10.18.1.0 0.0.0.255
network 10.18.2.0 0.0.0.255
network 10.18.3.0 0.0.0.255
network 10.31.126.0 0.0.0.255
network 10.31.127.2 0.0.0.0
eigrp router-id 10.31.127.2
exit-address-family

route-map BLOCK-DMVPN1 deny 10
match tag 10.31.127.1
!
route-map BLOCK-DMVPN1 permit 20
!

######   COMPLETELY MISSING route-map below  #####

route-map SET-TAG-ALL permit 10
description tag all routes advertised through the tunnel
set tag 10.31.127.2
!
route-map LEAK-DMVPN2 permit 10
match ip address prefix-list LOCAL-ROUTES
set tag 10.31.127.2
!
route-map SET-TAG-DMVPN2 permit 10
description tag all routes advertised through the tunnel
match ip route-source DMVPN2-SPOKES
set tag 10.31.127.2
!
route-map SET-TAG-DMVPN2 permit 20
description advertise all other routes with no tag

Glad to hear, that it's resolved now.

My congratulations.

Review Cisco Networking for a $25 gift card