Tag Archives: EX Series

VRRP Between Cisco and Juniper Switches

For one of the many projects that I’ve been assigned at work, I got the chance to join the InfoSec Team and help design and configure their second site for their expanding network. Of course, any network engineer always wants to design and provision a network, they can call his/her own! So we were put on a plane and off to Sunny Glasgow, with a plan of attack and 4 days to get this first phase done.

To say it was a busy few days would be the understatement of the year, long days and nights on the data floor stacking, racking, patching and configuring. We had hard deadline to get everything configured and remotely accessible, so making sure the network was sorted was key! But one good thing was that the data floor was in one of our office buildings and it had a window! Inserts shameless instagram plug!

 

 
For those who haven’t worked in a dedicated datacentre, you wouldn’t understand how great natural light and view can be after 10 hours of work haha
In the end, phase one was completed on time (just), with everything working as expected. Inserts another shameless instagram plug

 


Missing from that post above was a Cisco 3750X that was used for vendor redundancy as part of the network. The guys had a HP c7000 Blade Chassis with 2 HP Virtual Connects Chassis Switches which needed to be connected to the edge switches, a Juniper EX4300 and the Cisco. This meant that I would have to span a vlan across two switches and share a default gateway between them. With this being the case, I had use a First-hop Redundancy Protocol (FHRP) and as I was using a multiple vendor topology, the FHRP of choice would have to be VRRP (Virtual Router Redundancy Protocol).

VRRP is best defined in RFC3768:

The Virtual Router Redundancy Protocol (VRRP) is designed to eliminate the single point of failure inherent in the static default routed environment. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail-over in the forwarding responsibility should the Master become unavailable.

As VRRP is an open standard, it’s interoperable between both Cisco and Juniper devices. If it were just using Cisco devices, I would have had a choice between VRRP or HSRP (Hot Standby Router Protocol). HSRP works similar as VRRP but it’s a Cisco Proprietary Protocol, which means it’s only compatible between Cisco devices. You can see more detail on HSRP in RFC2281

Due to the upstream routing requirements and the EX4300 being higher specced switch, it was decided that the EX4300 was going to be the Master. The topology I was working with is shown below.

VRRP Topology
With that all explained, Let’s get cracking 😀

Juniper Configuration

Physical Interface ConfigurationIntegrated Routing & Bridging ConfigurationVlan Configuration
xe-0/2/3 {
    description "TRUNK to Edge Cisco";
    enable;
    unit 0 {
        family ethernet-switching {
            interface-mode trunk;
            vlan {
                members reith;
            }
        }
    }
}
irb {
    enable;
    unit 100 {                          
        enable;
        family inet {
            address 10.199.6.1/23 {
                vrrp-group 1 {
                    virtual-address 10.199.7.254;
                    priority 150;
                    no-preempt;
                    accept-data;
                }
            }
        }
    }
}
vlans {
    reith {
        vlan-id 100;
        l3-interface irb.100;
    }
}
Note
With the irb configuration, under the vrrp-group stanza, I had to add the command accept-data. Adding this command it will enable the master router to accept all packets destined for the Virtual IP (VIP) address. If this isn’t enabled when the EX4300 is set/becomes master, it will not respond to any packets sent to the VIP address!

Cisco Configuration

Physical Interface t1/1/2Routed VLAN Interface
egde-cisco#show run int t1/1/2 
Building configuration...

Current configuration : 137 bytes
!
interface TenGigabitEthernet1/1/2
 description "TRUNK to Edge Juniper"
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100
 switchport mode trunk
end
egde-cisco#show run int vlan100
Building configuration...

Current configuration : 176 bytes
!
interface Vlan100
 ip address 10.199.6.2 255.255.254.0
 vrrp 1 description "TRUNK to Edge Juniper"
 vrrp 1 ip 10.199.7.254
 no vrrp 1 preempt
 vrrp 1 priority 145
end

Juniper Verification

Depending on the level of detail you want to go into, you can run of any of these commands show vrrp summary, show vrrp detail or show vrrp extensive. I mostly use show vrrp summary or show vrrp detail as ive found (most of time) that you get want you need from either useless you’ve had a big issue and extensive detail is needed!

Show VRRP SummaryShow VRRP Detail
[email protected]> show vrrp summary     
Interface     State       Group   VR state       VR Mode    Type   Address 
irb.100       up              1   master          Active    lcl    10.199.6.1         
                                                            vip    10.199.7.254
[email protected]> show vrrp detail       
Physical interface: irb, Unit: 100, Address: 10.199.6.1/23
  Index: 547, SNMP ifIndex: 567, VRRP-Traps: disabled, VRRP-Version: 2
  Interface state: up, Group: 1, State: master, VRRP Mode: Active
  Priority: 150, Advertisement interval: 1, Authentication type: none
  Advertisement threshold: 3, Computed send rate: 0
  Preempt: no, Accept-data mode: yes, VIP count: 1, VIP: 10.199.7.254       
  Advertisement Timer: 0.064s, Master router: 10.199.6.1
  Virtual router uptime: 19:40:12, Master router uptime: 19:40:04
  Virtual Mac: 00:00:5e:00:01:01 
  Tracking: disabled

Cisco Verification

On a Cisco, you can check VRRP status by running the command show vrrp

egde-cisco#show vrrp 
Vlan100 - Group 1  
"TRUNK to Edge Juniper"
  State is Backup  
  Virtual IP address is 10.199.7.254
  Virtual MAC address is 0000.5e00.0101
  Advertisement interval is 1.000 sec
  Preemption disabled
  Priority is 145 
  Master Router is 10.199.6.1, priority is 145 
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.433 sec

And with that we are done! Confirmed VRRP is working as expected! To be honest, before getting started I was a little worried that ill be running into plenty of issues running cross vendor but it was pretty straightforward, which is always good when you’re under the gun 🙂

Share this:
Share

Virtual Chassis Upgrade with Minimal Downtime

At work we were looking to do a firmware upgrade of our junos going from 12.3 to 13.2X and we got a few VC switches. The plan was to use the NSSU method so that we didn’t get any downtime however, when doing testing I would kick off the NSSU and the backup member would upgrade, reboot and come up as expected:

{master:0}
[email protected]> ...p/jinstall-ex-4200-13.2X51-D35.3-domestic-signed.tgz    
Chassis ISSU Check Done
[Dec 18 04:32:13]:ISSU: Validating Image
[Dec 18 04:32:41]:ISSU: Preparing Backup RE
[Dec 18 04:32:42]: Installing image on other FPC's along with the backup

[Dec 18 04:32:42]: Checking pending install on fpc1
[Dec 18 04:33:41]: Pushing bundle to fpc1
NOTICE: Validating configuration against mchassis-install.tgz.
NOTICE: Use the 'no-validate' option to skip this if desired.
WARNING: A reboot is required to install the software
WARNING:     Use the 'request system reboot' command immediately
[Dec 18 04:34:42]: Completed install on fpc1
[Dec 18 04:34:53]: Backup upgrade done
[Dec 18 04:34:53]: Rebooting Backup RE

Rebooting fpc1
[Dec 18 04:34:54]:ISSU: Backup RE Prepare Done
[Dec 18 04:34:54]: Waiting for Backup RE reboot

After an hour of looking at this on the master, I consoled into the backup to see what had booted and was up, and I clearly had an issue. I aborted the NSSU and checked to see what was going; the backup member had upgraded and had connected with the master:

