VRRP VIP and the physical interface IP

[Mitrixsen]

Hello, everyone.

I am studying VRRP at the moment and I found out that you can configure the VIP to be the same as one of your interface IPs (which wasn't possible in HSRP).

I have two questions about this.

1. If the VRRP router owns the virtual IP, it changes its priority to 255? Why? This creates a priority high enough that the local device can never be preempted. I also cannot change the priority.

2. Why can we even configure the VIP to be the same as the interface IP? Say that we configure it to be 192.168.1.1 which is the same as an interface IP. If I issue a ping, how does the router know whether we're pinging the VIP or the physical interface IP?

Thank you.

David

[paul driver]

Hello
if you do use the same physical ip as the vip then you don’t have gateway resiliency - and that’s the point of fhrp protocols - hence I envisage why the priority is set to 255 as the other rtr won’t be able to use a vip that is currently assigned to another physical interface on the same subnet
Tbh not recommended in either case

[Mitrixsen]

Hello Paul.

VRRP works in my lab, even if I configure the VIP to be the same as a physical IP address.

SW1 became the Master gateway because of the priority being 255

If I shutdown the VLAN interface on SW1, SW2 takes over

And my PC can still communicate outside of its network via SW2 which means that I still have redundant gateways

David

[paul driver]

Hello

---

@Mitrixsen wrote:

Hello Paul.

VRRP works in my lab, even if I configure the VIP to be the same as a physical IP address.

Curious though you do not see any duplicate addressing, I would expect that at the very least?
Can you test something as i dont have the access at present, post the results

L3-SW1 - ip address only (no vip)
L3-SW2 - ip address and the vip of L3-SW1 vlan1 interface

[paul driver]

FYI
As expected although It would depend on how its applied - duplicating addressing before vrrp is also applied to sw1, obviously if L3-SW1 svi is shut down duplication ip conflict will cease

L3-SW1
interface Vlan1
ip address 1.1.1.1 255.255.255.0
no shut

L3-SW2
interface Vlan1
ip address 1.1.1.2 255.255.255.0
vrrp 1 ip 1.1.1.1

*Jan 19 21:06:58.889: %VRRP-6-STATECHANGE: Vl1 Grp 1 state Master -> Disable
*Jan 19 21:06:58.894: %VRRP-6-STATECHANGE: Vl1 Grp 1 state Init -> Backupend
*Jan 19 21:07:01.817: %SYS-5-CONFIG_I: Configured from console by console
*Jan 19 21:07:02.504: %VRRP-6-STATECHANGE: Vl1 Grp 1 state Backup -> Master

L3-SW1#
*Jan 19 21:06:36.239: %IP-4-DUPADDR: Duplicate address 1.1.1.1 on Vlan1, sourced by 0000.5e00.0101
*Jan 19 21:07:06.717: %IP-4-DUPADDR: Duplicate address 1.1.1.1 on Vlan1, sourced by 0000.5e00.0101
*Jan 19 21:07:37.662: %IP-4-DUPADDR: Duplicate address 1.1.1.1 on Vlan1, sourced by 0000.5e00.0101

L3-SW2#
*Jan 19 21:07:32.693: %IP-4-DUPADDR: Duplicate address 1.1.1.1 on Vlan1, sourced by 5001.0010.8001
*Jan 19 21:08:02.748: %IP-4-DUPADDR: Duplicate address 1.1.1.1 on Vlan1, sourced by 5001.0010.8001
*Jan 19 21:08:32.808: %IP-4-DUPADDR: Duplicate address 1.1.1.1 on Vlan1, sourced by 5001.0010.8001
*J

L3-SW1(config-if)#vrrp 1 IP 1.1.1.1
Jan 19 21:18:44.041: %VRRP-6-STATECHANGE: Vl1 Grp 1 state Init -> Master
*Jan 19 21:18:44.061: %VRRP-6-STATECHANGE: Vl1 Grp 1 state Init -> Master

L3-SW1(config-if)#vrrp 1 priority 10
% Priority change will have no effect whilst interface is vrrp address owner _ this is the reason why the priority sets itself to 255

L3-SW1(config-if)#do sh vrrp br
Interface Grp Pri Time Own Pre State Master addr Group addr
Vl1 1 255 3003 Y Y Master 1.1.1.1 1.1.1.1

L3-SW2#sh vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Vl1 1 254 3007 Y Backup 1.1.1.1 1.1.1.1

 duplicate address conflict is negated but not able to make L3-SW1 become a standby

So to summarise make no sense to set a vip to a same physical interface of a SVI/routed port

[MHM Cisco World]

I think you can do same in HSRP'

I see same config (in HSRP) in one of ccie lab. 

To be honest I dont know why we need to make active IP and VIP same.

MHM

[Mitrixsen]

Hello MHM Cisco World.

I've tried it with HSRP but the command doesn't pass (unless there is another way around this :D)

As for VRRP, I don't think I would ever make the VIP and the physical IP the same, but it's pretty weird that the possibility is there.

David

[MHM Cisco World]

Config one router interface IP with same of VIP 

Config other router with high priority and enable preempt.

I think the first router always elect as master whatever other routers priority.

This make elect not depend on priority to elect master of group.

Check this point.

Thanks 

MHM

[Mitrixsen]

Yes, you're correct. Whoever is the owner of the VIP / router interface IP will always be the master because its priority is set to 255 (the configurable priority is from 0 to 254) so no router will be able to be the master for this VIP unless the owner goes down.

[Giuseppe Larosa]

Hello @Mitrixsen ,

VRRP is built to be a FHRP read carefully the related RFCs and yes VRRP provides the capability to have the VIP = the interface address in that case the master is always the master until it dies.

By default VRRP has preemption enabled.

Hope to help

Giuseppe

[Joseph W. Doherty · Accepted solution]

---

@Mitrixsen wrote:

1. If the VRRP router owns the virtual IP, it changes its priority to 255? Why? This creates a priority high enough that the local device can never be preempted. I also cannot change the priority.

That might be a Cisco "feature", as Cisco provides HSRP.

I did a quick Internet search for VRRP master preemption, other vendors appear they might allow it.  So, I then started to read the VRRP RFCs, but haven't studied them enough to say whether VRRP preemption, other than for selecting a new master, is a RFC option or requirement.

---

@Mitrixsen wrote:

2. Why can we even configure the VIP to be the same as the interface IP? Say that we configure it to be 192.168.1.1 which is the same as an interface IP. If I issue a ping, how does the router know whether we're pinging the VIP or the physical interface IP?

Why not, if everything can be made to work correctly, even if possibly not optimally?

Regarding "optimally", both in regard to Cisco's implementation and the design of VRRP itself, understand the context.  HSRP is a proprietary Cisco protocol while VRRP is a later "public" alternative protocol.  Cisco doesn't have much interest in supporting competitive "solutions", especially when they are often inferior.  When you understand that, and its implications, "why" some technical approaches are done as they have been, will make "business" sense when they don't make "technical" sense.

[Mitrixsen · Accepted solution]

Hello.

Thank you for the response. I've looked into this some more and now it makes sense.

The reason why the priority is set to 255 for owned addresses (which isn't a priority that you can configure in VRRP, the maximum is 254 which makes anyone with this priority always the master) is pretty straightforward and I didn't notice it at first.

If you own the IP address that is also the VIP, it would be a bad idea if another VRRP device were allowed to control this IP address while you're online. Say that I have R1's physical IP as the VIP but R2 is the Master. If I tried to communicate with R1's physical IP in any way (for ex: SSH), it would be R2 who would respond to any ARP requests regarding R1's IP.

For this reason, the priority is set to 255 if the VIP is one of your owned addresses. Given that this priority is higher than the maximum configurable value (254), no router will be able to take over as the master router for this VIP unless the current master goes down.

In summary, it's a bad idea if another VRRP participant was allowed to control the physical IP address owned by another VRRP participant while it was still online.

As for the second point, you're right. If everything can be made to work correctly, we can even use the physical interface IP. If this is configured, the router always assumes that the intent is to hit the VIP (if I, for example, issue a ping).

David

[MHM Cisco World]

I am not agree with some point but let me check before reply with more detail 

MHM