cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2752
Views
20
Helpful
13
Replies

ASR-9010 - RSP-4G - XR.4.3.4 - HSRP limitations

DIEGO ZORRILLA
Level 1
Level 1

I´m unable to foward traffic to virtual IP (HSRP) when Router A is the Active. if Router B is the Active fowarding is ok.

HSRP negotiation (Active vs Standby) is working propertly, on both routers, A and B, see each other in the correct state, if raise priority on one side the other one change to Standby, and so on......

But traffic to Virtual IP when Router A is the active is not working.

 

show hsrp trace shows the next output

 

Feb 13 18:11:06.777 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  MAC addresses clear complete (1 success, 0 fail): No error
Feb 13 18:11:08.789 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  MAC addresses set complete (0 success, 1 fail): 'interface attributes library' detected the 'warning' condition 'At least one attribute operation failed. Check retcode array'

 

Feb 13 18:10:44.741 hsrp_unbulk 0/RSP0/CPU0 t1      VERIFY PRIORITY succeeded
Feb 13 18:10:44.741 hsrp_unbulk 0/RSP0/CPU0 t1      VERIFY PREEMPT: AF IPv4, Interface TenGigE0_0_0_0.567, group 567, delay 0 (remove)
Feb 13 18:10:44.741 hsrp_unbulk 0/RSP0/CPU0 t1      VERIFY PREEMPT succeeded
Feb 13 18:10:44.745 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PRIORITY: AF IPv4, Interface TenGigE0_0_0_0.567, group 567, priority 0 (remove)
Feb 13 18:10:44.745 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PRIORITY succeeded
Feb 13 18:10:44.745 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PREEMPT: AF IPv4, Interface TenGigE0_0_0_0.567, group 567, delay 0 (remove)
Feb 13 18:10:44.745 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PREEMPT succeeded
Feb 13 18:10:44.746 hsrp_bulked 0/RSP0/CPU0 t1  Send FO start message of size 1 to node 0x801 succeeded
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      VERIFY PRIMARY: Interface TenGigE0_0_0_0.567, group 567, addr 0.0.0.0 (learn) (remove)
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      VERIFY PRIMARY succeeded
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Active: (Ev h) Hello message from higher priority Active
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Session State Active        -> Speak
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1  FHRP:    Successfully queued ARP Update for 192.168.152.97 on TenGigE0/0/0/0.567*
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1  FHRP:    Queued RIB remove for 192.168.152.97 on TenGigE0/0/0/0.567*
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1  FHRP:    Successfully queued MAC remove for TenGigE0/0/0/0*, 0000.0c9f.f237
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      IPv4#TenGigE0_0_0_0.567#0x237Forwarder State Active  -> Speak
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item ipv4/group/TenGigE0_0_0_0.567,567 to the sysdb state change notification queue
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      (EDM): (Filter): IP mapping notification on TenGigE0/0/0/0.567*, deleting
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item ip_mapping/d40,c0a89862,567 to the sysdb ICMP redirects notification queue
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      (EDM): (Filter): VMAC mapping notification on TenGigE0/0/0/0.567*, deleting
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item dest_macs/d40,00000c9ff237 to the sysdb ICMP redirects notification queue
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Speak: (Ac H) Sending resign message
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      (EDM): (Filter): IP mapping notification on TenGigE0/0/0/0.567*, deleting
Feb 13 18:10:44.751 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item ip_mapping/d40,c0a89863,0 to the sysdb ICMP redirects notification queue
Feb 13 18:10:44.753 hsrp_bulked 0/RSP0/CPU0 t1  Send FO start message of size 2 to node 0x801 succeeded
Feb 13 18:10:44.754 hsrp_bulked 0/RSP0/CPU0 t1  Send FO send message of size 1 to node 0x801 succeeded
Feb 13 18:10:44.755 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Successful ARP update of size 1 (1 add, 0 remove, 0 grat ARP)
Feb 13 18:10:44.755 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Clearing Ucast MAC attribute for 1 interfaces
Feb 13 18:10:44.757 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  MAC addresses clear complete (1 success, 0 fail): No error
Feb 13 18:10:44.757 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Updating RIB (table 0xe0000034, proto 0x4): Adding 0 routes, removing 1 routes
Feb 13 18:10:44.758 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:    (batch_buffer_complete returned 1 - success)
Feb 13 18:10:44.758 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Sending batch to RIB
Feb 13 18:10:44.758 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:    (operation returned 6 - success)
Feb 13 18:10:44.758 hsrp_bulked 0/RSP0/CPU0 t1  Updating 1 sysdb state change notifications
Feb 13 18:10:44.763 hsrp_bulked 0/RSP0/CPU0 t1  Updating 3 sysdb ICMP redirect notifications
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PRIMARY: Interface TenGigE0_0_0_0.567, group 567, addr 0.0.0.0 (learn) (remove)
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Speak: (Ev b) HSRP disabled
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Speak: (Ac C) Stopping Active timer
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Speak: (Ac D) Stopping Standby timer
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Session State Speak         -> Init
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1  FHRP:    Successfully queued ARP Update for 192.168.152.97 on TenGigE0/0/0/0.567*
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1  FHRP:    Successfully queued MAC remove for TenGigE0/0/0/0*, 0000.0c9f.f237
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item to the IPv4 socket unjoin queue for VRF 0x60000025 on interface TenGigE0/0/0/0.567*
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      Add IPv4 interface TenGigE0_0_0_0.567 to the IP-ARM unregister queue succeeded
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      (EDM): (Filter): Interface config notification on TenGigE0/0/0/0.567*, deleting
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item if_config/d40 to the sysdb ICMP redirects notification queue
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      Add IPv6 interface TenGigE0_0_0_0.567 to the IP-ARM unregister queue succeeded
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1  Queued unregistration for link-local address updates for TenGigE0/0/0/0.567*
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      Add interface TenGigE0/0/0/0.567* to the IM mac unregister queue succeeded
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      Removed reference for VRF, vrf_id 0x60000025 refcount 1
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      Add IPv4 interface TenGigE0_0_0_0.567 to the IM state unregister queue succeeded
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      Add IPv6 interface TenGigE0_0_0_0.567 to the IM state unregister queue succeeded
Feb 13 18:10:44.765 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PRIMARY succeeded
Feb 13 18:10:44.766 hsrp_bulked 0/RSP0/CPU0 t1  IP-ARM unregister finished with 1 successes and 0 failures
Feb 13 18:10:44.766 hsrp_bulked 0/RSP0/CPU0 t1  IP-ARM unregister finished with 1 successes and 0 failures
Feb 13 18:10:44.766 hsrp_bulked 0/RSP0/CPU0 t1  Batch of 1 LAS unregister operations complete (0 success / 1 fail) - first failure Invalid argument
Feb 13 18:10:44.767 hsrp_bulked 0/RSP0/CPU0 t1  Send FO send message of size 1 to node 0x801 succeeded
Feb 13 18:10:44.769 hsrp_bulked 0/RSP0/CPU0 t1  Send FO stop message of size 2 to node 0x801 succeeded
Feb 13 18:10:44.770 hsrp_bulked 0/RSP0/CPU0 t1  Send FO delete message of size 2 to node 0x801 succeeded
Feb 13 18:10:44.770 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Successful ARP update of size 1 (0 add, 1 remove, 0 grat ARP)
Feb 13 18:10:44.770 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Clearing Ucast MAC attribute for 1 interfaces
Feb 13 18:10:44.772 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  MAC addresses clear complete (1 success, 0 fail): No error
Feb 13 18:10:44.773 hsrp_bulked 0/RSP0/CPU0 t1  IM state unregister finished with 2 successes and 0 failures
Feb 13 18:10:44.773 hsrp_bulked 0/RSP0/CPU0 t1  IM mac unregister finished with 1 successes and 0 failures
Feb 13 18:10:44.773 hsrp_bulked 0/RSP0/CPU0 t1  Updating 1 sysdb ICMP redirect notifications
Feb 13 18:10:44.775 hsrp_bulked 0/RSP0/CPU0 t1  socket unjoin completed with 0 failures and 2 successes
Feb 13 18:11:01.915 hsrp_unbulk 0/RSP0/CPU0 t1      VERIFY PRIMARY: Interface TenGigE0_0_0_0.567, group 567, addr 192.168.152.97  (add)
Feb 13 18:11:01.915 hsrp_unbulk 0/RSP0/CPU0 t1      VERIFY PRIMARY succeeded
Feb 13 18:11:01.921 hsrp_bulked 0/RSP0/CPU0 t1  IM state register finished with 2 successes and 0 failures
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PRIMARY: Interface TenGigE0_0_0_0.567, group 567, addr 192.168.152.97  (add)
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1      Add IPv4 interface TenGigE0_0_0_0.567 to the IM state register queue succeeded
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1      Add IPv6 interface TenGigE0_0_0_0.567 to the IM state register queue succeeded
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1      Unknown#0x237Add primary VIP 192.168.152.97 (Down)
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PRIMARY succeeded
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1      Attribute notification received for interface TenGigE0/0/0/0.567*
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1      Add interface TenGigE0/0/0/0.567* to the IM mac register queue succeeded
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1      Add IPv4 interface TenGigE0_0_0_0.567 to the IP-ARM register queue succeeded
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1      (EDM): (Filter): Interface config notification on TenGigE0/0/0/0.567*, filter on
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item if_config/d40 to the sysdb ICMP redirects notification queue
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1      IPv4#TenGigE0/0/0/0.567*#0x1000interface state notification (up) (old state unknown)
Feb 13 18:11:01.921 hsrp_unbulk 0/RSP0/CPU0 t1    FHRP TRK:  IM state notification for TenGigE0_0_0_0.567 (IPv4) - Up
Feb 13 18:11:01.922 hsrp_bulked 0/RSP0/CPU0 t1  IP-ARM register finished with 1 successes and 0 failures
Feb 13 18:11:01.922 hsrp_unbulk 0/RSP0/CPU0 t1      Received 1 interface IP address updates (scan)
Feb 13 18:11:01.922 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x1000Updating IP address info: 192.168.152.98/29 (add/change) VRF 0x60000025, tbl 0xe0000034
Feb 13 18:11:01.922 hsrp_unbulk 0/RSP0/CPU0 t1      Added reference to VRF, vrf_id 0x60000025 refcount 2
Feb 13 18:11:01.925 hsrp_bulked 0/RSP0/CPU0 t1  Send FO create message of size 1 to node 0x801 succeeded
Feb 13 18:11:01.925 hsrp_bulked 0/RSP0/CPU0 t1  IM mac register finished with 1 successes and 0 failures
Feb 13 18:11:01.925 hsrp_bulked 0/RSP0/CPU0 t1  Updating 1 sysdb ICMP redirect notifications
Feb 13 18:11:01.933 hsrp_unbulk 0/RSP0/CPU0 t1      Attribute notification received for interface TenGigE0/0/0/0.567*
Feb 13 18:11:01.933 hsrp_unbulk 0/RSP0/CPU0 t1      Received MAC change notification for interface TenGigE0/0/0/0.567*:new mac 6c9c.ed6f.c922 , old mac 0000.0000.0000
Feb 13 18:11:01.933 hsrp_unbulk 0/RSP0/CPU0 t1      Received 3rd party bulk end notification
Feb 13 18:11:01.936 hsrp_unbulk 0/RSP0/CPU0 t1      VERIFY PREEMPT: AF IPv4, Interface TenGigE0_0_0_0.567, group 567, delay 0 (add)
Feb 13 18:11:01.936 hsrp_unbulk 0/RSP0/CPU0 t1      VERIFY PREEMPT succeeded
Feb 13 18:11:01.936 hsrp_unbulk 0/RSP0/CPU0 t1      VERIFY PRIORITY: AF IPv4, Interface TenGigE0_0_0_0.567, group 567, priority 110 (add)
Feb 13 18:11:01.936 hsrp_unbulk 0/RSP0/CPU0 t1      VERIFY PRIORITY succeeded
Feb 13 18:11:01.941 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PREEMPT: AF IPv4, Interface TenGigE0_0_0_0.567, group 567, delay 0 (add)
Feb 13 18:11:01.941 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PREEMPT succeeded
Feb 13 18:11:01.942 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PRIORITY: AF IPv4, Interface TenGigE0_0_0_0.567, group 567, priority 110 (add)
Feb 13 18:11:01.942 hsrp_unbulk 0/RSP0/CPU0 t1      APPLY PRIORITY succeeded
Feb 13 18:11:06.772 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item to the IPv4 socket join queue for VRF 0x60000025 on interface TenGigE0/0/0/0.567*
Feb 13 18:11:06.772 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Init: (Ev a) HSRP enabled
Feb 13 18:11:06.772 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Session State Init  -> Listen
Feb 13 18:11:06.772 hsrp_unbulk 0/RSP0/CPU0 t1  FHRP:    Successfully queued ARP Update for 192.168.152.97 on TenGigE0/0/0/0.567*
Feb 13 18:11:06.772 hsrp_unbulk 0/RSP0/CPU0 t1  FHRP:    Successfully queued MAC remove for TenGigE0/0/0/0*, 0000.0c9f.f237
Feb 13 18:11:06.773 hsrp_bulked 0/RSP0/CPU0 t1  Send FO create message of size 1 to node 0x801 succeeded
Feb 13 18:11:06.774 hsrp_bulked 0/RSP0/CPU0 t1  Send FO start message of size 1 to node 0x801 succeeded
Feb 13 18:11:06.775 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Successful ARP update of size 1 (1 add, 0 remove, 0 grat ARP)
Feb 13 18:11:06.775 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Clearing Ucast MAC attribute for 1 interfaces
Feb 13 18:11:06.777 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  MAC addresses clear complete (1 success, 0 fail): No error
Feb 13 18:11:06.778 hsrp_bulked 0/RSP0/CPU0 t1  socket join completed with 0 failures and 2 successes
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Preempt delay not configured - preemption allowed
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Listen: (Ev h) Hello message from lower priority Active
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Listen: (Ac C) Stopping Active timer
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Listen: (Ac G) Sending coup message
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Session State Listen        -> Active
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1  FHRP:    Successfully queued ARP Update for 192.168.152.97 on TenGigE0/0/0/0.567*
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1  FHRP:    Queued RIB add for 192.168.152.97 on TenGigE0/0/0/0.567*
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1  FHRP:    Successfully queued MAC add for TenGigE0/0/0/0*, 0000.0c9f.f237
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1      IPv4#TenGigE0_0_0_0.567#0x237Forwarder State Listen  -> Active
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item ipv4/group/TenGigE0_0_0_0.567,567 to the sysdb state change notification queue
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1      (EDM): (Filter): VMAC mapping notification on TenGigE0/0/0/0.567*, virtual MAC 00000c9ff237, virtual ip 192.168.152.97
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item dest_macs/d40,00000c9ff237 to the sysdb ICMP redirects notification queue
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1      (EDM): (Filter): IP mapping notification on TenGigE0/0/0/0.567*, real ip 192.168.152.98, virtual 192.168.152.97
Feb 13 18:11:08.779 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item ip_mapping/d40,c0a89862,567 to the sysdb ICMP redirects notification queue
Feb 13 18:11:08.781 hsrp_bulked 0/RSP0/CPU0 t1  Send FO start message of size 1 to node 0x801 succeeded
Feb 13 18:11:08.783 hsrp_bulked 0/RSP0/CPU0 t1  Send FO send message of size 2 to node 0x801 succeeded
Feb 13 18:11:08.784 hsrp_bulked 0/RSP0/CPU0 t1  Send FO stop message of size 1 to node 0x801 succeeded
Feb 13 18:11:08.784 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Successful ARP update of size 1 (1 add, 0 remove, 0 grat ARP)
Feb 13 18:11:08.784 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Setting Ucast MAC attribute for 1 interfaces
Feb 13 18:11:08.789 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Updating RIB (table 0xe0000034, proto 0x4): Adding 1 routes, removing 0 routes
Feb 13 18:11:08.789 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  MAC addresses set complete (0 success, 1 fail): 'interface attributes library' detected the 'warning' condition 'At least one attribute operation failed. Check retcode array'
Feb 13 18:11:08.789 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Received IM disconnection event
Feb 13 18:11:08.789 hsrp_unbulk 0/RSP0/CPU0 t1  FHRP:    Failed to set MAC address on interface TenGigE0/0/0/0*: 'Ether' detected the 'warning' condition 'Out of memory': Not enough memory
Feb 13 18:11:08.790 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:    (batch_buffer_complete returned 1 - success)
Feb 13 18:11:08.790 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Sending batch to RIB
Feb 13 18:11:08.790 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:    (operation returned 6 - success)
Feb 13 18:11:08.791 hsrp_bulked 0/RSP0/CPU0 t1  Updating 1 sysdb state change notifications
Feb 13 18:11:08.793 hsrp_bulked 0/RSP0/CPU0 t1  Updating 2 sysdb ICMP redirect notifications
Feb 13 18:11:08.798 hsrp_unbulk 0/RSP0/CPU0 t1      (EDM): (Filter): IP mapping notification on TenGigE0/0/0/0.567*, real ip 192.168.152.99, virtual none
Feb 13 18:11:08.798 hsrp_unbulk 0/RSP0/CPU0 t1      Adding item ip_mapping/d40,c0a89863,0 to the sysdb ICMP redirects notification queue
Feb 13 18:11:08.798 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Active: (Ev i) Resign message from Active
Feb 13 18:11:08.798 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Active: (Ac G) Sending coup message
Feb 13 18:11:08.799 hsrp_bulked 0/RSP0/CPU0 t1  Send FO send message of size 2 to node 0x801 succeeded
Feb 13 18:11:08.799 hsrp_bulked 0/RSP0/CPU0 t1  Updating 1 sysdb ICMP redirect notifications
Feb 13 18:11:09.792 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Updating Owner Channel for 0 interfaces
Feb 13 18:11:09.792 hsrp_bulked 0/RSP0/CPU0 t1  FHRP:  Owner Channel update complete (0 success, 0 fail): No error
Feb 13 18:11:18.781 hsrp_unbulk 0/RSP0/CPU0 t1      TenGigE0/0/0/0.567*#0x237Active: (Ev d) Standby timer expired

 

 