{master:0}
[email protected]> show version 
fpc0:
--------------------------------------------------------------------------
Hostname: EX4200-A
Model: ex4200-48t
JUNOS Base OS boot [12.3R5.7]
JUNOS Base OS Software Suite [12.3R5.7]
JUNOS Kernel Software Suite [12.3R5.7]
JUNOS Crypto Software Suite [12.3R5.7]
JUNOS Online Documentation [12.3R5.7]
JUNOS Enterprise Software Suite [12.3R5.7]
JUNOS Packet Forwarding Engine Enterprise Software Suite [12.3R5.7]
JUNOS Routing Software Suite [12.3R5.7]
JUNOS Web Management [12.3R5.7]
JUNOS FIPS mode utilities [12.3R5.7]

fpc1:
--------------------------------------------------------------------------
Hostname: EX4200-A
Model: ex4200-48t
JUNOS EX  Software Suite [13.2X51-D35.3]
JUNOS FIPS mode utilities [13.2X51-D35.3]
JUNOS Online Documentation [13.2X51-D35.3]
JUNOS EX 4200 Software Suite [13.2X51-D35.3]
JUNOS Web Management [13.2X51-D35.3]

I thought this was very odd so I checked the logs to see if anything was out of the norm and saw that VCP ports had come up however, the attempts to backup member had timed out :/

