hi Andrew
Why have you used the same ip address for interface vlan A and B 192.168.1. 252?
Hello Daniel
Youâre right, it seems that it was a typo. The IP addresses on VLAN B have 2 as the third octet. Iâve corrected the post so that it shows the right IP addresses.
Thanks for pointing that out!
Laz
Ok, went through this entire thread and didnât find a single mention of IPv6 for VRRP. I know the original protocol did not support IPv6, but was wondering if there was an update for support. Iâve been using HSRP for most of my IPv4/v6 links, but am starting to move to more Arista gear and need to start thinking of protocols that support multiple vendors.
Any pointers to IPv6 support would be helpful.
Marcos
Hello Marcos
VRRPv3 supports the use of both IPv4 and IPv6 addresses. You must however ensure that the platform and IOS combination you are using support VRRPv3 in order to implement it. You can find out configuration information at the following Cisco documentation:
I hope this has been helpful!
Laz
Hi,
Is it possible to advertise a vrrp virtual IP over and IGP such as OSPF? Or is the only way to reach the VIP by setting static route to it?
Hello Hassan
First Hop Redundancy Protocols (FHRPs) are used to provide a redundant gateway to hosts. This means that FHRPs like VRRP and others should be implemented on subnets that contain end-user host devices. Typically, FHRPs are not used to connect to subnets that have routers that route traffic further downstream. As such, you should not need to advertise the IP addresses of the redundant gateways using an IGP.
Now having said that, if you still want to use an IGP with VRRP (or HSRP, or GLBP), keep the following rule of thumb in mind: Only the IP addresses of the physical interfaces are advertised. In other words, IGPs will not advertise the virtual IP address. However, keep in mind that VRRP allows you to have a virtual IP address that is the same as the real IP address on the interface of one of the redundant routers. This of course may cause problems in routing if that particular router goes down. The other router will adopt that IP address, but the IGP will attempt to reach the failed router, resulting in failed connectivity.
If you want to achieve load balancing in the core of your network, it is preferable to use the load balancing features of routing protocols rather than an FHRP.
I hope this has been helpful!
Laz
good evening sir Rene , in this course you make the comparison of HSRP and VRRP protocols by mentioning in the table one of the difference which is their multicast address .:224.0.0.2 and 224.0.0.18 , my concern is how a protocol can have the multicast address what it is used for these protocols concretely, since in the heart of multicast I think I have retained that it is the routers which use the addresses to broadcast the packets and the hosts also use these addresses to make a request
Hello Berthol
In order to operate correctly, many protocols and features use multicast to fulfill their functions. For example, OSPF and EIGRP routers need to send out hello messages and updates to communicate with other OSPF and EIGRP routers and establish their neighbor adjacencies. When such routing protocols are enabled, they automatically become members of specific predefined multicast groups for this purpose.
In a similar manner, VRRP and HSRP devices must communicate with each other in order to establish their function. When VRRP or HSRP is configured on a device, it automatically becomes part of the multicast group corresponding to the reserved multicast address.
Multicast is a convenient way of employing such features because initially, the devices involved have no information about how to reach each other to communicate. If a specific multicast address is reserved for these purposes, then HSRP and VRRP devices will automatically find each other and create their initial communication to make the feature work correctly. In such cases, you donât need to configure multicast at all, this is all preconfigured by the feature itself.
I hope this has been helpful!
Laz
1 Like
Hello team,
In the table for comparison youâre saying authentication is not supported in RFC. However in the configuration example Authentication is configured. Does this mean it is not âofficiallyâ supported but works in real environment?
Thanks,
Hello David
Indeed, according to RFC 3768 and even the most recent VRRP RFC 5798, VRRP does not currently include any authentication. Indeed, an earlier version of VRRP included several types of authentication. However, according to both of the above RFCs:
Earlier version of the VRRP specification had several defined
authentication types [RFC2338]. These were removed in this
specification because operational experience showed that they did not
provide any real security and would only cause multiple masters to be
created.
However, Cisco has implemented a proprietary feature called VRRP Authentication that provides a way to add authentication to VRRP. More about how to configure that can be found in the lesson, as you have already mentioned, as well as in the following documentation:
It is important to note that because VRRP Authentication is a proprietary feature, it may not be supported on other vendor devices or be interoperable with other VRRP implementations. If you need to provide redundancy between devices from different vendors, you may want to consider using an industry-standard protocol such as GLBP (Gateway Load Balancing Protocol) which support authentication and are supported by multiple vendors.
I hope this has been helpful!
Laz
1 Like
Hi Expert,
Does Cisco IOS-XR support configuration for single VRRP ID number with different interface ?
Thank for sharing
Hello Giarto
Each VRRP group is identified by a unique VRRP group ID number, which is configured on each router participating in the group. However, multiple interfaces on a single router can participate in the same VRRP group, as long as they are configured with the same VRRP group ID number and priority.
An example of where this could be useful is the following:
Letâs say you have a network with two switches connected to a router. Each switch has multiple VLANs, and the router has a separate interface for each VLAN on each switch. To provide redundancy for the network, you configure the router to participate in a VRRP group with the switches.
By using the same VRRP ID on each interface, you can ensure that the router appears as a single virtual router to the switches, even though it has multiple interfaces. This means that if one of the routerâs interfaces fails, the switches will automatically switch to using the virtual IP address associated with another interface on the same router, without having to reconfigure their routing tables.
In such a case, you are delivering redundancy between router ports rather than between multiple routers. This still has a single point of failure (the router itself) but it does deliver redundancy for the physical links to the router, and the router interfaces themselves.
I hope this has been helpful!
Laz
Hi Lazaros,
Thank you for your explanation, that we can configured same VRRP ID with different physical interfaces. As virtual mac-address will created based on VRRP ID, is it possible to create same VRRP ID on different Sub-interfaces but in same 1 Physical interface ?
Thank you.
Gie
Hello Gie
Yes, it is possible to create the same VRRP ID on different sub-interfaces of the same physical interface, as long as they belong to different VLANs or have different IP subnets. This is because the VRRP ID is unique within an IP subnet or VLAN.
The virtual MAC address for VRRP is generated based on the VRRP ID, and it will be the same for the same VRRP ID. However, since the sub-interfaces belong to different VLANs or IP subnets, there will be no conflict or issues in the network, as each sub-interface will have its own unique layer 3 address. The virtual MAC address is only used for forwarding packets to the active VRRP router within the same VLAN or IP subnet, so it will not cause any conflict in this scenario.
I hope this has been helpful!
Laz
Hello Gie
Just an update on this one. Although Cisco documentation seems to indicate that it is possible to use the same VRRP ID on different subinterfaces of the same physical interface, actually going into the lab and trying it out shows different results:
R1(config)#int gi 0/0.1
R1(config-subif)#encapsulation dot1Q 10
R1(config-subif)#ip address 192.168.1.1 255.255.255.0
R1(config-subif)#vrrp 10 ip 192.168.1.254
R1(config-subif)#exit
R1(config)#int gi 0/0.2
R1(config-subif)#encapsulation dot1Q 20
R1(config-subif)#ip address 192.168.2.1 255.255.255.0
R1(config-subif)#vrrp 10 ip 192.168.2.254
% Cannot create new VRRP group
It doesnât give a further explanation as to why the creation of the VRRP group fails. However, it does seem to be because the same VRRP ID is being used on multiple subinterfaces of the same physical interface. I tried using the same VRRP ID on different physical interfaces and I was successful.
Iâm using IOSv Version 15.9(3)M6 on Ciscoâs CML platform. It may be that in previous versions of IOS this was possible and this is why we see it in the documentation, but it has changed in the more recent versions.
Laz
Hello Laz,
I have configured VRRP in real production network for one of my customers but we face some challenge and that it traffic out toward the customer is load shared although i have set higher priority on the first interface which is the master,
do you know any way to flow traffic only on one interface which is the master VRRP, and only when this particular interface goes down traffic will flow to the backup VRRP.
Hello Ahmedlmad
VRRP by design does not deliver automatic load sharing. It should let traffic flow through the primary router, and will fall back to the secondary router only if the primary router fails. Load sharing is only achievable manually by creating multiple VRRP groups, with different gateway configurations of all the clients within the subnet, as shown in this Cisco documentation.
Setting up the appropriate priorities and configuring the primary and backup routers should be sufficient to achieve what you need. However, some platforms may choose to employ their own âenhancedâ version of VRRP that may automatically enable load sharing. I know that this is the case with HSRP on Cisco Nexus devices. What devices are you configuring using VRRP? Let us know so that we can help you further.
I hope this has been helpful!
Laz
Hello Laz,
Thanks for your prompt reply actually you was right, due you to our network design my customer download traffic was flowing equally on both interfaces toward my client, accordingly we have set higher metric to one of the paths, eventually the traffic took the primary vrrp router ,
regards.
1 Like
Hi Team,
I noticed that in HSRP and GLBP you can ping the VIP, but not in VRRP. To confirm the VIP is working in VRRP itâs enough to see the VIP entry in the ARP.
Why is there a difference, I understand that the VIP does not need to respond to ICMP packets as traffic just traverse there, but why we can ping it in HSRP and GLBP? Is there any real world application?
Kind Regards,
Martin Kuntov
Hello Martin
Your observation is correct. In HSRP and GLBP, the Virtual IP responds to pings, but in VRRP, it does not. This is based on the way the protocol itself is designed. The reason for this is clearly stated in RFC 3768 which defines VRRP.
Unlike HSRP, VRRP can use either a non-assigned IP address as the virtual IP (as configured in the lesson), or it can use an IP address that is owned by one of the redundant routers as the virtual IP. In this case, the âIP Address Ownerâ is defined as the router that has been assigned the same address that is used as the virtual address. In such a case, the IP address owner also becomes the master device.
Now the RFC states the following:
The Master:
MUST NOT accept packets addressed to the IP address(es) associated
with the virtual router if it is not the IP address owner.MUST accept packets addressed to the IP address(es) associated
with the virtual router if it is the IP address owner.
So in a scenario like the one in the lesson, if you ping the virtual IP address, then the router MUST NOT accept packets addressed to the virtual IP addresses. So pings will be ignored. However, if you configured the virtual IP address as one of the real assigned addresses on one of the routers, then those packets will be accepted and the pings will be responded to.
So to summarize, if the destination IP is that of the IP Address Owner, the ping will be responded to. If the virtual address does not belong to one of the routers, then it will not respond to pings.
Why is this? Well, the RFC gives the following reason:
Potential Forwarding Loop
A VRRP router SHOULD not forward packets addressed to the IP
Address(es) it becomes Master for if it is not the owner. Forwarding
these packets would result in unnecessary traffic. Also in the case
of LANs that receive packets they transmit (e.g., token ring) this
can result in a forwarding loop that is only terminated when the IP
TTL expires.
I hope this has been helpful!
Laz
1 Like