Any help is usefull.

2 Accepted Solutions

Accepted Solutions

based on the LC type, you have a number of interfaces attached to the NPU also, they have a (base) mac address too that adds to this number.

trident doesnt have a limitation of 256, HSRP does.

HSRP's mac is composed of the standard mac+groupID.

if you have overlapping groupID's, eg 10 then two subinterfaces will use that same mac address. If subif X fails over, it will withdraw that mac from the table, causing the other subif that uses this mac to fail to receive data (I think the np counter reported is NOTMYMAC or something like that).

Also make sure you look at the struct for the right NP, I used np0 in my example, but you want to make sure that the interface you're having issues with is connected to that NPU. show controller np ports all loc will report the port to np mapping.

xander

View solution in original post

Hi Diego,

just to make sure; the 255 per interface for HSRP applies to typhoon also.

it is that mac withdraw situation in the tcam (which can hold 1024 entries both on trident and typhoon).

If you want to go higher, best to use VRRP.

cheers

xander

View solution in original post

13 Replies 13

xthuijs
Cisco Employee
Cisco Employee

do you have multiple groups on the main interface whereby there are overlapping groupID numbers by any chance?

when the traffic is not flowing, do you see any drops reported in the np counters for that RTR-A device in question?

those 2 datapoints will help solidify the precise next step possibly.

