Hi all
I had to install some switches this week for a customer. I thought it might be interesting to share the config and explain why I did what.
The config was for a company with not the most network knowledge, so I tried to simplify some things. I will explain further on.
The config itself:
system {
hostname SW-EDGE-LOC;
auto-snapshot;
time-zone America/New_York;
root-authentication {
encrypted-password ""; ## SECRET-DATA
}
name-server {
x.x.x.x;
y.y.y.y;
}
login {
user admin {
uid 2000;
class super-user;
authentication {
encrypted-password ""; ## SECRET-DATA
}
}
}
services {
ssh {
connection-limit 5;
rate-limit 5;
}
web-management {
https;
}
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
commit synchronize;
ntp {
server x.x.y.y;
}
}
chassis {
redundancy {
graceful-switchover;
}
aggregated-devices {
ethernet {
device-count 1;
}
}
alarm {
management-ethernet {
link-down ignore;
}
}
}
interfaces {
ge-0/0/0 {
description "Uplink";
ether-options {
802.3ad ae0;
}
}
ge-0/0/1 {
description "Uplink";
ether-options {
802.3ad ae0;
}
}
ge-0/0/2 {
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members lan;
}
storm-control default;
}
}
}
/* I deleted the other interfaces to make it more readable */
ae0 {
description "Uplink";
aggregated-ether-options {
lacp {
active;
periodic fast;
}
}
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members all;
}
}
}
}
irb {
unit 999 {
family inet {
address 10.250.99.11/24;
}
}
}
}
forwarding-options {
storm-control-profiles default {
all;
}
}
routing-options {
nonstop-routing;
static {
route 0.0.0.0/0 next-hop 172.16.53.254;
}
}
protocols {
lldp {
interface all;
}
lldp-med {
interface all;
}
igmp-snooping {
vlan default;
}
layer2-control {
nonstop-bridging;
bpdu-block {
disable-timeout 900;
}
}
rstp {
interface ge-0/0/2 {
edge;
}
interface ge-0/0/3 {
edge;
}
/* I deleted the other interfaces to make it more readable */
bpdu-block-on-edge;
}
}
virtual-chassis {
preprovisioned;
no-split-detection;
member 0 {
role routing-engine;
serial-number xxxxxxxxxxxx;
}
member 1 {
role routing-engine;
serial-number yyyyyyyyyyyyy;
}
}
vlans {
lan {
vlan-id 100;
}
mgmt {
vlan-id 999;
l3-interface irb.999;
}
}
poe {
interface all;
}
Alright so we have the basics like hostname, ntp, dns, etc. I’m going into some newer options
auto-snapshot
Juniper documentation says: Statement introduced in Junos OS Release 12.3 for EX Series switches.
Okay so not that new. Anyway, it’s on by default now. I left it in the config. I don’t know if it works (I guess it does). But this is a handy feature then.
Junos devices usually have a primary and a backup partition for when something goes wrong. With the snapshot command you sync those partitions. Like so:
request system snapshot
request system snapshot slice alternate
syslog
I left it at the default. Maybe you can delete the “file interactive-commands” to save your flash a bit. But in a good setup I would recommend to send everything to a syslog server. However keep the file messages. Because if you lose network connectivity because of issues with your switch, you can troubleshoot via the messages log.
commit synchronize
This is recommended for Virtual chassis configuration and any device with multiple routing-engines (master/backup). It actually automatically issues the “commit synchronize” command on any commit you execute.
chassis redundancy graceful switchover
From the Juniper documentation:
The graceful Routing Engine switchover (GRES) feature in Junos OS enables a router with redundant Routing Engines to continue forwarding packets, even if one Routing Engine fails. GRES preserves interface and kernel information. Traffic is not interrupted. However, GRES does not preserve the control plane
It will allow us to switchover routing engines with the least impact. It will also monitor the routing engines and switchover automatically when it’s needed. This without restarting the pfe’s. So it should be the least impacted switchover possible.
I would recommend this when using virtual chassis configurations.
Reference: https://www.juniper.net/documentation/en_US/junos/topics/concept/gres-overview.html
aggregated devices
This is always a bit strange for people not used to work with Juniper hardware. We need to preprovision the aggregated interfaces.
If your aggregated doesn’t work, it’s one of the first things to check. If you change the value, you should be able to see the ae interfaces when running the show interfaces command.
set chassis aggregated-devices ethernet device-count x
alarm management-ethernet
The Junos device will give an alarm when the management ethernet interface is not connected.
To disable this alarm you can configure following option:
set chassis alarm management-ethernet link-down ignore
interfaces
There are only a few things I want to say about the interfaces configuration:
- Since ELS it is “interface-mode access” and not “port-mode access”
- I put the vlan members on the interface. It is compatible with the WebGUI and in my opinion also the most readable
- Storm control is on default settings
nonstop-routing
When you want to use GRES (graceful switchover) it needs to be on. The NSR (non stop routing) will run the rpd on the backup routing engine and sync the routes. This way the routing engine can failover in a situation that it is necessary.
Best practice to keep this on
Reference: https://www.juniper.net/documentation/en_US/junos/topics/concept/nsr-overview.html
protocols
I kept most protocols on default settings. In this situation there were no IP phones or special multicast devices.
layer2-control
nonstop-bridging
Nonstop-bridging is also an option necessary for GRES
From the Juniper documentation:
NSB operates by synchronizing all protocol information for NSB-supported Layer 2 protocols between the master and backup Routing Engines. If the switch has a Routing Engine switchover, the NSB-supported Layer 2 protocol sessions remain active because all session information is already synchronized to the backup Routing Engine. Traffic disruption for the NSB-supported Layer 2 protocol is minimal or nonexistent as a result of the switchover.
Reference: https://www.juniper.net/documentation/en_US/junos/topics/concept/nonstop-bridging-ex-series.html
It’s necessary so I would always turn it on when you have more than 1 switch. It also requires GRES and commit sync to be enabled (which we already enabled in our config)
bpdu-block
Further on we are going to configure bpdu-block-on-edge. Under layer2-control we need to configure how long the port will be inactive.
You can manually bring the port up again with the following command.
clear error bpdu interface (all | interface-name)
rstp
I put all the interfaces in “edge”. I don’t like to configure point to point interfaces or anything, when it’s not needed.
Putting the interfaces in edge however is a minimum. It will put out BPDU’s which can help us find loops and mitigate them.
bpdu-block-on-edge
I would highly recommend to enable this. It will only work if you configured your interfaces as edge under RSTP. otherwise it will not work.
However I think you can configure it also under layer2-protocols bpdu-bock interface
The switch will now shutdown the interface when it receives a bpdu. To enable the interface again execute the following command
clear error bpdu interface (all | interface-name)
virtual-chassis
I like to preprovision the virtual chassis, cause it makes things very clear. You don’t need to fiddle with the member numbers later.
It’s also a requirement if you want to use Nonstop Software Upgrade (NSSU). So if you configure it like this, the VC is ready for it.
In our 2 member VC both members will be routing-engine. The members we will add later have to be line-cards. It is however not necessary to have member 0 and member 1 be routing engines.
no split detection
No split is necessary for 2 member VC’s. If you have more than two, you probably need to remove this setting.
If you don’t configure no split detection on this VC. The VC will disable the master RE when the backup RE fails. This is to prevent split brain situations.
If the Master RE fails however, the backup will take on the master role.
When you configure the no split detection, the switches will detect no split. So they remain up. If the master loses the backup it will stay master and keep working. If the backup loses the master, it will become master and stay working.
More information about VC splits: https://www.juniper.net/documentation/en_US/junos/topics/concept/virtual-chassis-ex4200-split-merge.html
Conclusion
As this is a small configuration, it already contains a lot of special (Juniper) features. Things you probably didn’t know when you first picked up a Juniper switch.
There are a lot of other features you should configure though, but were not necessary in this case. SNMP, syslog and switch security for example.
I will write about those features later.
Thanks for reading.