show log messages output
[email protected]> show log messages | last 100    
Dec 18 04:44:33  EX4200-A /kernel: tcp_timer_rexmt: Dropping socket connection due to error: 65
Dec 18 04:44:36  EX4200-A last message repeated 4 times
Dec 18 05:01:30  EX4200-A chassism[1280]: cm_ff_ifd_disable: fast failover disabled for internal-0/26
Dec 18 05:01:30  EX4200-A chassism[1280]: cm_ff_ifd_disable: fast failover disabled for internal-0/27
Dec 18 05:01:30  EX4200-A vccpd[1282]: ifl vcp-0.32768 set up, ifl flags 0, flags 1
Dec 18 05:01:30  EX4200-A vccpd[1282]: interface vcp-0 came up
Dec 18 05:01:30  EX4200-A chassism[1280]: cm_ff_ifd_disable: fast failover disabled for internal-1/26
Dec 18 05:01:30  EX4200-A vccpd[1282]: ifl vcp-1.32768 set up, ifl flags 0, flags 1
Dec 18 05:01:30  EX4200-A vccpd[1282]: interface vcp-1 came up
Dec 18 05:01:30  EX4200-A chassism[1280]: cm_ff_ifd_disable: fast failover disabled for internal-1/27
Dec 18 05:01:30  EX4200-A vccpd[1282]: Member 0, interface vcp-1.32768 came up
Dec 18 05:01:30  EX4200-A vccpd[1282]: Member 0, interface vcp-0.32768 came up
Dec 18 05:01:30  EX4200-A vccpd[1282]: Member 1, interface vcp-1.32768 came up
Dec 18 05:01:30  EX4200-A vccpd[1282]: Member 1, interface vcp-0.32768 came up
Dec 18 05:01:36  EX4200-A chassism[1280]: cm_ff_vcp_port_add: fast failover received VCP port add on dev 0 port 26
Dec 18 05:01:36  EX4200-A chassism[1280]: cm_ff_vcp_port_add: fast failover received VCP port add on dev 0 port 27
Dec 18 05:01:36  EX4200-A chassism[1280]: cm_ff_vcp_port_add: fast failover received VCP port add on dev 1 port 26
Dec 18 05:01:36  EX4200-A chassism[1280]: cm_ff_vcp_port_add: fast failover received VCP port add on dev 1 port 27
Dec 18 05:01:36  EX4200-A chassism[1280]: CM_CHANGE: Member 0->0, Mode M->M, 0M 1B, GID 0, Master Unchanged, Members Changed
Dec 18 05:01:36  EX4200-A chassism[1280]: CM_CHANGE: 0M 1B
Dec 18 05:01:36  EX4200-A chassism[1280]: CM_CHANGE: Signaling license service
Dec 18 05:01:36  EX4200-A chassism[1280]: mvlan_member_change_add: member id 1 (my member id 0, my role 1)
Dec 18 05:01:36  EX4200-A chassism[1280]: mvlan_ifl_create: Creating ifl, name bme0, subunit 32770
Dec 18 05:01:36  EX4200-A chassism[1280]: mvlan_rts_ifl_op: IFL idx is 8 is created
Dec 18 05:01:39  EX4200-A chassisd[1298]: CHASSISD_VERSION_MISMATCH: Version mismatch:   chassisd message version 2   FPC 1 message version 2   local IPC version $Revision: 590540 $   remote IPC version $Revision: 653007 $
Dec 18 05:01:42  EX4200-A license-check[1331]: LICENSE: copy to /config/license from fpc0:/config/.license_priv/
Dec 18 05:01:42  EX4200-A license-check[1331]: LIBJNX_REPLICATE_RCP_ERROR: rcp -r -Ji fpc0:/config/.license_priv/ /config/license : rcp: /config/.license_priv/: No such file or directory
Dec 18 05:01:42  EX4200-A license-check[1331]: LIBJNX_REPLICATE_RCP_ERROR: rcp -r -Ji fpc1:/config/.license_priv/ /config/license : rcp: /config/.license_priv/: No such file or directory
Dec 18 05:01:42  EX4200-A license-check[1331]: copy from member 0 failed
Dec 18 05:01:42  EX4200-A license-check[1331]: LICENSE: copy to /config/license from fpc1:/config/.license_priv/
Dec 18 05:01:42  EX4200-A license-check[1331]: copy from member 1 failed
Dec 18 05:01:50  EX4200-A bdbrepd: Subscriber Management is ready for GRES
Dec 18 05:01:52  EX4200-A license-check[1331]: LICENSE: copy to /config/license from fpc0:/config/.license_priv/
Dec 18 05:01:52  EX4200-A license-check[1331]: LIBJNX_REPLICATE_RCP_ERROR: rcp -r -Ji fpc0:/config/.license_priv/ /config/license : rcp: /config/.license_priv/: No such file or directory
Dec 18 05:01:52  EX4200-A license-check[1331]: copy from member 0 failed
{...}
Dec 18 05:02:39  EX4200-A chassisd[1298]: CHASSISD_FRU_ONLINE_TIMEOUT: fpc_online_timeout: attempt to bring FPC 1 online timed out
Dec 18 05:03:39  EX4200-A chassisd[1298]: CHASSISD_FRU_ONLINE_TIMEOUT: fpc_online_timeout: attempt to bring FPC 1 online timed out
Dec 18 05:03:39  EX4200-A chassisd[1298]: CHASSISD_FRU_UNRESPONSIVE: Error for FPC 1: attempt to bring online timed out; restarted it
Dec 18 05:03:39  EX4200-A chassisd[1298]: CHASSISD_FRU_OFFLINE_NOTICE: Taking FPC 1 offline: Restarting unresponsive board
Dec 18 05:03:39  EX4200-A chassisd[1298]: CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(1)
Dec 18 05:03:39  EX4200-A chassisd[1298]: CHASSISD_SNMP_TRAP7: SNMP trap generated: FRU removal (jnxFruContentsIndex 7, jnxFruL1Index 2, jnxFruL2Index 0, jnxFruL3Index 0, jnxFruName FPC: EX4200-48T, 8 POE @ 1/*/*, jnxFruType 3, jnxFruSlot 1)
Dec 18 05:03:40  EX4200-A chassisd[1298]: CHASSISD_VERSION_MISMATCH: Version mismatch:   chassisd message version 2   FPC 1 message version 2   local IPC version $Revision: 590540 $   remote IPC version $Revision: 653007 $

It was Friday and I had a planned upgrade for the following week, so I didn’t have the time to raise a JTAC case (which I should have probably done but that could come later). With this in mind I thought I should be able to manually failover the Routing-Engines and upgrade each member the same way without all of the magic of the NSSU:

NSSU Note
It took longer than expected to do this testing and I had to cancel my change. I found out that currently (as in when this was written) you can’t use NSSU to upgrade from 12.3 to any higher versions. This explained why everything was breaking and giving me issues. After raising this with our Technical Account Manager at Juniper, he provided details on What version Of Junos supports NSSU on EX Series.

Soooooooo this is what this post will be about, the success or failure of manually failing over a VC with minimal downtime 🙂

Let’s get cracking!

I was using 2x EX4200 with JUNOS 12.3R5.7; it’s the same setup I had in my previous Virtual Chassis post. I used the preprovisioned method of stacking the switches, and had the following VC specific configuration applied:

show routing-optionsshow chassisshow virtual-chassis
[email protected]# show routing-options 
nonstop-routing;
static {
    route 0.0.0.0/0 {
        next-hop 10.1.0.1;
        no-readvertise;
    }
}
[email protected]# show chassis 
redundancy {
    graceful-switchover;
}
[email protected]# show virtual-chassis 
preprovisioned;
no-split-detection;
member 0 {
    role routing-engine;
    serial-number BP0214340104;
}
member 1 {
    role routing-engine;
    serial-number BP0215090120;
}
fast-failover {
    ge;
    xe;
}

It’s important to make sure you have nonstop-routing, graceful-switchover and no-split-detection configured without these or you will most likely get a split brain affect and that’s not a good thing!

I’ve got a VM connected to both switches in LACP bond configured

[email protected]> show lldp neighbors 
Local Interface    Parent Interface    Chassis Id          Port info          System Name
ge-0/0/2.0         ae1.0               00:0c:29:4f:26:bb   eth1               km-vm1              
ge-1/0/2.0         ae1.0               00:0c:29:4f:26:bb   eth2               km-vm1

and I have the VM pinging it default gateway (192.31.1.1), which is the l3-interface on the switch

[email protected]:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.31.1.1      0.0.0.0         UG    0      0        0 bond0
10.1.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.31.1.0      0.0.0.0         255.255.255.0   U     0      0        0 bond0

Now everything is sorted, let’s try some stuff!

As the VM is dual connected to both members, I’ll shutdown the interfaces and the VCP ports of backup switch, upgrade it and then do the same on the master switch. In essence, I’ll be breaking the VC to upgrade each switch individually. I’ll be running a continuous ping from the VM switch and will be able see if any packets are dropped during this work.

I start with the backup member. I have to disable the data and break the virtual chassis by disabling the VCP ports. I had to copy over the junos package from member 0 to member 1, as I’d have no access to member 0 once the virtual chassis had been broken.

[email protected]> file copy /tmp/jinstall-ex-4200-13.2X51-D35.3-domestic-signed.tgz fpc1:/tmp/

This will copy the package from the member 0 to member 1. Confirmed by entering the shell cli and checking the /tmp folder on member 1

{backup:1}
[email protected]> start shell 
[email protected]:BK:1% cd /tmp/
[email protected]:BK:1% ls -la
total 234744
drwxrwxrwt   3 root  wheel           512 Dec 18 14:57 .
drwxr-xr-x  23 root  wheel           512 Dec 18 04:06 ..
-rw-r--r--   1 root  wheel            92 Dec 18 12:13 .clnpkg.LCK
-rw-r--r--   1 root  wheel            92 Dec 18 12:13 .pkg.LCK
drwxrwxr-x   2 root  operator        512 Dec 18 12:10 .snap
-rw-r--r--   1 root  wheel     120120669 Dec 18 14:58 jinstall-ex-4200-13.2X51-D35.3-domestic-signed.tgz
-rw-r--r--   1 root  wheel           393 Dec 18 12:10 partitions.spec
[email protected]:BK:1% exit

Next disable the member 1 port, in my case ge-1/0/2, deactivate interfaces ge-1/0/2

[email protected]# run show interfaces ge-1/0/2          
Physical interface: ge-1/0/2, Administratively down, Physical link is Down

The server dropped 3 packets, which is acceptable to most; so far so good. Next I disabled the VCP on the member 1 and member 0 and then console onto member 1.

[email protected]> request virtual-chassis vc-port set interface vcp-0 member 1 disable 
  [email protected]> request virtual-chassis vc-port set interface vcp-1 member 1 disable
  [email protected]> request virtual-chassis vc-port set interface vcp-0 disable 
  [email protected]> request virtual-chassis vc-port set interface vcp-1 disable

On member 1, it automatically took mastership and doesn’t member 0 anymore

{master:1}
[email protected]> show virtual-chassis status 

Preprovisioned Virtual Chassis
Virtual Chassis ID: e8a9.d27b.0f05
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  NotPrsnt BP0214340104 ex4200-48t
1 (FPC 1)  Prsnt    BP0215090120 ex4200-48t 129  Master*      N

The server is still pinging along, so now we can upgrade the backup member as if it was a standalone device. We’ll run request system software add /tmp/jinstall-ex-4200-13.2X51-D35.3-domestic-signed.tgz reboot validate reboot

Once member 1 rebooted I had to wait for a bit as it was looking for the master (due to the preprovisioned config) and it initial booted as a linecard however, it changed back to master after I entered the operational mode.

Next I enabled the member 1 port, activate interfaces ge-1/0/2

Comment
When I went to commit the change it took an awfully long time to activate the interface however, with a bit of patience the interface did come back up….. Eventually! Patience is the Key!

To double check and confirm it was up, I checked the lldp neighbor

[email protected]> show interfaces ge-1/0/2   
Physical interface: ge-1/0/2, Enabled, Physical link is Up
{master:1}
[email protected]> show lldp neighbors 
Local Interface    Parent Interface    Chassis Id          Port info          System Name
ge-1/0/2.0         ae1.0               00:0c:29:4f:26:bb   eth2               km-vm1

Now disable the member 0 port, in my case ge-0/0/2, deactivate interfaces ge-0/0/2

The Server had dropped 47 packets after the interface was disabled. This was most likely due to the convergence time for the LACP bond and the port going down, and this is shown in the log messages

Logs
Dec 18 17:01:19  EX4200-A /kernel: Percentage memory available(19)less than threshold(20 %)- 14
Dec 18 17:01:50  EX4200-A dcd[5164]: ae0 : Warning: aggregated-ether-options link-speed no kernel value! default to  0
Dec 18 17:01:50  EX4200-A dcd[5164]: check_prot: p_ae NULL, ifdp->ifdp_type is 25 ifdp_ifname ae1
Dec 18 17:01:50  EX4200-A mgd[3713]: UI_CHILD_EXITED: Child exited: PID 5164, status 1, command '/sbin/dcd'
Dec 18 17:03:27  EX4200-A mgd[3713]: UI_COMMIT: User 'root' requested 'commit' operation (comment: none)
Dec 18 17:03:34  EX4200-A /kernel: Percentage memory available(19)less than threshold(20 %)- 15
Dec 18 17:04:07  EX4200-A dcd[5205]: ae0 : Warning: aggregated-ether-options link-speed no kernel value! default to  0
Dec 18 17:04:07  EX4200-A dcd[5205]: ae1 : Warning: aggregated-ether-options link-speed no kernel value! default to  0
Dec 18 17:04:12  EX4200-A lldpd[1326]: UI_CONFIGURATION_ERROR: Process: lldpd, path: , statement: , Configuration database open failure: Database is already open
Dec 18 17:04:13  EX4200-A mgd[3713]: UI_DBASE_LOGOUT_EVENT: User 'root' exiting configuration mode
Dec 18 17:04:52  EX4200-A dcd[1297]: ae0 : aggregated-ether-options link-speed set to kernel value of  10000000000
Dec 18 17:04:52  EX4200-A dcd[1297]: ae1 : Warning: aggregated-ether-options has no childern! link-speed set to  0
Dec 18 17:04:52  EX4200-A /kernel: ae_bundlestate_ifd_change: bundle ae1: bundle IFD minimum links not met 0 < 1
Dec 18 17:04:52  EX4200-A mib2d[1304]: SNMP_TRAP_LINK_DOWN: ifIndex 655, ifAdminStatus up(1), ifOperStatus down(2), ifName ae1
Dec 18 17:04:52  EX4200-A /kernel: GENCFG: op 22 (Sflow) failed; err 1 (Unknown)
Dec 18 17:04:52  EX4200-A /kernel: drv_ge_misc_handler: ifd:135  new address:cc:e1:7f:2b:82:85
Dec 18 17:04:53  EX4200-A mib2d[1304]: SNMP_TRAP_LINK_DOWN: ifIndex 708, ifAdminStatus up(1), ifOperStatus down(2), ifName ae1.0
Dec 18 17:04:53  EX4200-A mib2d[1304]: SNMP_TRAP_LINK_DOWN: ifIndex 506, ifAdminStatus down(2), ifOperStatus down(2), ifName ge-0/0/2

With the server passing traffic over member 1, I could upgrade member 0 which was the same as before request system software add /tmp/jinstall-ex-4200-13.2X51-D35.3-domestic-signed.tgz reboot validate reboot

Same as member 1, it came back up after its reboot but the switch took an age to find the master and just as long to commit the activation of interface ge-0/0/2! Extreme Patience’s Needed!

Confirmation of the link is up and I have lldp neighbor

{master:0}
[email protected]> show lldp neighbors 
Local Interface    Parent Interface    Chassis Id          Port info          System Name
ge-0/0/2.0         ae1.0               00:0c:29:4f:26:bb   eth1               km-vm1
{master:0}
[email protected]> show interfaces ge-0/0/2   
Physical interface: ge-0/0/2, Enabled, Physical link is Up

Having both members are on the same code as expected:

{master:0}
[email protected]> show version 
fpc0:
--------------------------------------------------------------------------
Hostname: EX4200-A
Model: ex4200-48t
JUNOS EX  Software Suite [13.2X51-D35.3]
JUNOS FIPS mode utilities [13.2X51-D35.3]
JUNOS Online Documentation [13.2X51-D35.3]
JUNOS EX 4200 Software Suite [13.2X51-D35.3]
JUNOS Web Management [13.2X51-D35.3]

{master:1}
[email protected]> show version 
fpc1:
--------------------------------------------------------------------------
Hostname: EX4200-A
Model: ex4200-48t
JUNOS EX  Software Suite [13.2X51-D35.3]
JUNOS FIPS mode utilities [13.2X51-D35.3]
JUNOS Online Documentation [13.2X51-D35.3]
JUNOS EX 4200 Software Suite [13.2X51-D35.3]
JUNOS Web Management [13.2X51-D35.3]

To get them joined together into the virtual chassis I enabled the VCP ports on member 0 and hoped this would bring them back together with no issues (He says!!!)

{master:0}
[email protected]> request virtual-chassis vc-port set interface vcp-0    
{master:0}
[email protected]> request virtual-chassis vc-port set interface vcp-1

To finish off, I ran the command request system snapshot slice alternate all-members to make sure the backup partition image was consistent with the primary

And finally everything is complete! I confirmed the virtual-chassis, firmware version, lldp neighbors and Upgraded the Backup Partition! Never forget to do this!

show virtual-chassisshow versionshow lldp neighborsrequest system snapshot slice alternate
[email protected]> show virtual-chassis    

Preprovisioned Virtual Chassis
Virtual Chassis ID: e8a9.d27b.0f05
Virtual Chassis Mode: Enabled
                                                Mstr           Mixed Route Neighbor List
Member ID  Status   Serial No    Model          prio  Role      Mode  Mode ID  Interface
0 (FPC 0)  Prsnt    BP0214340104 ex4200-48t     129   Master*      N  VC   1  vcp-0      
                                                                           1  vcp-1      
1 (FPC 1)  Prsnt    BP0215090120 ex4200-48t     129   Backup       N  VC   0  vcp-0      
                                                                           0  vcp-1

[email protected]> show version              
fpc0:
--------------------------------------------------------------------------
Hostname: EX4200-A
Model: ex4200-48t
JUNOS EX  Software Suite [13.2X51-D35.3]
JUNOS FIPS mode utilities [13.2X51-D35.3]
JUNOS Online Documentation [13.2X51-D35.3]
JUNOS EX 4200 Software Suite [13.2X51-D35.3]
JUNOS Web Management [13.2X51-D35.3]

fpc1:
--------------------------------------------------------------------------
Hostname: EX4200-A
Model: ex4200-48t
JUNOS EX  Software Suite [13.2X51-D35.3]
JUNOS FIPS mode utilities [13.2X51-D35.3]
JUNOS Online Documentation [13.2X51-D35.3]
JUNOS EX 4200 Software Suite [13.2X51-D35.3]
JUNOS Web Management [13.2X51-D35.3]

[email protected]> show lldp neighbors 
Local Interface    Parent Interface    Chassis Id          Port info          System Name
ge-0/0/2.0         ae1.0               00:0c:29:4f:26:bb   eth1               km-vm1              
ge-1/0/2.0         ae1.0               00:0c:29:4f:26:bb   eth2               km-vm1
[email protected]> request system snapshot slice alternate  
fpc0:
--------------------------------------------------------------------------
Formatting alternate root (/dev/da0s1a)...
Copying '/dev/da0s2a' to '/dev/da0s1a' .. (this may take a few minutes)
The following filesystems were archived: /

fpc1:
--------------------------------------------------------------------------
Formatting alternate root (/dev/da0s2a)...
Copying '/dev/da0s1a' to '/dev/da0s2a' .. (this may take a few minutes)
The following filesystems were archived: /

From the running pings:

--- 192.31.1.1 ping statistics ---
9365 packets transmitted, 9234 received, +42 errors, 1% packet loss, time 9377278ms
rtt min/avg/max/mdev = 0.771/1.162/11.807/0.370 ms, pipe 3
[email protected]:~$

There was 1% packet over the whole time of the test (156 minutes), working out as a 93.77 second outage which isn't too bad. Considering this was the first time I tried this method I’ll be going over it again because it took far too long, but overall this method works!

I also messed about with the different types of bonding methods available:

With the round-robin or bond-type 0, the switch was configured as two access ports and I saw high packet loss during the testing.

--- 192.31.1.1 ping statistics ---
6106 packets transmitted, 3125 received, 48% packet loss, time 6128448ms
rtt min/avg/max/mdev = 0.814/1.484/902.641/16.131 ms

This was due to the nature of the round-robin bonding method.

Round-robin policy to transmit packets in sequential order from the first available slave through the last. This mode provides load balancing and fault tolerance.

With the active-backup or bond-type 1, the switch was configured as two access ports and I saw no packet loss during the testing. A sight difference when using active-backup (as expected to be honest) when you check the lldp neighbors is that you’ll only see one interface up at a time.

This is due to the nature of the bond-type

Only one slave in the bond is active. A different slave becomes active if, and only if, the active slave fails. The bond’s MAC address is externally visible on only one port (network adapter) to avoid confusing the switch.
Ping OutputLLDP Difference
--- 192.31.1.1 ping statistics ---
2905 packets transmitted, 2892 received, 0% packet loss, time 2908023ms
rtt min/avg/max/mdev = 0.846/1.214/20.269/0.758 ms
[email protected]> show lldp neighbors 
Local Interface    Parent Interface    Chassis Id          Port info          System Name
ge-0/0/2.0         -                   00:0c:29:4f:26:bb   eth1               km-vm1              
vme.0              -                   00:19:06:cd:8f:80   GigabitEthernet1/0/36 oob-sw0-10.lab      
xe-0/1/0.0         ae0.0               78:fe:3d:46:2a:c0   xe-0/0/2.0         EX4500

Having got a method that worked, the tabs below show some of the methods I tried and failed on. Looking back on some of the methods, the two methods I used were never going to work however, this is why you have a lab and it’s always good to see things for yourself to see if you can troubleshoot your way out! With all that being said I’ve actually picked up a few things I didn’t know, so this was a good exercise!

Tester Method #1
Upgrade the member 1 then see if you failover routing-engine from member 0 to member 1. The issue that could arise is that the routing-engine will not failover as the 2 switches will be on different version of code and the VC will not join back up as backup routing-engine.

I started the upgrade on member 1 running:

request system software add /tmp/jinstall-ex-4200-13.2X51-D35.3-domestic-signed.tgz member 1 reboot

Once the upgrade had completed, I checked the virtual chassis and as I thought member 1 didn’t join back into the VC as backup routing-engine

[email protected]> show virtual-chassis    

Preprovisioned Virtual Chassis
Virtual Chassis ID: e8a9.d27b.0f05
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  Prsnt    BP0214340104 ex4200-48t 129  Master*      N  1  vcp-0      
                                                                 1  vcp-1      
1 (FPC 1)  Inactive BP0215090120 ex4200-48t 129  Linecard     N  0  vcp-0      
                                                                 0  vcp-1

And the logs show the mismatch of code and timeout of member 1 rejoining the VC. This method is out, but then it was expected to be honest

Tester Method #2
Upgrade using NSSU method and when it gets stuck see if you can abort and failover. This method sounds like it’s a bit of a hack and won’t work however, we’re in the lab so it doesn’t matter, and if it works then yaaay!

I ran the command to kick of the NSSU

request system software nonstop-upgrade /tmp/jinstall-ex-4200-13.2X51-D35.3-domestic-signed.tgz
Chassis ISSU Check Done
[Dec 18 08:41:50]:ISSU: Validating Image
[Dec 18 08:42:20]:ISSU: Preparing Backup RE
[Dec 18 08:42:21]: Installing image on other FPC's along with the backup

[Dec 18 08:42:21]: Checking pending install on fpc1
[Dec 18 08:43:21]: Pushing bundle to fpc1
NOTICE: Validating configuration against mchassis-install.tgz.
NOTICE: Use the 'no-validate' option to skip this if desired.
WARNING: A reboot is required to install the software
WARNING:     Use the 'request system reboot' command immediately
[Dec 18 08:44:23]: Completed install on fpc1
[Dec 18 08:44:34]: Backup upgrade done
[Dec 18 08:44:34]: Rebooting Backup RE

Rebooting fpc1
[Dec 18 08:44:34]:ISSU: Backup RE Prepare Done
[Dec 18 08:44:34]: Waiting for Backup RE reboot

Having a console into member 1, I can see that member 1 has joined the VC cluster

{backup:1}
[email protected]> show virtual-chassis 

Preprovisioned Virtual Chassis
Virtual Chassis ID: e8a9.d27b.0f05
Virtual Chassis Mode: Enabled
                                                Mstr           Mixed Route Neighbor List
Member ID  Status   Serial No    Model          prio  Role      Mode  Mode ID  Interface
0 (FPC 0)  Prsnt    BP0214340104 ex4200-48t     129   Master       N  VC   1  vcp-0      
                                                                           1  vcp-1      
1 (FPC 1)  Prsnt    BP0215090120 ex4200-48t     129   Backup*      N  VC   0  vcp-0      
                                                                           0  vcp-1 

I aborted the NSSU on the member 0 console screen and tried to failover the routing-engine. However, when I aborted the NSSU it took over an hour to get the operational prompt and once I got to the operational prompt, the VC cluster had detached and was back to Master and Linecard. This makes sense now as the switches are out of the NSSU process, and it will just go back seeing 2 mismatched Junos versions

{master:0}
[email protected]> show virtual-chassis 

Preprovisioned Virtual Chassis
Virtual Chassis ID: e8a9.d27b.0f05
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  Prsnt    BP0214340104 ex4200-48t 129  Master*      N  1  vcp-0      
                                                                 1  vcp-1      
1 (FPC 1)  Inactive BP0215090120 ex4200-48t 129  Linecard     N  0  vcp-0      
                                                                 0  vcp-1

This method is out (but then this was expected)

Side Notes
Note 1Note 1.5Rollback Firmware Upgrade
If you want to change it you can release the routing-engine mastership by running the command request chassis routing-engine master release, but by using this command you will get an outage as the PFE will switchover and as you can not have non-stop routing and graceful switchover, both configured under routing-options stanza an outage will happen.
Additionally, whatever config changes you made as the members are separated will not be kept if you switchover the PFE. I saw that when I enabled interface ge-1/0/2 on member 1, but when the PFE was switchover it become inactive.
[email protected]> request system software rollback member 1 reboot 
fpc1:
--------------------------------------------------------------------------
Junos version '12.3R5.7' will become active at next reboot
Rebooting ...
shutdown: [pid 1280]
Shutdown NOW!

Then once member 1 has rebooted, I checked to make sure it is present into the virtual chassis

[email protected]> show virtual-chassis                                

Preprovisioned Virtual Chassis
Virtual Chassis ID: e8a9.d27b.0f05
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  Prsnt    BP0214340104 ex4200-48t 129  Master*      N  1  vcp-0      
                                                                 1  vcp-1      
1 (FPC 1)  Prsnt    BP0215090120 ex4200-48t 129  Backup       N  0  vcp-0      
                                                                 0  vcp-1
Share this:
Share

Installing LLDP on Ubuntu

LLDP (Link Local Discovery Protocol) is an Open Standard Layer-2 protocol that is used by servers and network devices to advertise their identity and capabilities to other device, by directly connected devices. This standard is defined in IEEE 802.1AB. The information is sent via lldp-enabled interfaces, as Ethernet frame, over fixed interval. These frames contain LLDPDS (Link Local Discovery Protocol Data Unit) in a Type-Length-Value (TLV) format.

LLPDS include a wide range of information from hostname, description, and port name etc. Using LLPD can be very useful as you will be able to find out what devices are directly connected to a switch without having the joy of going cable tracking, and it’s useful for troubleshooting. With that in mind, this post will go into how you would enable LLDP on a Juniper and Cisco switch, and how to enable on Ubuntu 14.04LTS.

Let’s get cracking!

For my set up I’ve got ESXi host running Ubuntu 14.04LTS. It has three vNICs; one is connected to the OOB Cisco 3750G switch and other two connections go into a Virtual Chassis Juniper EX4200

Firstly enable lldp on your network device:

For a Juniper device set protocols lldp interface all and for a Cisco device lldp run or for CDP, under the interface you will need to run cdp enable (CDP is Cisco’s proprietary link discovery protocol)

You’ll need to install the LLDP and SNMP packages onto the server:

[email protected]:~$ sudo apt-get install lldpd snmp

You’ll need to start both of the processes to get them up and running:

[email protected]:~$ sudo service lldpd restart
[email protected]:~$ sudo service snmpd restart

Once you’ve started these you’ll have both enabled on your server, and you’ll have LLDP configured! Nice and simple 🙂

To confirm everything is working as expected, you can run a show command on switches and the server for verification:

On the Juniper EX4200 show lldp neighbors, shows the 2 server NICs connected to each member

show lldp neighbors
[email protected]> show lldp neighbors 
Local Interface    Parent Interface    Chassis Id          Port info          System Name
ge-0/0/2.0         -                   00:0c:29:4f:26:bb   eth1               km-vm1              
ge-1/0/2.0         -                   00:0c:29:4f:26:bb   eth2               km-vm1              
vme.0              -                   00:19:06:cd:8f:80   GigabitEthernet1/0/36 oob-sw0-10.lab

On the Cisco 3750G show lldp neighbors, show the 2 ESXi hosts connected using the switch for Out of Band.

show lldp neighbors g1/0/48
oob-sw0-10.lab#show lldp neighbors g1/0/48
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID           Local Intf     Hold-time  Capability      Port ID
km-vm2              Gi1/0/48       120                        000c.29d3.ac6d
km-vm1              Gi1/0/48       120                        000c.294f.26bb

On the server, lldpcli show neighbors, shows all Cisco and Juniper switches and the other ESXi host shared the OOB NIC

lldpcli show neighbors
[email protected]:~$ lldpcli show neighbors
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    eth0, via: LLDP, RID: 1, Time: 0 day, 22:19:29
  Chassis:     
    ChassisID:    mac 00:0c:29:d3:ac:77
    SysName:      km-vm2
    SysDescr:     Ubuntu 14.04.2 LTS Linux 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64
    MgmtIP:       10.1.0.141
    MgmtIP:       2001:41c1:4:8040:20c:29ff:fed3:ac6d
    Capability:   Bridge, off
    Capability:   Router, off
    Capability:   Wlan, off
  Port:        
    PortID:       mac 00:0c:29:d3:ac:6d
    PortDescr:    eth0
-------------------------------------------------------------------------------
Interface:    eth0, via: LLDP, RID: 2, Time: 0 day, 22:19:11
  Chassis:     
    ChassisID:    mac 00:19:06:cd:8f:80
    SysName:      oob-sw0-10.lab
    SysDescr:     Cisco IOS Software, C3750 Software (C3750-IPSERVICESK9-M), Version 15.0(1)SE, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2011 by Cisco Systems, Inc.
Compiled Wed 20-Jul-11 09:32 by prod_rel_team
    MgmtIP:       10.1.0.4
    Capability:   Bridge, on
    Capability:   Router, off
  Port:        
    PortID:       ifname Gi1/0/48
    PortDescr:    GigabitEthernet1/0/48
-------------------------------------------------------------------------------
Interface:    eth1, via: LLDP, RID: 6, Time: 0 day, 00:02:58
  Chassis:     
    ChassisID:    mac 40:a6:77:5f:60:00
    SysName:      EX4200-A
    SysDescr:     Juniper Networks, Inc. ex4200-48t , version 12.3R5.7 Build date: 2013-12-18 03:01:12 UTC 
    MgmtIP:       10.1.0.243
    Capability:   Bridge, on
    Capability:   Router, on
  Port:        
    PortID:       local 503
    PortDescr:    KM-VM-1
-------------------------------------------------------------------------------
Interface:    eth2, via: LLDP, RID: 6, Time: 0 day, 00:03:01
  Chassis:     
    ChassisID:    mac 40:a6:77:5f:60:00
    SysName:      EX4200-A
    SysDescr:     Juniper Networks, Inc. ex4200-48t , version 12.3R5.7 Build date: 2013-12-18 03:01:12 UTC 
    MgmtIP:       10.1.0.243
    Capability:   Bridge, on
    Capability:   Router, on
  Port:        
    PortID:       local 661
    PortDescr:    KM-VM-1
-------------------------------------------------------------------------------

You can see detailed information and additional commands that can be run using lldpcli, on the man pages or via Ubuntu documentation

Share this:
Share

Juniper EX Virtual Chassis Part 2

I’ve already written a post on how to create a Virtual Chassis by using the 1/10GB uplink modules. If you have a switch in production and want to add another switch for additional ports or redundancy, you can easily create a virtual chassis. This time I’ll be using the dedicated VC ports and cables and adding a new switch to a production switch.

I’ll be using the preprovisioned method, and before I do any virtual chassis configuration I’ll need to add some features to the master member to minimize failover times:

set system commit synchronize
set chassis redundancy graceful-switchover
set routing-options nonstop-routing
set ethernet-switching-options nonstop-bridging

Having added these features, we can now configure preprovisioned virtual chassis onto the master switch, which will become member 0. Because this is only a 2 member VC, I’ve added the no-split-detection command as recommended by Juniper, and to help with the failover times fast-failover on all ports ge/xe that have been enabled.

set virtual-chassis preprovisioned
set virtual-chassis no-split-detection
set virtual-chassis member 0 role routing-engine
set virtual-chassis member 0 serial-number BP0214340104
set virtual-chassis member 1 role routing-engine
set virtual-chassis member 1 serial-number BP0215090120
set virtual-chassis fast-failover ge
set virtual-chassis fast-failover xe

For now, that’s everything on the master member. On the new switch (member 1), you need to clear all config from the switch and set the root password to allow you to commit your changes:

root> edit 
Entering configuration mode
 
{master:0}[edit]
root# delete 
This will delete the entire configuration
Delete everything under this level? [yes,no] (no) yes 
{master:0}[edit]
root# set system root-authentication plain-text-password    
New password:
Retype new password:
root# commit 
configuration check succeeds
commit complete

You need to ensure there are no past virtual chassis configurations, and you can do this by entering the shell cli of the switch and removing anything in the vchassis folder:

root> start shell 
[email protected]:RE:0% rm -rf /config/vchassis/*
[email protected]:RE:0% cd /config/vchassis/
[email protected]:RE:0% ls -la
total 8
drwxr-xr-x  2 root  wheel  512 Sep 13 07:26 .
drwxr-xr-x  5 root  wheel  512 Sep 13 06:57 ..
[email protected]:RE:0% exit
exit

Now you will need to power off the backup member for at least a minute, to ensure that the other switch is elected as master.

After the minute, patch the VC-cable into the dedicated VCP-Ports at the back of the chassis and power on the backup switch. Once member 1 has booted you will be able to verify the new member by running: show virtual-chassis status

[email protected]> show virtual-chassis status     
 
Preprovisioned Virtual Chassis
Virtual Chassis ID: f1a1.ca8e.bbba
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  Prsnt    BP0214340104 ex4200-48t 129  Master*      N  1  vcp-0      
                                                                 1  vcp-1      
1 (FPC 1)  Prsnt    BP0215090120 ex4200-48t 129  Backup       N  0  vcp-0      
                                                                 0  vcp-1  

And you can verify the health of the VCP ports by running: show virtual-chassis vc-port

[email protected]> show virtual-chassis vc-port    
fpc0:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Up           32000        1   vcp-0  
vcp-1       Dedicated           2    Up           32000        1   vcp-1  
 
fpc1:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Up           32000        0   vcp-0  
vcp-1       Dedicated           2    Up           32000        0   vcp-1  
Share this:
Share

JNCIA Refresher #2 – Junos OS Fundamentals

Junos device portfolio – product families, general functionality
Software architecture and Protocol daemons
Control and Forwarding planes
Routing Engine and Packet Forwarding Engine
Transit and Exception traffic

Junos device portfolio – product families, general functionality

Juniper has a number of the products that span across a number of different environments now. In the most part you are able to categories the devices into a four networking areas. These areas are: Enterprise, Service Provider, Data Centre and Security. Of course you will be able to put whatever device into your network as you wish, but you will have devices that would be more effective and efficient in a particular environment compared to overs. The tabs show the different model Series that Juniper provide (descriptions are taken from the Juniper product pages)

M SeriesT SeriesMX SeriesEX SeriesQFX SeriesSRX Series
M Series is a Multiservice Edge Router, on the edge of your network connecting to the external peers and transit providers. These would seen in Service Providers or Medium to Large Enterprise networks. M Series can provide up to 320Gbps of throughput.

Model Juniper’s Description
M7i M7i Multiservice Edge Router is compact with 10 Gbps throughput.
M10i M10i Multiservice Edge Router is compact and fully redundant with 16 Gbps throughput.
M120 M120 Multiservice Edge Router is highly redundant with 120 Gbps throughput.
M320 M320 Multiservice Edge Router is a 320 Gbps high-performance routing platform.
T series provides from 320Gbps up to 1.6Tbps of throughput on a single chassis and up to 25Tbps in a multi-chassis configuration. These routers would be used within an IP/MPLS Core Service Provider or Large Enterprise networks.

Model Juniper’s Description
T640 T640 Core Router delivers 50 Gbps forwarding on each of its 8 slots, and is ideal for powering small core applications.
T1600 T1600 Core Router offers scalable, high-performance, core routing in a small package.
T4000 T4000 Core Router delivers 4 Tbps of traffic in a single half rack routing node.
MX Series allows the flexibility between have router that has a throughput of 80Tbps with the switching capabilities. The MX Series can be used as both an Edge/Core device in Service Provider/Enterprise environment and has the stability through interchangeable line cards and software licensing.

Model Juniper’s Description
MX5 The MX5 is a compact 20 Gbps upgradeable router for enterprise applications, space/power constrained service provider facilities and CPEs.
MX10 The MX10 is a compact 40 Gbps router ideal for enterprise applications and space/power-constrained service provider facilities.
MX40 The MX40 is a compact 60 Gbps router ideal for enterprise applications and space/power-constrained service provider facilities.
MX80 The MX80 is a compact 80 Gbps router ideal for enterprise applications and space/power constrained service provider facilities.
MX104 The 80 Gbps MX104 offers control plane redundancy and is optimized for Ethernet aggregation and enterprise applications.
MX240 The modular MX240 offers almost 2 Tbps of system capacity for cloud, campus and enterprise data center, service provider edge, and mobile service core deployments.
MX480 The modular MX480 delivers over 5 Tbps of system capacity for cloud, campus and enterprise data center, service provider edge, and mobile service core deployments.
MX960 The modular MX960 delivers over 10 Tbps of system capacity for cloud and large enterprise data center, service provider edge, and mobile service core deployments.
MX2010 The modular MX2010 offers over 17 Tbps of system capacity to help service providers scale long-term for broadband traffic, subscribers, and services.
MX2020 The modular MX2020 is the industry’s highest-capacity, single-chassis edge router, supporting 10/100 Gbps interfaces and scaling up to 80 Tbps.
EX Series is a Layer 2/3 switch largely (not exclusively) used in Enterprise Networks. These switches can be used within a Virtual Chassis configuration, to provide Aggregation Layer, High Availability and Port Capacity.

Model Juniper’s Description
2200 EX2200 switches are low power, low acoustic 1 U devices, offering an economical solution for branch offices and campus networks.
3200 The EX3300 is a compact switch for demanding converged enterprise access.
4200 The EX4200 is a flexible, stackable switching solution for data centers and campuses.
4300 The EX4300 supports branch, campus, and data center access and aggregation deployments.
4500/4550 The EX4500 and EX4550 are a compact, high-performance platform for data center, campus, and service provider deployments.
4600 The EX4600 delivers a scalable 10GbE solution for high-density campus and data center top-of-rack deployments.
6200 The EX6200 is a scalable, resilient, high-performance wiring closet solution.
8200 The EX8200 provides the port densities, scalability, and high availability required for today’s data center and campus core environments.
9200 The EX9200 is SDN-ready and offers the flexibility and scalability required for business agility and growth.
QFX Series are switches that are fairly new product from Juniper. These switches are used in Data Centre environment.

Model Juniper’s Description
QFX3500 The QFX3500 Switch is a high-performance, low-latency, feature-rich 10GbE Layer 2 and Layer 3 switch designed and optimized for virtualized data centers.
QFX3600 The QFX3600 Switch is a 40GbE, high-performance, Layer 2 and Layer 3 switch designed and optimized for virtualized data centers
QFX5100 The QFX5100 Switches are low-latency, high-performance 10GbE/40GbE switches that act as a flexible building block for multiple data center fabric architectures.
QFX10000 The QFX10000 Switches are highly scalable, high-density platforms that support a variety of 10GbE/40GbE/100GbE deployments, providing a robust foundation for the most demanding data centers.
SRX Series are Juniper Security Gateways/Firewall devices that will be used to protect your network. These can use be as an Edge Gateway in a number of different environments from Service Provider/Enterprise or Data Centre.

Model Juniper’s Description
100 SRX100 Services Gateway provides high-performance security for small business and distributed enterprise locations.
110 SRX110 consolidates security, routing, switching, and WAN connectivity in a small desktop device, and is ideal for securing small businesses and branch deployments.
210 SRX210 provides robust, enterprise-class security for small distributed enterprise locations.
220 SRX220 provides robust, enterprise-class security for small to midsize businesses and distributed enterprise locations.
240 SRX240 provides robust, enterprise-class security for branch distributed enterprise locations.
550 SRX550 provides robust, enterprise-class security for medium and large branch locations.
650 SRX650 provides robust, enterprise-class security for regional sites and large branch locations
1400 SRX1400 is ideal for securing small to midsize data center environments.
3400 SRX3400 is ideal for securing small and midsize server farms and hosting sites.
3600 SRX3600 is ideal for securing medium to large enterprise data centers, hosted or colocated data centers, and server farms.
5400 SRX5400 is ideal for securing service provider, large enterprise, and public sector networks.
5600 SRX5600 is ideal for securing large enterprise data centers or service provider infrastructures, and aggregating security services.
5800 SRX5800 is ideal for securing large enterprise data centers, hosted or colocated data centers, and service provider infrastructures.

Software architecture and Protocol daemons

Junos unlike other vendors is Unix based system, its underlying operating system is based on the Unix Open Source system FreeBSD. By using an open source approached for the OS, it has allowed Junos to be easily adaptable across the multiple platforms that Juniper offer. The Unix based OS allows Junos to be modular design, where the different modules have their own separate process with it own dedicated memory space. This is important, because if you have an issue with one module, it is not going to break the whole device, as the module has its own separate memory space. You would be able to see the processes being run on device, you would be able run the command show system processes | match /usr/sbin

System Processes and Daemons
[email protected]_SRX> show system processes | match /usr/sbin 
 1257  ??  S      0:00.06 /usr/sbin/tnetd -N
 1259  ??  S     13:15.04 /usr/sbin/chassisd -N
 1260  ??  S     33:39.68 /usr/sbin/alarmd -N
 1261  ??  S      1:53.77 /usr/sbin/craftd -N
 1262  ??  S      0:21.39 /usr/sbin/mgd -N
 1263  ??  S     27:16.26 /usr/sbin/snmpd -N
 1264  ??  S     73:26.45 /usr/sbin/mib2d -N
 1265  ??  S     32:50.53 /usr/sbin/rpd -N
 1266  ??  S     73:08.18 /usr/sbin/l2ald -N
 1267  ??  S      0:00.18 /usr/sbin/inetd -N -w
 1268  ??  S     32:51.30 /usr/sbin/pfed -N
 1269  ??  S      1:45.65 /usr/sbin/cosd
 1270  ??  S     12:34.69 /usr/sbin/kmd -N
 1271  ??  S     15:28.64 /usr/sbin/ppmd -N
 1272  ??  S      0:17.35 /usr/sbin/dfwd -N
 1273  ??  S      7:54.62 /usr/sbin/irsd -N
 1274  ??  S      2:48.90 /usr/sbin/bfdd -N
 1275  ??  S    39659:13.10 /usr/sbin/flowd_octeon_hm
 1277  ??  S      0:00.33 /usr/sbin/pppd -N
 1279  ??  S      0:35.75 /usr/sbin/mplsoamd -N
 1280  ??  S      0:00.25 /usr/sbin/sendd -N
 1281  ??  S      0:00.46 /usr/sbin/wwand -N
 1282  ??  S      3:42.82 /usr/sbin/smid -N
 1283  ??  S      0:00.17 /usr/sbin/relayd -N
 1284  ??  S     55:48.49 /usr/sbin/shm-rtsdbd -N
 1285  ??  S      1:47.37 /usr/sbin/jsrpd -N
 1286  ??  S      2:41.78 /usr/sbin/nsd -N
 1287  ??  S      5:50.36 /usr/sbin/pkid -N
 1288  ??  S      0:00.56 /usr/sbin/appidd -N
 1289  ??  S      3:08.13 /usr/sbin/idpd -N
 1290  ??  S      8:46.55 /usr/sbin/rtlogd -N
 1291  ??  S     38:49.97 /usr/sbin/utmd -N
 1292  ??  S      0:25.08 /usr/sbin/smtpd -N
 1293  ??  S      8:57.92 /usr/sbin/wland -N
 1294  ??  S      8:19.53 /usr/sbin/mcsnoopd -N
 1295  ??  S    110:37.19 /usr/sbin/license-check -U -M -p 10 -i 10
 1296  ??  S      0:00.39 /usr/sbin/sdxd -N
17173  ??  S      7:35.50 /usr/sbin/lldpd -N
  923  u0- S      0:06.23 /usr/sbin/usbd -N
  942  u0- S      0:18.52 /usr/sbin/eventd -N -r -s -A

Control and Forwarding planes

All the functions of the control plane run on the Routing Engine (RE) whether you have a router, switch, or security platform running Junos. The Control plane has a set of modules, with clean interfaces between them. This interface can be different between device models, but largely will be fxp1 or bme0. You can check by running show interface terse. In addition, the kernel has control modules that manage all the needed communication between the components. The kernel handles the RE link between itself and the Packet Forwarding Engine (PFE) and the services. Each of the different modules provides a different control process, such as control for the chassis, Ethernet switching, routing protocols, interfaces, management etc. As stated earlier Junos uses a Unix based kernal from FreeBSD, by using this open-source untying kernal, it can provides many of the essential functions of an operating system, such as the scheduling of resources. Junos to protect the control plane from a security attack, by rate-limit the traffic that reaches your RE and allowing firewall filters to be placed onto the management interfaces

The Packet Forwarding Engine (PFE) is the central processing element of the forwarding plane, systematically moving the packets in and out of the device. In the Junos OS, the PFE has a locally stored forwarding table. The forwarding table is a synchronized copy of all the information from the RE that the forwarding plane needs to handle each packet, including outgoing interfaces, addresses, and so on. Storing a local copy of this information allows the PFE to get its job done without going to the control plane every time that it needs to process a packet. Another benefit to having a local copy is that the PFE can continue forwarding packets, even when a disruption occurs to the control plane, such as when a routing or other process issue happens.

 

Routing Engine and Packet Forwarding Engine

The Packet Forwarding Engine uses application-specific integrated circuits (ASICs) chips, to perform Layer 2 and Layer 3 packet switching, route lookups, and packet forwarding. The Packet Forwarding Engine forwards packets between input and output interfaces.

The Routing Engine controls the routing updates and system management. The Routing Engine consists of routing protocol software processes running inside a protected memory environment on a general-purpose computer platform. The Routing Engine handles all the routing protocol processes and other software processes that control the routing platform’s interfaces, some of the chassis components, system management, and user access to the routing platform. These routing platform and software processes run on top of a kernel that interacts with the Packet Forwarding Engine.

The key functions of the Routing Engine are:

  • Routing protocol packets processing
  • Software modularity—Software functions have been divided into separate processes, so a failure of one process has little or no effect on other software processes.
  • In-depth IP functionality- Each routing protocol is implemented with a complete set of IP features and provides full flexibility for advertising, filtering, and modifying routes. Routing policies are set according to route parameters, such as prefix, prefix lengths, and Border Gateway Protocol (BGP) attributes
  • Management interfaces—System management is possible with a command-line interface (CLI), a craft interface, and Simple Network Management Protocol (SNMP).
  • Storage and change management
  • Monitoring efficiency and flexibility—Alarms can be generated and packets can be counted without adversely affecting packet forwarding performance.
  • Transit and Exception traffic

    Transit Transit is traffic that is sent by an user which isn’t destined for the router, switch or gateway, but the packets have to pass through the device to get its end destination. For example:

    PC1 ---> Switch --> Router --> Internet

    If the PC on the left wanted to get the Internet on the right, the packets would transit the network to get out to the Internet. Transit Traffic is mostly unicast and/or multicast packets. Most of the time, Transit traffic will be largely processed by the PFE as the Forwarding Table will be referenced, to allow quicker movement of traffic. It is important to note, Transit Traffic does not consult the Routing Engine.

    Exception Traffic is traffic that is destined for the local system. For example if you wanted to check if the router up, you would ping its loopback address. This would be regarded as Exception Traffic, as packets destined for a device requires additional processing by the Routing Engine.

    Share this:
    Share