xander

I´m running HSRP v1 and v2 at the same time.

Over 250 groups in main interface (one per sub-interface). HSRP group # are NOT repeat.

0/RSP0/CPU0     A9K-RSP-4G

0/0/CPU0        A9K-2T20GE-B

 

one thing to verify diego is the np counters to see if there are drops due to the hsrp mac not being recognized, this would identify a programming issue on the hsrp vmac.

this can be verified with the show controller np struct 33 I think it was (virtual mac table).

another option you might consider is the use of MGO on all subinterfaces, that way we'll fail over all groups together, or you want that laodbalancing capability beween different vlans?

what version do you have there?

cheers

xander

I´m working with 4.3.4, maybe in some months move to 5.1.3.

About the controller np struct 33, it shows I´m on 257 of 1024, so thats not the issue.

As far as i know MGO is not support on 4.3.4

 

I think is a hardware limitation because of using Trident insted of Typhone.

you may want to look at the detail portion of that command to see the mac's programmed. this way if you have a failing group/subinterface, you can check the table via : show controller np struct 33 det all-entries np0 loc

and see if the mac is present in the table or not.

for sure the np counters would be good to look at to see why that group is not forwarding.

with 250 entries you're close to the limit of hsrp obviously.

xander

Ok

The output of the show controller np struct 33 shows that im on 257

 

