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
- 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.
| Device | Interface | Address | VRRP priority |
|---|---|---|---|
| R1 | Gi0/0 | 10.30.0.11/24 | 200 (the intended master) |
| SRX1 | ge-0/0/0.0 | 10.30.0.14/24 | 150 |
| EOS1 | Ethernet1 | 10.30.0.12/24 | 120 |
| CHR1 | ether1 | 10.30.0.13/24 | 100 |
| H1 | eth0 | 10.30.0.100/24 | Gateway 10.30.0.1 |
| Design standard | Value |
|---|---|
| Virtual router | VRID 30, virtual IP 10.30.0.1 |
| Version | VRRPv2 |
| Advertisement interval | 1 second |
| Authentication | Simple text, Lark30 |
| Monitoring | The 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
- Give H1 its address
- Count the masters
- Authentication on R1
- Timers on EOS1
- Version on CHR1
- A key you can't read
- 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.
Every link, as text
- SRX1
ge-0/0/0to Leeds-LAN (network) - R1
Gi0/0to Leeds-LAN (network) - EOS1
Ethernet1to Leeds-LAN (network) - CHR1
ether1to Leeds-LAN (network) - H1
eth0to Leeds-LAN (network)
| Node | Device | Image in Add Node | Set to |
|---|---|---|---|
| SRX1 | Juniper vSRX NextGen template | vsrxng-23.4R2-S3.9 | 2 vCPU, 4,096 MB |
| R1 | Cisco IOSv | vios-adventerprisek9-m.spa.159-3.m9 | 1 vCPU, 512 MB |
| EOS1 | Arista vEOS | veos-4.33.1.1F | 1 vCPU, 2,048 MB |
| CHR1 | MikroTik RouterOS | mikrotik-7.14.2 | 1 vCPU, 256 MB |
| H1 | Alpine Linux | clbalpinebase-alpine-base-3-20-3 | 1 vCPU, 512 MB |
How to open this lab
Sign in to your workspace at
lab.cloudlabbox.com.In File Manager, open Shared, then the folder
Multi-vendor interoperability and troubleshooting guided labs.Open
03 - VRRP across four vendorsand 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.