Multi-vendor troubleshooting lab 3 of 12

VRRP across four vendors

Four routers from four vendors share one office LAN and one virtual gateway, and all of them think they're the master. Match VRRP version, timers and authentication until exactly one router wins, then prove that the gateway really carries traffic.

Run this lab

It needs Lite: its 5 nodes are set to 6 vCPU and 7,424 MB in total. That fits the free demo too.

In your workspace: Shared, then Multi-vendor interoperability and troubleshooting guided labs, then 03 - VRRP across four vendors

Try it free for 30 minutesRun it on Lite from £3 a day

The free demo needs no card and no email. Every lab plan includes every guided lab.

Level
Intermediate
Time
About 70 minutes
Nodes need
6 vCPU, 7,424 MB
Smallest plan
Lite

The scenario

During Larkfield's office move, four routers from four projects share the Leeds LAN and are meant to act as one gateway, 10.30.0.1. Staff report that the network works, then doesn't, then works again. The monitoring system says the gateway is down, although the users behind it are often fine.

Each router has its own address, plus a loopback 198.51.100.1 that stands in for the internet: a host that can reach it has a working gateway.

DeviceInterfaceAddressVRRP priority
R1Gi0/010.30.0.11/24200 (the intended master)
SRX1ge-0/0/0.010.30.0.14/24150
EOS1Ethernet110.30.0.12/24120
CHR1ether110.30.0.13/24100
H1eth010.30.0.100/24Gateway 10.30.0.1
Design standardValue
Virtual routerVRID 30, virtual IP 10.30.0.1
VersionVRRPv2
Advertisement interval1 second
AuthenticationSimple text, Lark30
MonitoringThe virtual IP must answer ping

What you’ll practise

  • Read VRRP state on IOS, Junos, EOS and RouterOS
  • Explain why VRRP mismatches give two masters, not an error
  • Match VRRP version, advertisement interval and authentication between vendors
  • Explain the virtual MAC, and check it from a host
  • Find a wrong key on Junos, where the configuration hides the secret
  • Test pre-emption across vendors

The tasks

  1. Give H1 its address
  2. Count the masters
  3. Authentication on R1
  4. Timers on EOS1
  5. Version on CHR1
  6. A key you can't read
  7. Test pre-emption

The Lab Tasks pane has the scenario, these tasks, the checks to run, hints and the full solution.

Topology and devices

The network as it opens in EVE-NG, drawn from the lab’s own canvas, and the image each node runs.

Topology of VRRP across four vendors5 nodes and 1 network, 5 links. Every link is listed as text below the diagram.SRX1R1EOS1CHR1H1Leeds-LANeth0ge-0/0/0Gi0/0Ethernet1ether1
5 nodes and 1 network, with the interface names each link uses. On a narrow screen, scroll the diagram sideways.
Nodes in VRRP across four vendors, with the image each runs and the vCPU and RAM it’s set to
NodeDeviceImage in Add NodeSet to
SRX1Juniper vSRX NextGen templatevsrxng-23.4R2-S3.92 vCPU, 4,096 MB
R1Cisco IOSvvios-adventerprisek9-m.spa.159-3.m91 vCPU, 512 MB
EOS1Arista vEOSveos-4.33.1.1F1 vCPU, 2,048 MB
CHR1MikroTik RouterOSmikrotik-7.14.21 vCPU, 256 MB
H1Alpine Linuxclbalpinebase-alpine-base-3-20-31 vCPU, 512 MB

How to open this lab

  1. Sign in to your workspace at lab.cloudlabbox.com.

  2. In File Manager, open Shared, then the folder Multi-vendor interoperability and troubleshooting guided labs.

  3. Open 03 - VRRP across four vendors and start its nodes, then open Lab Tasks for the scenario and the steps.

The lab is read-only. You can start the nodes and configure the devices, but changes to the topology can’t be saved. To change it, rebuild it in your own folder.

More Multi-vendor troubleshooting labs

All Multi-vendor troubleshooting labs

Related labs in other courses

CloudLabBox is independent of Arista Networks, Cisco, CompTIA, Fortinet, HPE, Juniper Networks and MikroTik. The lab follows exam topics and isn’t vendor training material; vendor names identify the exams and the images in the workspace.