RP/0/RSP0/CPU0:9010-Router-A#show controller np struct 33 det all-entries np3 loc 0/0/CPU0
Tue Feb 17 15:08:00.156 CST

                Node: 0/0/CPU0:
----------------------------------------------------------------

NP: 3
Struct 33: VRRP_MAC (maps to uCode Str=3 in TopSearch1)
Struct is a PHYSICAL entity
Reserved Entries: 0, Used Entries: 257, Max Entries: 1024
Entries Shown: 257
 -------------------------------------------------------------

 

So a Trident NP has a limitation of 256 Entries on Struct 33 even when the output shows 1024? Thyphone it is able to reach the 1024

We talk about this on a previous discussion and you light my way jejejej and teach me about this command, and now i see on a Thyphone is able to reach the 1024.

But Trident, the maximum is 256 in a port or the np?

 

Sorry about all this

 

based on the LC type, you have a number of interfaces attached to the NPU also, they have a (base) mac address too that adds to this number.

trident doesnt have a limitation of 256, HSRP does.

HSRP's mac is composed of the standard mac+groupID.

if you have overlapping groupID's, eg 10 then two subinterfaces will use that same mac address. If subif X fails over, it will withdraw that mac from the table, causing the other subif that uses this mac to fail to receive data (I think the np counter reported is NOTMYMAC or something like that).

