VRRP Setup

[robknowles]

Hi,

 

I'm looking at setting up VRRP. I have an existing, older switch/router that supports this so was thinking about using it as a backup for our core router.

 

My understanding is this:

- Each Router has all of the VLANs & Routing tables etc setup, each with its own unique IP for each VLAN/Subnet defined.

- VRRP is enabled and is associated with a Virtual VRRP IP Address for each VLAN/subnet - this is the address that clients use as the default gateway.

- I specify a master router (i.e. our current core router by specifying a value, such as 255 - highest priority) and enable this.

- I will then setup the secondary router.

- All our satellite/edge switches must be connected to both switches. STP will be enabled to disable the uplink to the backup router until the main link goes off.

- If the core router goes offline then within a few seconds the backup router assumes the role as the router for the school and STP will allow the backup link to be used

- If a fibre transceiver goes down on a edge switch then STP will allow data to be transmitted to the backup switch which transmit it to the core switch.

 

Is my understanding correct?

 

So in my case, I will need to rename IPs used on the current core router, such as 172.16.0.1 becoming 172.16.0.2, setup the backup router to have 172.16.0.3 and then also setup VRRP to then re-use 172.16.0.1 (as clients already point to this as the default gateway).

 

Any thoughts appreciated. I should add I have Dell PowerConnect Switches - using a 8000 (Master) and 7000 (Backup) series router

 

Cheers,

 

Rob

Edited April 29, 2013 by robknowles

[Destinova]

You're on track with the exception of the STP part. STP plays no role in VRRP operation. You do not want to disable the link to the backup router. Your layer 2 devices (switches) are forwarding traffic to a virtual MAC address (the layer 2 address of the virtual IP or default gateway), so absolutely nothing changes from a switching perspective if the primary router fails. The secondary router simply 'becomes' that L2 address. Your switches simply learn that MAC is on a different port and forward traffic accordingly.

 

Some more info:

 

RFC 3768 - Virtual Router Redundancy Protocol (VRRP)

http://www.dell.com/downloads/global/products/pwcnt/en/app_note_32.pdf

[ConradJones]

anyone blocking the vrrp broadcasts ? not between the two routers but across the vlan.

[Destinova]

anyone blocking the vrrp broadcasts ? not between the two routers but across the vlan.

 

VRRP doesn't use broadcast except for the initialization phase during which it sends a gratuitous ARP request containing the virtual router MAC address. Otherwise multicast is used between VRRP routers to multicast address 224.0.0.18 using IP protocol 112.

[ConradJones]

VRRP doesn't use broadcast except for the initialization phase during which it sends a gratuitous ARP request containing the virtual router MAC address. Otherwise multicast is used between VRRP routers to multicast address 224.0.0.18 using IP protocol 112.

 

apologies i mean the multicast, i was pretty tired last night.

 

I'm seeing the multicast on all my machines?

[Destinova]

apologies i mean the multicast, i was pretty tired last night.

 

I'm seeing the multicast on all my machines?

 

From what source?

 

Unless you are seeing it specifically to 224.0.0.18 using IP protocol 112, it isn't your VRRP devices.

[ConradJones]

from the real ip of one of the routers.

 

i'm just going to block it everyone, it makes these switches go active/active if you block it between them

Edited May 1, 2013 by ConradJones

[Destinova]

Yes, but what destination? There are several reasons for multicast traffic, you need to find out the destination address before you can determine what it is being used for. Multicast addressing in many cases is reserved, so you can look up what service or protocol is using it.

 

IPv4 Multicast Address Space Registry

 

Blocking it with respect to VRRP is bad. You'll just cause all VRRP gateways to constantly believe they should be the active device because they will not be able to communicate with each other.

 

Also, you can ping the multicast address and see what responds. A ping to 224.0.0.18 should return replies from any VRRP device.

[ConradJones]

yes that destination, wireshark flags it as vrrp.

 

read the second to last post of the first page

 

ESRP vs VRRP - ExtremeXOS - EtherNation

[Destinova]

yes that destination, wireshark flags it as vrrp.

 

read the second to last post of the first page

 

ESRP vs VRRP - ExtremeXOS - EtherNation

 

Ok so you've got a non-standards based iteration of VRRP that doesn't follow the protocol. Fair enough. In that case you might want to block it then, or use a standards-based L3 redundancy protocol that doesn't flood your network with multicast traffic.