I design networks that mix vendors, so I need to know how each one thinks. This page explains how Arista EOS (Extensible Operating System) and Juniper Junos work inside and how changes land on each. It covers MLAG (multi chassis link aggregation), buffers, Virtual Chassis and routing policy, and where they differ from Cisco IOS and NX-OS. It ends with a CLI (command line interface) translator and the faults I expect where vendors meet.
Most of my production work has been on Cisco, with Palo Alto, Check Point, FortiGate, F5 and Aruba alongside. Arista and Juniper turn up in the same kinds of estates: Arista in data centres and trading networks, Juniper at the provider edge and in campuses run from the cloud. This page sets out how EOS and Junos work, how they differ from Cisco, and what I check when they meet.
Swipe sideways to see the whole diagram.
In the campus, Juniper EX switches are usually run with Juniper Mist, a cloud service that uses AI (artificial intelligence) to find faults across wired and wireless clients. Arista sells campus switches too, such as the 720XP and 750, managed through CloudVision. Most campus estates I see are still Cisco Catalyst, so the second vendor tends to arrive with a new site or a refresh.
Arista built its business in data centre leaf and spine fabrics: 7050X switches with shallow shared buffers as leaves, and 7280R or 7800R switches with deep buffers where incast or speed changes need them. Juniper QFX switches run EVPN (Ethernet VPN) and VXLAN (Virtual Extensible LAN) fabrics, often designed and checked through Apstra, which also manages Cisco NX-OS, Arista EOS and SONiC (Software for Open Networking in the Cloud).
At the WAN (wide area network) and internet edge, Juniper MX routers are common for peering, transit and provider edge work, with SRX firewalls behind them. Arista 7280R switches also take full internet tables for peering. Cisco ASR and Catalyst 8000 routers hold the same roles in many estates.
Most estates end up mixed, through a merger, a refresh or a deliberate choice of a second supplier. I keep it manageable with one design, one source of truth and one set of tests. Between vendors I only use standard protocols: BGP (Border Gateway Protocol), OSPF (Open Shortest Path First), EVPN, LACP (Link Aggregation Control Protocol) and LLDP (Link Layer Discovery Protocol).
| Vendor | Operating system | Main families and roles |
|---|---|---|
| Arista | EOS (Extensible Operating System) | 7050X and 7060X leaf and spine; 7280R and 7800R deep buffer leaf, spine and peering; 7130 ultra low latency; 720XP and 750 campus. CloudVision manages them. |
| Juniper, part of HPE (Hewlett Packard Enterprise) | Junos OS and Junos OS Evolved | MX routers for the edge and provider edge; PTX for core and peering; ACX for metro and access; QFX data centre switches; EX campus switches; SRX firewalls. Mist and Apstra manage them. |
| Cisco, for comparison | IOS XE, NX-OS and IOS XR | Catalyst campus and Catalyst 8000 routers; Nexus data centre switches; ASR (Aggregation Services Router) and NCS (Network Convergence System) provider routers. |
HPE closed its purchase of Juniper on 2 July 2025, and Juniper now sits inside HPE Networking. In July 2025 Arista bought the VeloCloud SD-WAN business from Broadcom.
Price tension at renewal, less supply chain risk, and features one vendor does better: deep buffers, full table peering on a switch, low latency, or AI driven operations in the campus. Mergers bring a second vendor in whether anyone planned it or not.
Two sets of skills, tools, support contracts, software trains and security advisories to track. Every protocol that crosses the boundary needs interoperability testing, and the support desk needs runbooks for both.
One design and one source of truth, rendered into each vendor's syntax. Standard protocols only between vendors. The same automated tests after every change, whatever the platform. Clear ownership of each domain.
EOS (Extensible Operating System) looks like IOS at the prompt, but the design underneath is different. Each feature runs as a separate agent on Linux. Agents never talk to each other directly. They read and write a central, in memory database called Sysdb, and that one decision explains most of how EOS behaves when things fail.
Swipe sideways to see the whole diagram.
Agents never call each other. Each one writes what it knows into Sysdb and subscribes to what it needs, so one agent can fail and restart without the others noticing.
bash shell, run tcpdump on control plane traffic and use standard Linux tools, with the right privileges.Swipe sideways to see the whole diagram.
The BGP agent learns routes from its peer and writes them into Sysdb. The forwarding agent subscribes to them and programs the switch chip, which forwards user traffic in hardware.
If the BGP agent crashes, the routes it wrote are still in Sysdb and still in the chip. User traffic keeps flowing, because forwarding never depended on the agent being alive.
EOS notices the failed process and starts it again on its own. No reload, and no other agent is touched. The event is logged, so I can raise it with the vendor.
The new BGP agent reads its configuration and state back from Sysdb, rather than rebuilding everything from scratch. This is why Arista describes EOS processes as restartable.
The BGP sessions come back up. With graceful restart configured on both sides, the peer keeps forwarding to me while that happens. Then the routes refresh and the table converges.
| Classic IOS | Arista EOS | Junos OS Evolved | |
|---|---|---|---|
| Kernel | IOS was its own operating system; IOS XE now runs IOSd as a process on Linux | Unmodified Linux kernel | Native Linux |
| Where state lives | Inside each process | Sysdb, a central state database | A distributed data store (DDS) |
| If a process fails | Often a reload in classic IOS | The agent restarts and reads its state back | The application restarts and reloads its state from the DDS |
| Shell access | Guest shell on IOS XE | Full bash shell | Linux shell |
Junos OS Evolved moved Juniper to the same idea: applications publish and subscribe through a state store, and restart on their own. Classic Junos runs on FreeBSD.
At the prompt EOS feels like IOS: the same modes, many of the same show commands and the same habits. The differences are in how changes land and how much can be driven by software. I use configuration sessions for anything risky, eAPI or CloudVision for anything repeated, and automated tests after every change.
Swipe sideways to see the whole diagram.
In classic IOS and IOS XE, each command takes effect when I press Enter. A half typed change is live, and a mistake in line three can cut my session before line four arrives. IOS XE can still protect me: configure terminal revert timer 10, with the archive set up, rolls back unless I enter configure confirm.
EOS can work like IOS, but I prefer configuration sessions. configure session takes a copy of the running configuration, my edits go into the copy, and show session-config diffs shows exactly what will change. One commit applies it all, and commit timer rolls it back unless I confirm.
Junos never changes the live network as I type. Edits build a candidate configuration. show | compare shows the difference, commit check validates it, and commit applies it in one step. Junos keeps the last 50 commits, so rollback 1 gets me back to where I was.
switch# configure session vlan30
switch(config-s-vlan30)# vlan 30
switch(config-s-vlan30-vlan-30)# name APP-30
switch(config-s-vlan30-vlan-30)# exit
switch(config-s-vlan30)# show session-config diffs
+vlan 30
+ name APP-30
switch(config-s-vlan30)# commit timer 00:05:00
# Still connected and working? Make it permanent:
switch# show configuration sessions detail
switch# configure session vlan30 commitIf I lose access, the change rolls back after five minutes on its own. Committing a session replaces the running configuration, so any change someone made outside my session since I started it is lost. I keep sessions short for that reason.
management api http-commands
protocol https
no shutdown
# A JSON-RPC call to https://switch/command-api
{"jsonrpc": "2.0", "method": "runCmds", "id": "1",
"params": {"version": 1, "format": "json",
"cmds": ["show version", "show ip bgp summary"]}}eAPI accepts the same commands I type, so anything I can do by hand I can script. With "format": "json" the answer comes back as structured data rather than text.
| Tool | What it is | How I use it |
|---|---|---|
| CloudVision | Arista's management platform, on premises or as a cloud service | Inventory, configuration with change control, compliance against a template, and streamed telemetry with history |
| TerminAttr | The streaming agent on each switch | Sends state changes to CloudVision as they happen |
| eAPI | JSON-RPC (JavaScript Object Notation remote procedure calls) over HTTPS (Hypertext Transfer Protocol Secure), on the switch | Run any CLI command from code and get structured JSON back, with no screen scraping |
| AVD (Arista Validated Designs) | An open source Ansible collection | Builds every device configuration and its documentation from one set of YAML (YAML Ain't Markup Language) files for a leaf and spine design |
| ANTA (Arista Network Test Automation) | An open source Python test framework | Checks BGP, MLAG, interfaces and more after every change, with pass or fail results |
| cEOS and vEOS | EOS as a container or a virtual machine | Lab copies of a design, for testing a change or a release before it reaches hardware |
| Item | What I plan around |
|---|---|
| Release names | Each EOS release ends in F or M, for example 4.36.2F. F releases add features. M releases are in their maintenance phase and only get fixes. |
| Support length | Arista supports each major EOS release for up to 36 months from when it was first posted, moving from the feature phase to maintenance and then support only. |
| My standard | I pick an M release where one has the features I need, test it in a cEOS or vEOS lab, then pilot it before the estate moves. |
Arista's range splits into switches with shallow shared buffers, built for low cost and low latency, and switches with deep buffers, built to absorb bursts. Choosing between them is the main platform decision in an Arista fabric. Incast is the clearest reason: many senders answer one request at once, and the switch port facing the receiver has to queue what it cannot send.
Swipe sideways to see the whole diagram.
Senders bursting at once
Burst from each sender
128 senders, 1 MB each: the queue needs about 127 MB. The shallow buffer leaf drops about 95 MB even if one port could use all 32 MB. The deep buffer leaf absorbs the burst with about 1.6% of its buffer.
Shallow buffers are right for most leaves, because most traffic never queues for long. Deep buffers earn their cost where many senders converge on one port, such as storage and analytics clusters, or where speeds change, such as 100G into a slower WAN.
| Series | Role | What sets it apart |
|---|---|---|
| 7050X3 | Leaf | A fully shared 32 MB packet buffer and port to port latency from 800 ns, per the datasheet. The default choice for most leaves. |
| 7060X | Leaf and spine | High port counts for large fabrics, with shallow buffers like the 7050X. |
| 7280R3 | Leaf, spine and peering | Deep buffers with VOQ (virtual output queues): 2 GB to 24 GB per system, depending on the model. Takes full internet tables with FlexRoute for peering. |
| 7800R | Modular spine and core | The deep buffer architecture in a chassis, for the largest spines and data centre interconnects. |
| 7130 | Ultra low latency | Layer 1 switching in about 5 ns, with FPGA (field programmable gate array) applications. It came from Metamako, which Arista bought in 2018. See the low latency trading page. |
| 720XP and 750 | Campus | Access switches with PoE (Power over Ethernet), and a modular campus chassis, run from CloudVision. |
| VeloCloud | SD-WAN | Bought from Broadcom in July 2025, adding SD-WAN for branches. |
Figures are from Arista datasheets and announcements. Model by model limits change, so I check the current datasheet before I size a design.
In a VOQ switch each ingress port keeps a separate queue for every egress port. A packet only crosses the fabric when the egress port can take it, so one congested port never blocks traffic heading somewhere else. That is head of line blocking, and VOQ removes it.
Deep buffer switches cost more and use more power per port. A deep buffer can also hide congestion by adding delay instead of loss, which hurts latency sensitive traffic. I put deep buffers where the traffic pattern needs them, not everywhere.
Output discards on leaf ports, the queue length at busy times, and which hosts send in bursts. Arista's LANZ (Latency Analyzer) reports queue lengths from the hardware, which shows microbursts that five minute averages hide.
MLAG (multi chassis link aggregation) is Arista's version of Cisco vPC. Two switches keep separate control planes but present one LACP partner to a server or another switch, so both links forward and spanning tree blocks nothing. The design work is in the failures: what happens when an uplink, the peer link or a whole switch goes.
Swipe sideways to see the whole diagram.
Two leaves act as one switch towards the server, which bonds its two links with LACP (Link Aggregation Control Protocol). Each leaf forwards locally, the peer link keeps the MAC (media access control) tables in step, and a host on only one leaf is an orphan whose traffic may cross the peer link.
If leaf 1 loses every uplink, its MLAG ports stay up, so anything the server hashes to leaf 1 crosses the peer link to leaf 2. I size the peer link for that, or track the uplinks so leaf 1 takes its MLAG ports down when it has nowhere to send traffic.
The peer link carries the MLAG control messages. If it fails while both leaves are alive, each may decide it is alone, which is a split brain. I build the peer link from at least two links on different chips, and add a heartbeat over the management network so each leaf can tell a dead peer from a broken link.
While leaf 1 is down, leaf 2 carries everything. When leaf 1 returns, a reload delay keeps its MLAG ports down until it has learned the tables from its peer: 300 seconds by default on fixed configuration switches, longer on modular and deep buffer platforms.
vlan 4094
trunk group MLAG-PEER
no spanning-tree vlan-id 4094
!
interface Port-Channel10
description peer link
switchport mode trunk
switchport trunk group MLAG-PEER
!
interface Vlan4094
ip address 10.255.255.0/31
no autostate
!
mlag configuration
domain-id POD1
local-interface Vlan4094
peer-address 10.255.255.1
peer-link Port-Channel10
peer-address heartbeat 192.168.0.12 vrf MGMT
dual-primary detection delay 10 action errdisable all-interfaces
!
interface Port-Channel20
description server bond
switchport access vlan 30
mlag 20show mlag config-sanity lists any difference.show mlag reports the state as active, with the peer link and local interface up.| Approach | Control planes | Standard? | What I watch for |
|---|---|---|---|
| Cisco vPC (NX-OS) | Two | Cisco only | Peer link, keepalive and consistency checks. Detail on the data centre page. |
| Arista MLAG | Two | Arista only | Peer link sizing, the heartbeat, reload delay and show mlag config-sanity. |
| Juniper MC-LAG | Two, joined by ICCP (Inter Chassis Control Protocol) | Juniper only | Older designs. Juniper now steers new fabrics to EVPN multihoming. |
| EVPN multihoming (ESI) | Two or more | Yes, RFC 7432 | Works between vendors in principle; I still test it, because support for each route type varies. |
| Virtual Chassis, StackWise Virtual | One | Vendor specific | One control plane is simpler to run, but one software fault or upgrade touches every member. |
Juniper built Junos around a strict split. The RE (Routing Engine) runs the operating system, the routing protocols and the CLI. The PFE (Packet Forwarding Engine) forwards packets in hardware. One Junos runs across Juniper's routers, switches and firewalls, so the commands and the commit model are the same on an MX router, a QFX switch or an SRX firewall.
Swipe sideways to see the whole diagram.
A routing update climbs to the RE, the routing protocol daemon picks the best path, and the RE pushes the result down to the PFE as a forwarding table. Traffic passing through never needs the RE at all.
| Part | What runs there | What I need to know |
|---|---|---|
| Routing Engine (RE) | The Junos kernel, rpd (routing protocol daemon), mgd (management daemon), chassisd, the CLI and every routing table: inet.0 for IPv4, inet6.0 for IPv6, mpls.0 and more | It makes decisions but forwards almost nothing. Routers with two REs use GRES (graceful Routing Engine switchover) and NSR (nonstop active routing), and commit synchronize keeps both configurations the same. |
| Packet Forwarding Engine (PFE) | The forwarding table, firewall filters, policers and class of service, in hardware | It forwards at line rate on its own, and it keeps forwarding with its last table if the RE is busy or switching over. |
| The internal link | Routes and configuration down to the PFE, and host bound packets up to the RE | Everything aimed at the router itself crosses it, so I filter and police that traffic on lo0. |
firewall {
family inet {
filter PROTECT-RE {
term BGP {
from { source-prefix-list BGP-PEERS; protocol tcp; port bgp; }
then accept;
}
term SSH {
from { source-prefix-list MGMT-NETS; protocol tcp; destination-port ssh; }
then accept;
}
term ICMP {
from { protocol icmp; }
then { policer ICMP-1M; accept; }
}
term LAST { then { count DROPPED; discard; } }
}
}
}
# Applied to the loopback, in set form:
set interfaces lo0 unit 0 family inet filter input PROTECT-REA filter on lo0 applies to every packet the router delivers to itself, whichever interface it arrived on. The last term discards everything I did not name, so I build the list carefully and apply it with commit confirmed.
| Junos OS | Junos OS Evolved | |
|---|---|---|
| Base | FreeBSD | Native Linux |
| State | Inside each daemon | A distributed data store that applications publish to and subscribe from |
| If an application fails | The daemon restarts | The application restarts on its own and reloads its state |
| Where I meet it | Most MX, SRX and EX models | Newer routing and switching platforms; I check which one a model runs before I plan an upgrade |
| CLI and commit model | The same | The same |
R1 is the first build of a release, and service releases add -S and a number.The Junos commit model is the biggest habit change for anyone coming from IOS. Edits build a candidate configuration, and the network only changes when I commit. Every commit is kept, so I can see who changed what and step back to any of the last 50 versions. commit confirmed adds a safety net for remote changes.
Swipe sideways to see the whole diagram.
Every set or delete changes a private candidate copy. Nothing on the network changes, however many lines I type. Other users can see that the configuration is being edited, and configure private gives me my own copy.
show | compare prints exactly what will change against the active configuration. commit check validates the whole candidate, including references between sections, without applying anything.
commit confirmed 10 makes the candidate active and moves the old active configuration to rollback 1. The change is live, but Junos will undo it unless I confirm within 10 minutes.
If the change cuts my session, I cannot confirm it. When the timer runs out, Junos rolls back to the previous configuration on its own and tells every logged in user. Nobody needs to drive to the site.
If everything still works, I enter commit or commit check within the window. The timer stops and the change stays. I add commit comment with the change number, so show system commit tells the story later.
Make a change, compare it, check it and commit it, the way I would on a real router. The changes add a VLAN (virtual LAN), move a BGP peer to a new AS (autonomous system) number, or swap the filter that protects the router. Time runs ten times faster here, so a two minute timer lasts twelve seconds. The last one locks out SSH (Secure Shell) on purpose: commit it both ways and see the difference.
1. Edit the candidate
2. Run a command
No timer running
[edit]
punit@mx1# set vlans v30 vlan-id 30
[edit]
punit@mx1# show | compare
[edit vlans]
+ v30 {
+ vlan-id 30;
+ }
[edit]
punit@mx1# commit check
configuration check succeeds
[edit]
punit@mx1# commit confirmed 2
commit confirmed will be automatically rolled back in 2 minutes unless confirmed
commit complete
[edit]
punit@mx1# commit
commit completeWorked example: add a VLAN, compare, check, commit with a two minute timer, then confirm with a second commit.
Commit history, newest first
commit confirmed then commit: VLAN 30 addedinterfaces {
ge-0/0/0 {
mtu 9192;
unit 0 {
family inet {
address 10.0.0.1/31;
}
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0 interface-type p2p;
}
}
}set interfaces ge-0/0/0 mtu 9192
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/31
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
# The same configuration, two views:
# show configuration
# show configuration | display setI read configurations as a hierarchy and write changes as set lines, because set lines paste cleanly, diff cleanly and suit templates.
| Command | What it does |
|---|---|
show | compare | Shows the candidate against the active configuration. show | compare rollback 3 compares with an older version. |
commit check | Validates the candidate without applying it. |
commit confirmed 5 | Applies it, and rolls back after five minutes unless I commit again. |
commit comment "CHG1234" | Records why, for show system commit. |
rollback 1 then commit | Loads the previous version into the candidate, then makes it active. |
load merge terminal | Merges pasted configuration into the candidate; the pasted lines win any conflict. |
load override | Replaces the whole candidate with a file. |
load replace | Replaces only the sections marked replace: in the file. |
load set terminal | Runs pasted set lines one by one. |
load patch | Applies a difference, such as the output of show | compare from another router. |
commit synchronize | On routers with two Routing Engines, commits on both. |
Junos does all redistribution and filtering with one tool, the policy statement. Policies are applied as import or export chains on a protocol, a group or a neighbour. The rule that catches people out is what happens when no policy decides: the protocol's default policy does, and the BGP default is generous.
Swipe sideways to see the whole diagram.
This eBGP group exports with two policies: export [ BOGONS AGGREGATE ]. Junos evaluates them left to right, and each policy's terms top to bottom. If nothing accepts or rejects a route, the protocol's default policy decides.
A customer leaks 10.20.0.0/16 to me. Term 1 of BOGONS matches private space with orlonger and rejects it. A reject is a terminating action, so nothing after it is evaluated.
My aggregate 198.51.100.0/24 does not match BOGONS, so evaluation moves on. AGGREGATE matches it exactly and accepts it, so it is advertised.
A route learned from another peer matches neither policy. The default BGP export policy then advertises every active BGP route, so my transit provider receives a peer's route. That is a route leak.
My loopback is a direct route. It matches neither policy, and the default BGP policy only advertises BGP routes, so it is never sent. This is why Junos needs an explicit export policy for connected and static routes.
I end every eBGP export chain with a term that rejects everything else, so only what I meant to send leaves the router. IOS and EOS also send every best BGP route to every peer unless an outbound filter stops it.
policy-options {
prefix-list MY-AGGREGATES {
198.51.100.0/24;
}
policy-statement BOGONS {
term PRIVATE {
from {
route-filter 10.0.0.0/8 orlonger;
route-filter 172.16.0.0/12 orlonger;
route-filter 192.168.0.0/16 orlonger;
}
then reject;
}
}
policy-statement AGGREGATE {
term MINE {
from {
protocol aggregate;
prefix-list MY-AGGREGATES;
}
then accept;
}
term LAST {
then reject;
}
}
}
routing-options {
aggregate {
route 198.51.100.0/24;
}
}
protocols {
bgp {
group TRANSIT {
type external;
peer-as 64500;
neighbor 192.0.2.254;
export [ BOGONS AGGREGATE ];
}
}
}| Protocol | Default import | Default export |
|---|---|---|
| BGP | Accept every BGP route from configured neighbours | Advertise every active BGP route to every BGP speaker, within the usual iBGP rules |
| OSPF | Accept all OSPF routes. This cannot be changed | Reject everything: nothing outside OSPF is redistributed |
| IS-IS | Accept all IS-IS routes | Reject everything |
| Direct and static | Accept into the routing table | They are not protocols, so they reach BGP or OSPF only through an export policy |
From Juniper's documentation on default routing policies.
| Match type | What it matches, for 10.0.0.0/8 |
|---|---|
exact | Only 10.0.0.0/8 itself |
orlonger | 10.0.0.0/8 and anything longer inside it |
longer | Only longer prefixes, not the /8 itself |
upto /24 | 10.0.0.0/8 and longer prefixes down to /24 |
prefix-length-range /16-/24 | Prefixes inside 10/8 with a length from /16 to /24 |
Juniper's range is wide, but one Junos and one commit model run across it. The design choices I meet most are at the campus edge, where Virtual Chassis has been the way to stack EX switches, and in the data centre, where EVPN multihoming has taken over from stacking and MC-LAG.
Swipe sideways to see the whole diagram.
A Virtual Chassis joins switches through VCP (Virtual Chassis port) links into one logical switch, with one management address and one configuration. One member is the primary Routing Engine, one is the backup, and the rest are linecards. An EX4400 Virtual Chassis can have up to ten members.
If the primary fails, the backup takes over as primary, and another member is chosen as the new backup. With graceful Routing Engine switchover and nonstop bridging configured, forwarding carries on through the change. Ports on the failed member go down with it, so I spread uplinks and important hosts across members, as the second uplink shows.
If the ring is cut in two places, the members split into two groups. Split detection decides which group stays active, so the two halves never both claim the same identity. I run VCP links in a ring, never a chain, and keep each one on a separate path.
For new fabrics Juniper points to EVPN multihoming instead: two switches with their own control planes share an ESI (Ethernet segment identifier) towards the server. An upgrade or a software fault touches one switch, not the whole stack, and the method is a standard, so it can work between vendors.
| Family | Role | What I note |
|---|---|---|
| MX | Edge, provider edge, broadband and peering routers | The workhorse of many service provider and enterprise edges. Rich routing, MPLS and subscriber features. |
| PTX | Core and peering | High capacity routers for large backbones and peering points. |
| ACX | Metro and access | Smaller routers for metro rings and cell sites. |
| QFX | Data centre leaf and spine | EVPN VXLAN fabrics, usually designed and run from Apstra. |
| EX | Campus access, distribution and core | Virtual Chassis for stacking, run from Juniper Mist with wired assurance. |
| SRX | Firewalls | Branch to data centre security. How an SRX handles a packet is on the firewall platforms page. |
A cloud management and assurance service for Wi-Fi, wired and WAN. Marvis, its AI assistant, answers questions about client problems and points to likely causes across access points, switches and the WAN.
Intent based design and assurance for data centre fabrics. I describe the design once, and Apstra builds and checks the configuration. Apstra 6.1 qualifies Junos, Junos OS Evolved, Cisco NX-OS, Arista EOS and SONiC.
HPE closed its purchase of Juniper on 2 July 2025, and Rami Rahim, formerly Juniper's chief executive, now leads the combined HPE Networking business. Aruba and Juniper both make campus switches and Wi-Fi, so I watch the roadmap before committing an estate for ten years.
Most of my troubleshooting starts with the same dozen questions, whatever the vendor: what are my neighbours, what is in the routing table, what am I sending and receiving, and what changed. This table answers them in IOS XE, NX-OS, EOS and Junos. Type in the box to filter it.
Showing all 26 tasks.
| Task | Cisco IOS XE | Cisco NX-OS | Arista EOS | Juniper Junos |
|---|---|---|---|---|
| Routing table | show ip route | show ip route | show ip route | show route |
| One route | show ip route 10.1.1.0 | show ip route 10.1.1.0 | show ip route 10.1.1.0 | show route 10.1.1.0 |
| Whole configuration | show running-config | show running-config | show running-config | show configuration |
| One part of the configuration | show running-config | section router bgp | show running-config bgp | show running-config section bgp | show configuration protocols bgp |
| Configuration as set lines | No direct equivalent | No direct equivalent | No direct equivalent | show configuration | display set |
| Interfaces at a glance | show ip interface brief | show ip interface brief | show ip interface brief | show interfaces terse |
| Interface errors | show interfaces counters errors | show interface counters errors | show interfaces counters errors | show interfaces extensive ge-0/0/0 |
| Neighbours by LLDP | show lldp neighbors | show lldp neighbors | show lldp neighbors | show lldp neighbors |
| MAC address table | show mac address-table | show mac address-table | show mac address-table | show ethernet-switching table |
| ARP (Address Resolution Protocol) table | show ip arp | show ip arp | show ip arp | show arp no-resolve |
| BGP peers | show ip bgp summary | show bgp ipv4 unicast summary | show ip bgp summary | show bgp summary |
| Routes I send a BGP peer | show ip bgp neighbors 192.0.2.1 advertised-routes | show bgp ipv4 unicast neighbors 192.0.2.1 advertised-routes | show ip bgp neighbors 192.0.2.1 advertised-routes | show route advertising-protocol bgp 192.0.2.1 |
| Routes a BGP peer sends me | show ip bgp neighbors 192.0.2.1 routes | show bgp ipv4 unicast neighbors 192.0.2.1 routes | show ip bgp neighbors 192.0.2.1 routes | show route receive-protocol bgp 192.0.2.1 |
| OSPF neighbours | show ip ospf neighbor | show ip ospf neighbors | show ip ospf neighbor | show ospf neighbor |
| Port channels | show etherchannel summary | show port-channel summary | show port-channel | show lacp interfaces |
| A pair of switches as one | show stackwise-virtual | show vpc | show mlag | show virtual-chassis |
| Logs | show logging | show logging logfile | show logging | show log messages |
| Save the configuration | copy running-config startup-config | copy running-config startup-config | copy running-config startup-config | commit (saves as it applies) |
| Compare running with saved | show archive config differences | show running-config diff | show running-config diffs | show | compare |
| Undo a change | configure replace flash:backup.cfg | rollback running-config checkpoint CP1 | configure replace flash:backup.cfg | rollback 1, then commit |
| Capture traffic to the CPU (central processing unit) | monitor capture (EPC) | ethanalyzer local interface inband | tcpdump interface Ethernet1 | monitor traffic interface ge-0/0/0 |
| Ping from a source | ping 10.0.0.2 source Loopback0 | ping 10.0.0.2 source-interface loopback0 | ping 10.0.0.2 source Loopback0 | ping 10.0.0.2 source 192.0.2.1 |
| Filter the output | | include BGP | | include BGP | | include BGP | | match BGP |
| A show command while configuring | do show ip route | show ip route | show ip route | run show route |
| Linux shell | guestshell run bash | run bash | bash | start shell |
| Hardware and software | show version | show version | show version | show chassis hardware |
Interface names, addresses and the checkpoint name are examples. On NX-OS, run bash needs feature bash-shell first. Junos pipes use match rather than include, and Junos has | display set, which no other CLI here offers.
From IOS to NX-OS and EOS almost everything does: modes, show commands, interface ranges and the way a running configuration reads. EOS was built to feel familiar, and it shows.
On Junos, configuration mode changes nothing until I commit, show becomes run show while configuring, and filters, policies and redistribution are all policy statements rather than route maps.
Compare before applying, apply with a timer, record a comment, and check with the same tests on every platform afterwards. Junos makes these the default; on the others I make them a standard.
More on each Cisco platform: IOS and IOS XE and NX-OS.
Standard protocols interoperate, but each vendor fills the gaps in the standards with its own defaults. Most of the faults I see at a vendor boundary are two correct configurations that mean different things. I list them in the design, so they are settled once rather than found one at a time.
Swipe sideways to see the whole diagram.
Both interfaces are set to mtu 9192. On Junos the interface MTU (maximum transmission unit) includes the 14 byte Ethernet header, so the IP (Internet Protocol) MTU is 9178. On an IOS XE router the interface MTU is the IP packet size, so the IP MTU is 9192.
OSPF hello packets do not carry the MTU, so the two routers see each other and reach 2-Way. Nothing looks wrong yet.
The database description (DBD) packets carry the interface MTU. RFC 2328 says a router rejects a DBD that announces a larger IP MTU than it can accept. Junos receives 9192 against its own 9178 and ignores the packet.
The exchange never completes. One side typically sits in ExStart and the other in Exchange, retrying until someone looks. Small pings work, so the link looks healthy.
I agree the IP MTU in the design and set each platform to match it: on Junos, mtu 9206 on the interface or family inet mtu 9192 on the unit. Ignoring the MTU check would hide the fault, and large packets would still be lost.
| Area | What differs | What I do |
|---|---|---|
| OSPF cost | IOS and Junos default to a reference bandwidth of 100 Mb/s, so every link of 100 Mb/s or faster costs 1. NX-OS defaults to 40 Gb/s. A mixed area can pick paths nobody intended. | Set one reference bandwidth on every router in the design, or set costs explicitly on every link. |
| MTU | Junos counts the Ethernet header in the interface MTU. IOS XE routers count only the IP packet. | Agree the IP MTU in the design and translate it per platform. Test with large pings that are not allowed to fragment. |
| BGP export | Junos advertises only active BGP routes by default, so connected and static routes need a policy. It also passes every peer's routes on, as IOS and EOS do. | An explicit export policy with a final reject on every eBGP session, on every vendor. |
| BGP timers | Junos defaults to a 90 second hold time; IOS defaults to 180. The lower offer wins, so detection time depends on who the peer is. | Set timers explicitly, and use BFD (Bidirectional Forwarding Detection) where fast failover matters. |
| Link aggregation | Junos creates no ae interfaces until chassis aggregated-devices ethernet device-count is set. | Put the device count in the base template of every Junos box. |
| ARP and MAC timers | Junos ages ARP entries after 20 minutes and IOS after four hours, while MAC entries usually age after five. If ARP outlives the MAC entry, the switch floods unicast traffic until the host speaks again. | Keep ARP timeouts shorter than MAC aging on gateways, and watch for unknown unicast flooding. |
| Change model | Junos changes nothing until commit. An EOS session commit replaces the running configuration, including changes made by others since the session began. | Write the change procedure per platform, and never mix live edits with session based changes on the same box. |
| EVPN | RFC 9136 allows more than one model for IP prefix routes, so both ends must use the same one. Multihoming and route type support also vary by release. | Prove every EVPN feature between the exact releases in a lab before it reaches production. |
Each of these has a test in my post change checks: OSPF costs per link, MTU with large pings, routes advertised per peer, timers per session, LACP state and flooding counters.
Faults on EOS and Junos look like faults anywhere: an interface that will not come up, a neighbour that will not form, routes that do not arrive. The causes are often specific to the platform or to the boundary between vendors. Choose a symptom to see where it sits, what I see and what I run.
Swipe sideways to see the whole diagram.
ae0 never appears on Junos. Junos creates no aggregated Ethernet interfaces until a device count is set, so the configuration commits but the interface does not exist. I add set chassis aggregated-devices ethernet device-count 8 to the base template, commit, and check LACP with show lacp interfaces.
My change vanished ten minutes later. It went in with commit confirmed and nobody confirmed it, so Junos rolled it back as designed. If the change was good, I apply it again and confirm with commit inside the window. If my session had dropped, the rollback just saved a site visit.
A colleague's change disappeared on EOS. Committing a configuration session replaces the running configuration with the session copy, so anything changed outside the session after it started is lost. I keep sessions short, agree one change at a time per switch, and restore the lost lines from the change record.
MLAG ports stay down after a reload. The reload delay is holding them down while the switch learns its tables from its peer: 300 seconds by default on fixed switches, longer on others. If they stay down after that, show mlag config-sanity lists settings that differ between the peers.
A Virtual Chassis member is missing. The usual causes are a VCP cable or optic fault, a port not set as a VCP, or a member on a different Junos release. I check the VCP port states, the member's software version and the ring, and I keep spare VCP cables on site.
OSPF stuck in ExStart with a Cisco router. Both sides show the same MTU number, but Junos counts the Ethernet header and IOS XE does not, so the database description packets are rejected. I match the IP MTU, as the interoperability section shows, and prove it with large pings that may not fragment.
BGP is up, but Junos advertises nothing. The routes I expected are connected or static, and the default BGP export policy only sends active BGP routes. I write an export policy that names the prefixes, end it with a reject, and check again with the same command.
Traffic takes the long way after a Nexus joins. NX-OS defaults to a 40 Gb/s reference bandwidth while IOS and Junos default to 100 Mb/s, so the same link has different costs depending on who calculates it. I set one reference bandwidth across the area, or set costs explicitly.
Unicast flooding every few minutes. A gateway still has the host in its ARP table, but the switch has aged out its MAC entry, so frames to that host flood every port in the VLAN. I bring the ARP timeout below the MAC aging time on the gateway, or raise MAC aging where it is safe.
| What I need | Arista EOS | Juniper Junos |
|---|---|---|
| Everything the vendor will ask for | show tech-support | request support information | save /var/tmp/rsi.txt |
| What changed, and when | show configuration sessions detail | show system commit, then show | compare rollback 1 |
| Process crashes | Restarted agents in show logging | show system core-dumps |
| Hardware alarms | show logging and CloudVision events | show chassis alarms |
| Traffic to the control plane | tcpdump interface Ethernet1 | monitor traffic interface ge-0/0/0 |
I change one thing at a time, re run the same checks after each change, and record the cause for problem management. My general method, with worked faults, is on the troubleshooting page.
A second vendor usually arrives through a refresh, a merger or a data centre build. The technology is rarely the hard part. The work is in agreeing why, deciding which domains each vendor owns, settling the boundaries between them and making sure the support teams can run both. I follow the same path every time.
Swipe sideways to see the whole diagram.
I start by writing down why a second vendor is coming in: cost, supply risk, a feature or an inherited estate. Then I agree which domains each vendor will own, who decides, and what would make us stop. A RACI (responsible, accountable, consulted, informed) chart records who signs off each decision.
Requirements cover what each boundary must carry and how well: convergence times, upgrade windows, monitoring and access control. They also cover the people side. Operations must be able to run both platforms at three in the morning, so training and runbooks are requirements, not extras.
I map the estate as it is: inventory and releases, every protocol that will cross a vendor boundary, and the defaults each side uses today. A vendor neutral tool such as Batfish reads the configurations of both vendors and answers reachability and policy questions before anything changes.
The high level design sets the domains, the boundary protocols and every default that must match: MTU, OSPF reference bandwidth, timers and export policy. The low level design renders one source of truth into templates for EOS, Junos and IOS, with a test plan agreed before the build.
I build the boundaries in a lab with the exact releases, using virtual EOS and Junos where hardware is short, and break them on purpose: links, peers and upgrades. Then one pilot site carries real traffic before rollout in waves through change control, each with a tested rollback.
Before handover, both platforms report into the same monitoring, and the service desk has runbooks that start with the same questions on either vendor. Escalation paths, contract numbers and spares are agreed for each, and hypercare ends only when the agreed criteria have held for a set period.
Two vendors means two release trains, two sets of advisories and two hardware roadmaps. I plan upgrades by role, retest every boundary after each one, and review the roadmaps each year, including how Juniper settles inside HPE alongside Aruba.
What it must do.
How well it must do it, with a number wherever one can be agreed.
Numbers are typical starting points. Each organisation agrees its own.
| Tool or source | What it tells me |
|---|---|
| LLDP and CDP (Cisco Discovery Protocol) neighbour tables | What connects to what, across vendors |
| NetBox or the current CMDB (configuration management database) | Inventory, addressing and intended state |
| Batfish | Vendor neutral analysis of configurations: reachability, routing policy and differences |
| CloudVision | Arista inventory, configuration compliance and streamed state |
| Juniper Mist and Apstra | Juniper campus and fabric state, where they are already in use |
| SNMP (Simple Network Management Protocol) and IPFIX (IP Flow Information Export) | Utilisation and traffic across vendor boundaries |
show tech-support and request support information | A full snapshot of each platform before any change |
Most faults at a vendor boundary are two correct configurations that mean different things. I check the boundary defaults early, once I have proved where the fault sits.
show system commit on Junos, configuration sessions on EOS, the archive on IOS.ae device count on Junos| Layer | What I check |
|---|---|
| 1 · Physical | Optics, cables and FEC settings agreed on both ends. show interfaces transceiver on EOS, show interfaces diagnostics optics ge-0/0/0 on Junos. |
| 2 · Data link | LACP state, VLANs and MTU, and the health of MLAG or Virtual Chassis. show lacp interfaces, show mlag, show virtual-chassis. |
| 3 · Network | OSPF costs and adjacencies, and the routes each side really sends. show route advertising-protocol bgp on Junos, show ip bgp neighbors ... advertised-routes on EOS. |
| 4 · Transport | BGP sessions over TCP (Transmission Control Protocol) port 179, hold times and BFD. show bgp neighbor on Junos, show ip bgp neighbors on EOS. |
| 5 to 7 · Application | Management access: SSH, eAPI, NETCONF (Network Configuration Protocol) and TACACS+ (Terminal Access Controller Access Control System Plus), and the filters protecting each control plane. |
My general method, with worked faults, is on the troubleshooting page.
A mixed estate only works if the people running it are as comfortable with the second vendor as with the first. I plan support before the first box arrives.
Who owns each domain: service desk, network operations centre (NOC), engineering and each vendor's support, with escalation times in the contracts.
Both vendors stream or poll into the same monitoring, with the same alert names and thresholds, so a fault looks the same on either platform.
Step by step guides for the common faults on each platform, each starting with the same questions and the commands from the translator above.
Every change through change control, compared before it is applied, applied with a timed rollback, and checked with the same automated tests.
Arista TAC (Technical Assistance Center) and JTAC (Juniper Technical Assistance Center), with the support bundles each one asks for collected before the case is opened.
Spares on site or on contract for each platform, including optics and stacking cables, with a tested RMA (return merchandise authorisation) process.
Two vendors double the lifecycle work, so I plan it from the start rather than discover it at the first advisory.
My production work has been on Cisco, Palo Alto, Check Point, FortiGate, F5, Meraki and Aruba, rather than Arista or Juniper. These are the projects closest to this page: estates with several vendors, provider routing at the internet edge, and data centre fabrics. The skills carry straight across: protocols, design, change control and testing do not depend on the badge on the box.
Produced multi vendor SD-WAN and SD-Access designs for enterprise clients, as lead architect on network, cloud and data centre programmes from discovery to operational handover.
Cloud, SDN (software defined networking), disaster recovery and security architecture on Nexus, Viptela, Palo Alto, F5 and Aruba, for the firm's enterprise clients.
Public sector network modernisation on Meraki, Nexus, FortiGate and Check Point, leading 7 engineers and third party suppliers.
A tier 3 data centre and managed infrastructure for over 300 customer sites on Cisco ACI (Application Centric Infrastructure) and Nexus. Managed provider IP space and AS numbers with RIPE NCC (Réseaux IP Européens Network Coordination Centre), including RPKI (Resource Public Key Infrastructure) ROAs (route origin authorisations).
Defined routing security policy for the peering and transit edge: RPKI and ROA origin validation and RIPE NCC resource governance. The export policy rules on this page come from the same thinking.
Completed the Cumulus Linux Essentials and SONiC Essentials courses: two more network operating systems built on Linux, managed the way EOS invites, through files, APIs and automation.
Backed by CCNP (Cisco Certified Network Professional) Enterprise, a pass in the CCIE (Cisco Certified Internetwork Expert) Routing and Switching written exam, and NVIDIA courses in Cumulus Linux and SONiC. See all credentials
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.