Also make sure you look at the struct for the right NP, I used np0 in my example, but you want to make sure that the interface you're having issues with is connected to that NPU. show controller np ports all loc will report the port to np mapping.

xander

Tks Alexander

I´m am working on this with the TAC on SR 633699425.

They told me about the limitation per interface to 255, + limitation of np to 1024, all this in Trident.

I appriciate your comment about not using same hsrp group # in 2 interfaces that are attach to same np.

Tks!
 

Hi Diego,

just to make sure; the 255 per interface for HSRP applies to typhoon also.

it is that mac withdraw situation in the tcam (which can hold 1024 entries both on trident and typhoon).

If you want to go higher, best to use VRRP.

cheers

xander

Jajajajajjaj

Ok, but then why the ASR-9001 allows me to configure over 600 hsrp groups on same Interface?

I´m really running out of questions jejeje.

 

Tks

:)

that is because in the release of sw that you have (434) there is no enforcement/warning implemented to alert you on going beyond the 255 groups (which inherently means you're reusing groupID's).

that warning is part of newer releases.

in XR 51 you can have 4000 standby groups, but it is very important, for that scale, to use VRRP to prevent that mac overload situation that HSRP suffers from.

OR: configure the standby mac manually! that is another option for HSRP to go beyond 255.

As long as you stay below 1k vmac's per NPU, you're fine.

So "rule set" would be:

HSRP; with standard vmac, maxes out at 255

1K VMAC per NPU

to go beyond 255 standby sessions either:

- use configured standby-mac for HSRP

- use VRRP

in XR 51 scale is 4k total per system and warnings implemented when you reuse MAC.

OR use MGO for subinterface (sets).

this should do the trick :)

cheers

xander

Great so i will do that.

And when ever possible migrate to 5.1.3 and start using MGO.

Also try to migrate to VRRP.

And i will see what else of the full solution can arrange.

 

Tk U very Much Alexander!!

 

PD. Finally out of questions.

out of questions??? oh man :) just when we're getting warmed up :)

great talking with you and glad to see this helped!

am sure we'll be in touch later :)

cheers

xander