07-30-2024 08:17 AM - edited 07-30-2024 08:23 AM
I notice this configuration in production that is different than the Cisco recommended configuration. Is this worth correcting or should we leave it alone? The issue is the VIP IP is the same as the SVI IP address and not a third unique IP. It seems to be working but this seems odd to me. It is configured on many other unique SVIs.
switch1(c9500-40x)
interface Vlan 16
ip address 172.16.16.2
ip ospf cost 100
fhrp delay minimum 5
vrrp 16 address-family ipv4
preempt delay minimum 30
address 172.16.16.1 primary
VRRP Statistics for Vlan16
Header Discarded Packets: 0
Invalid TTL/Hop Limit: 0
Invalid Checksum: 0
Invalid Version: 0
Invalid Msg Type: 0
Invalid length/Incomplete packet: 0
Invalid group no: 0
Invalid packet other reason: 0
VRRP Statistics for Vlan16 - Group 16 - Address-Family IPv4
State is BACKUP
State duration 12 weeks 2 days 15 hours
VRRPv3 Advertisements: sent 0 (errors 0) - rcvd 8312091
VRRPv2 Advertisements: sent 0 (errors 0) - rcvd 0
Group Discarded Packets: 0
VRRPv2 incompatibility: 0
IP Address Owner conflicts: 0
Invalid address count: 0
IP address configuration mismatch : 0
Invalid Advert Interval: 0
Adverts received in Init state: 0
Invalid group other reason: 0
Group State transition:
Init to master: 0
Init to backup: 1 (Last change Sat May 04 19:36:53.891 )
Backup to master: 0
Master to backup: 0
Master to init: 0
Backup to init: 0
------------------------------------------------------
switch 2(c9500-40x)
interface Vlan 16
ip address 172.16.16.1
ip ospf cost 200
fhrp delay minimum 5
vrrp 16 address-family ipv4
priority 120
preempt delay minimum 30
address 172.16.16.1 primary
exit-vrrp
VRRP Statistics for Vlan16
Header Discarded Packets: 0
Invalid TTL/Hop Limit: 0
Invalid Checksum: 0
Invalid Version: 0
Invalid Msg Type: 0
Invalid length/Incomplete packet: 0
Invalid group no: 0
Invalid packet other reason: 0
VRRP Statistics for Vlan16 - Group 16 - Address-Family IPv4
State is MASTER
State duration 128 weeks 2 days 17 hours
VRRPv3 Advertisements: sent 86207374 (errors 0) - rcvd 0
VRRPv2 Advertisements: sent 0 (errors 0) - rcvd 0
Group Discarded Packets: 0
VRRPv2 incompatibility: 0
IP Address Owner conflicts: 0
Invalid address count: 0
IP address configuration mismatch : 0
Invalid Advert Interval: 0
Adverts received in Init state: 0
Invalid group other reason: 0
Group State transition:
Init to master: 1 (Last change Sat Feb 12 17:43:59.129)
Init to backup: 0
Backup to master: 0
Master to backup: 0
Master to init: 0
Backup to init: 0
end
Solved! Go to Solution.
07-30-2024 05:18 PM
Indeed it not usual to use VRRP IP same as one Peer IP
so I late my reply to test one condition here
master use 10.0.0.2 and VRRP is 10.0.0.1 by config high priority
backup use 10.0.0.1 and VRRP is 10.0.0.1
in this case we can not never reach backup Peer IP since master (10.0.0.2) use VRRP IP 10.0.0.1
when I start config and config backup with low priority, the below error message appear
this error message meaning that always the Peer that have IP same as VRRP IP will elect as master whatever it priority
MHM
07-30-2024 09:49 AM - edited 07-30-2024 09:50 AM
I always prefer to not try to fix what is not broken but the scenario is weird, to say the least. You probably have two ARP entry for 172.16.16.1 on Switch 2, right? One with the mac address of vlan 16 and one with a virtual mac address of HRRP.
I wonder if you ever shut the vlan 16 on the Switch 2 if everything will be ok. I believe it worth try in a lab.
07-30-2024 12:34 PM
Hello @WMA Hell ,
VRRP allows this kind of configuration with the VRRP VIP = interface IP address of one device that is member of the VRRP group.
When this happens the device with the IP address equal to the VRRP VIP address is the master until it is alive on the subnet.
This is what you see in your show outputs.
There are some special cases where this can be handy if you have a small public IP subnet and you want to run a FHRP using only two addresses instead of the three that would be used by HSRP.
In your scenario you have private IP address per RFC 1918 and the subnet is /24 so there is not a strict need to use this VRRP capability.
Probably the idea was to be sure that swich2 is the MASTER without changing priority.
Hope to help
Giuseppe
07-30-2024 01:34 PM
Hello,
This is a perfectly valid configuration and I have used this in a lab. You may be able to ask around for the original intention, but it just saves an extra IP address in the subnet. Useful for subnets with limited amount of IP addresses.
-David
07-30-2024 05:18 PM
Indeed it not usual to use VRRP IP same as one Peer IP
so I late my reply to test one condition here
master use 10.0.0.2 and VRRP is 10.0.0.1 by config high priority
backup use 10.0.0.1 and VRRP is 10.0.0.1
in this case we can not never reach backup Peer IP since master (10.0.0.2) use VRRP IP 10.0.0.1
when I start config and config backup with low priority, the below error message appear
this error message meaning that always the Peer that have IP same as VRRP IP will elect as master whatever it priority
MHM
07-31-2024 07:17 AM
Yes. Thank your for mocking this up in GNS3. This is very disconcerting as I presume the intention is to have switch1 as the master since OSPF has a lower cost than switch2. I'll mention it to management but they will probably ignore it. I will come up with a proper replacement configuration. Thanks for the support.
07-31-2024 07:49 AM
Also, you conducted this test on a router with IOS-XE. I have two Cisco Catalyst 9k switches. Are the effects the same? Also, the IOS XE documentation doesn't mention the VIP being the same as interface IP gives priority of 255. It only says this: "
If a VRRP device owns the IP address of the virtual device and the IP address of the physical interface, this device will function as a primary virtual device." It doesn't distinguish if the VIP is the same as the interface IP.
Nexus documentation says this: "If a VRRP router owns the virtual IP address and the IP address of the physical interface, this router functions as the master. The priority of the master is 255." It doesn't say if the VIP IP is the same as the interface IP.
Your test proved preemption will not happen if a router has the interface IP the same as the VIP. Would it be too much trouble for you to do the same test with a mockup of Catalyst or is it mute as they both use IOS-XE?
07-31-2024 09:41 AM - edited 07-31-2024 09:41 AM
Note: S1 is backup for VLAN 16
Note: S2 is master for VLAN 16.
Note: S1 and S2 are connected via a port channel.
I can't reconcile why VLAN 16 traffic on S2 is RX traffic with Tx 0 and why VLAN 16 on S1 is Tx traffic and Rx (0).
The upstream router is singled legged to S1.
07-31-2024 10:56 AM
I will test with NSK also
And then test mix ios and NX-OS and update you.
MHM
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