02-15-2015 12:09 PM
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.
Solved! Go to Solution.
02-17-2015 01:23 PM
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
02-18-2015 05:40 AM
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
02-16-2015 01:44 PM
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
02-16-2015 02:17 PM
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
02-17-2015 10:06 AM
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
02-17-2015 10:17 AM
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.
02-17-2015 11:41 AM
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
02-17-2015 01:16 PM
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
02-17-2015 01:23 PM
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
02-17-2015 02:49 PM
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!
02-18-2015 05:40 AM
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
02-18-2015 07:26 AM
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
02-18-2015 08:16 AM
:)
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
02-18-2015 09:00 AM
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.
02-18-2015 09:04 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide