Juniper EX – Private vlans

I’ve gone over pvlans before on IOS, so I’m going to cover Juniper’s implementation today. This post will be based on the following topology:
PVLANS-1
There are five hosts and a single router. Host1 and Host3 are in the same community vlan, while Host2, Host4, and Host5 are in isolated vlans. R1 is the default gateway for all hosts.
The vlan plan is laid out as follows:

PVLAN Table
Host Switch Vlan
1 SW1 Community 501
2 SW1 Isolated 502
3 SW2 Community 501
4 SW2 Isolated 502
5 SW2 Isolated 502
R1 SW3 Primary 500

Community vlan – SW1

The community vlan has a vlan-id and primary vlan specified. You enable the interface under tha vlan config:

set vlans HOST_COMM vlan-id 501
set vlans HOST_COMM primary-vlan HOST_PRIMARY
set vlans HOST_COMM interface ge-0/0/4.0

Isolated and Primary Van – SW1

Isolated vlans are configured directly under the primary vlan. You also specify the interfaces in this vlan under the vlans hierarchy. Finally, as this pvlans span multiple switches, you need to ensure the trunk interfaces are pvlans aware:

set vlans HOST_PRIMARY vlan-id 500
set vlans HOST_PRIMARY interface ge-0/0/1.0 pvlan-trunk
set vlans HOST_PRIMARY interface ge-0/0/3.0 pvlan-trunk
set vlans HOST_PRIMARY interface ge-0/0/5.0
set vlans HOST_PRIMARY no-local-switching
set vlans HOST_PRIMARY isolation-id 502

Personally I really don’t like the Junos way of doing isolated vlans. Interface ge-0/0/5.0 is an isolated port as its untagged and no-local-switching is configured. Configuring the promiscuous port to R1 from SW3 is configured like so:

set vlans HOST_PRIMARY vlan-id 500
set vlans HOST_PRIMARY interface ge-0/0/2.0 pvlan-trunk
set vlans HOST_PRIMARY interface ge-0/0/1.0 pvlan-trunk
set vlans HOST_PRIMARY interface ge-0/0/0.0
set vlans HOST_PRIMARY no-local-switching
set vlans HOST_PRIMARY isolation-id 502

There is no difference in the vlan configuration between an actual isolated port and a promiscuous port. What makes the difference is the interface config itself on both switches:

[email protected]> show configuration interfaces ge-0/0/5
unit 0 {
    family ethernet-switching {
        port-mode access;
    }
}

While SW3’s port to R1 is tagged:

[email protected]> show configuration interfaces ge-0/0/0
unit 0 {
    family ethernet-switching {
        port-mode trunk;
    }
}

If I wanted SW3’s like to R1 to be untagged it would change it to an isolated port. If I needed a host to send tagged traffic into an isolated vlan (like an ESX server), Junos makes that a promiscuous port. This is a lack of flexibility that I don’t like. The switches should be able to put devices in isolated or promiscuous mode by config separate to the fact that the host-facing port has a dot1q tag or not.

Verification

Show vlans extensive shows the pvlan information. It would be nice if Junos had a separate show pvlans command:

[email protected]> show vlans extensive
VLAN: HOST_COMM, Created at: Wed Mar 19 04:00:58 2014
802.1Q Tag: 501, Internal index: 14, Admin State: Enabled, Origin: Static
Private VLAN Mode: Community, Primary VLAN: HOST_PRIMARY
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 2 (Active = 2), Untagged  1 (Active = 1)
      ge-0/0/1.0*, tagged, trunk, pvlan-trunk
      ge-0/0/3.0*, tagged, trunk, pvlan-trunk
      ge-0/0/4.0*, untagged, access

Here we see ge-0/0/4.0 is an access port in vlan HOST_COMM. ge-0/0/1.0 and ge-0/0/3.0 are pvlan trunks as expected.

LAN: HOST_PRIMARY, Created at: Wed Mar 19 04:00:58 2014
802.1Q Tag: 500, Internal index: 16, Admin State: Enabled, Origin: Static
Private VLAN Mode: Primary
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 2 (Active = 2), Untagged  2 (Active = 2)
      ge-0/0/1.0*, tagged, trunk, pvlan-trunk
      ge-0/0/3.0*, tagged, trunk, pvlan-trunk
      ge-0/0/4.0*, untagged, access
      ge-0/0/5.0*, untagged, access
Secondary VLANs: Isolated 1, Community  1, Inter-switch-isolated  1
  Isolated VLANs :
      __pvlan_HOST_PRIMARY_ge-0/0/5.0__
  Community VLANs :
      HOST_COMM
  Inter-switch-isolated VLAN :
      __pvlan_HOST_PRIMARY_isiv__

VLAN: __pvlan_HOST_PRIMARY_ge-0/0/5.0__, Created at: Wed Mar 19 04:26:16 2014
Internal index: 17, Admin State: Enabled, Origin: Static
Private VLAN Mode: Isolated, Primary VLAN: HOST_PRIMARY
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 2 (Active = 2), Untagged  1 (Active = 1)
      ge-0/0/1.0*, tagged, trunk, pvlan-trunk
      ge-0/0/3.0*, tagged, trunk, pvlan-trunk
      ge-0/0/5.0*, untagged, access

VLAN: __pvlan_HOST_PRIMARY_isiv__, Created at: Wed Mar 19 04:26:16 2014
802.1Q Tag: 502, Internal index: 18, Admin State: Enabled, Origin: Static
Private VLAN Mode: Inter-switch-isolated, Primary VLAN: HOST_PRIMARY
Protocol: Port Mode, Mac aging time: 300 seconds
Number of interfaces: Tagged 2 (Active = 2), Untagged  0 (Active = 0)
      ge-0/0/1.0*, tagged, trunk, pvlan-trunk
      ge-0/0/3.0*, tagged, trunk, pvlan-trunk

A lot of information above, buit it does show which ports are connected to the primary vlan and which are isolated. It also shows which community and isolated vlans are connected to the primary vlan.

Ultimately the end result is that Host1 should be able to ping Host3 and Router1, but nothing else:

[email protected]_HOST> ping routing-instance HOST1 10.0.0.2 rapid
PING 10.0.0.2 (10.0.0.2): 56 data bytes
.....
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

{master:0}
[email protected]_HOST> ping routing-instance HOST1 10.0.0.3 rapid
PING 10.0.0.3 (10.0.0.3): 56 data bytes
!!!!!
--- 10.0.0.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.056/1.175/1.415/0.136 ms

{master:0}
[email protected]_HOST> ping routing-instance HOST1 10.0.0.4 rapid
PING 10.0.0.4 (10.0.0.4): 56 data bytes
.....
--- 10.0.0.4 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

{master:0}
[email protected]_HOST> ping routing-instance HOST1 10.0.0.5 rapid
PING 10.0.0.5 (10.0.0.5): 56 data bytes
.....
--- 10.0.0.5 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

{master:0}
[email protected]_HOST> ping routing-instance HOST1 10.0.0.254 rapid
PING 10.0.0.254 (10.0.0.254): 56 data bytes
!!!!!
--- 10.0.0.254 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.007/1.189/1.638/0.229 ms

I won’t go every single possible combination a there will simply be too much text, but I’ll go over Host4 and Router1.

Host4 should only be able to ping Router1 and nothing else:

[email protected]_HOST> ping routing-instance HOST4 10.0.0.1 rapid
PING 10.0.0.1 (10.0.0.1): 56 data bytes
.....
--- 10.0.0.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

{master:0}
[email protected]_HOST> ping routing-instance HOST4 10.0.0.2 rapid
PING 10.0.0.2 (10.0.0.2): 56 data bytes
.....
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

{master:0}
[email protected]_HOST> ping routing-instance HOST4 10.0.0.3 rapid
PING 10.0.0.3 (10.0.0.3): 56 data bytes
.....
--- 10.0.0.3 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

{master:0}
[email protected]_HOST> ping routing-instance HOST4 10.0.0.5 rapid
PING 10.0.0.5 (10.0.0.5): 56 data bytes
.....
--- 10.0.0.5 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

{master:0}
[email protected]_HOST> ping routing-instance HOST4 10.0.0.254 rapid
PING 10.0.0.254 (10.0.0.254): 56 data bytes
!!!!!
--- 10.0.0.254 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.997/1.763/3.471/0.927 ms

Finally, Router1 should be able to ping all hosts:

[email protected]_HOST> ping routing-instance ROUTER1 10.0.0.1 rapid
PING 10.0.0.1 (10.0.0.1): 56 data bytes
!!!!!
--- 10.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.011/1.168/1.301/0.122 ms

{master:0}
[email protected]_HOST> ping routing-instance ROUTER1 10.0.0.2 rapid
PING 10.0.0.2 (10.0.0.2): 56 data bytes
!!!!!
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.963/1.194/1.432/0.180 ms

{master:0}
[email protected]_HOST> ping routing-instance ROUTER1 10.0.0.3 rapid
PING 10.0.0.3 (10.0.0.3): 56 data bytes
!!!!!
--- 10.0.0.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.988/1.165/1.438/0.161 ms

{master:0}
[email protected]_HOST> ping routing-instance ROUTER1 10.0.0.4 rapid
PING 10.0.0.4 (10.0.0.4): 56 data bytes
!!!!!
--- 10.0.0.4 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.997/1.194/1.444/0.200 ms

{master:0}
[email protected]_HOST> ping routing-instance ROUTER1 10.0.0.5 rapid
PING 10.0.0.5 (10.0.0.5): 56 data bytes
!!!!!
--- 10.0.0.5 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.015/1.174/1.324/0.123 ms

Juniper EX Virtual-Chassis notes

I’ve been deploying some EX VCs recently so this post will go over some configuration and verification commands. To start with I have two EX4200s in my lab connected via the built-in VC ports. I’m running code version 12.3R6.6

VC-1

VC Ports

When booting this type of configuration, the switches will automatically attempt to create a virtual-chassis. i.e. without configuring anything they are already in a virtual-chassis:

[email protected]> show virtual-chassis

Virtual Chassis ID: f365.a9c6.1714
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  Prsnt    BN0208105351 ex4200-24p 128  Backup       N  1  vcp-0
                                                                 1  vcp-1
1 (FPC 1)  Prsnt    BN0208084463 ex4200-24p 128  Master*      N  0  vcp-0
                                                                 0  vcp-1

Member ID for next new member: 2 (FPC 2)

Here we see two members, both of which are present. Both have a default priority of 128. vcp-0/1 are the purpose-made VC ports. We can drill a bit deeper to see the bandwidth offered by these ports:

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

fpc1:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           2    Up           32000        0   vcp-1
vcp-1       Dedicated           1    Up           32000        0   vcp-0

VCEP Ports

VCP cables are limited in length. Juniper allows you to use the uplink module on the ex4200 to create a VC. These are called VCEP ports and requires manual configuration to do so. You can mix and match both VCP and VCEP ports at the same time. I’ve added the following switch to my topology:
VC-2
Turning these ports into VCEP ports is done in operational mode!

[email protected]> request virtual-chassis vc-port set pic-slot 1 port 0

Once this is done on both, I can verify that the vcep ports are created and the switched has joined the VC:

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

fpc1:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           2    Up           32000        0   vcp-1
vcp-1       Dedicated           1    Up           32000        0   vcp-0

fpc2:
--------------------------------------------------------------------------
Interface   Type              Trunk  Status       Speed        Neighbor
or                             ID                 (mbps)       ID  Interface
PIC / Port
vcp-0       Dedicated           1    Down         32000
vcp-1       Dedicated           2    Down         32000
1/0         Configured         -1    Up           1000         0   vcp-255/1/0

The advantage of using VCEP ports is that my ethernet cables can run as long as standard ethernet. The disadvantages include losing some front ports as well as much lower bandwidth. In the above the VCP ports give 32Gb while the VCEP port only gives 1Gb. Of course I could use a 10Gb module for the same duty.

Deterministic Master

Juniper has a great page showing how a master is elected right here. It basically goes like this:

  • Choose the member with the highest user-configured mastership priority (255 is the highest possible value). A switch with a mastership priority of 0 will always stay in the linecard role.
  • Choose the member that was master the last time the Virtual Chassis configuration booted.
  • Choose the member that has been included in the Virtual Chassis configuration for the longest period of time. (For this to be a deciding factor, there has to be a minimum time lapse of 1 minute between the power-ons of the individual interconnected member switches.)
  • Choose the member with the lowest MAC address.

I’d like to ensure SW1 is the master when possible:

{master:1}[edit]
[email protected]# set virtual-chassis member 0 mastership-priority 255

I can verify that it’s now 255:

[email protected]> show virtual-chassis

Virtual Chassis ID: f365.a9c6.1714
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  Prsnt    BN0208105351 ex4200-24p 255  Master*      N  1  vcp-0
                                                                 2  vcp-255/1/0
                                                                 1  vcp-1
1 (FPC 1)  Prsnt    BN0208084463 ex4200-24p 128  Backup       N  0  vcp-0
                                                                 0  vcp-1
2 (FPC 2)  Prsnt    BP0213260138 ex4200-48t 128  Linecard     N  0  vcp-255/1/0

Member ID for next new member: 3 (FPC 3)

Note that this mastership is pre-emptive and you cannot change that behaviour. This can be disruptive and the current best practise is to actually ensure all devices are configured with the same priority. – Virtual Chassis Technology Best Practises

Management port

Each ex4200 has an onboard ethernet management port referred to as me0.0 in the configuration. In a VC you con configure a vme port. This is a management address that moves to whichever switch is the master. Note that packets coming into ANY members me port will get directed to the master switch via the VCP ports:

[email protected]> show configuration interfaces vme
unit 0 {
    family inet {
        address 192.168.0.0/31;
    }
}

LCD Menu

The LCD panel of switches in a VC will inform you of their current role. RE for master, BK for backup, LC for linecard.

VCCP

Juniper uses VCCP as the VC protocol. This is actually customised IS-IS and you cannot configure it. You are able to extract some information though:

[email protected]> show virtual-chassis protocol interface
fpc0:
--------------------------------------------------------------------------
IS-IS interface database:
Interface             State         Metric
internal-0/27         Up             7
internal-1/24         Up             7
vcp-0.32768           Up             7
vcp-1.32768           Up             7
vcp-255/1/0.32768     Up             240

fpc1:
--------------------------------------------------------------------------
IS-IS interface database:
Interface             State         Metric
internal-0/27         Up             7
internal-1/24         Up             7
vcp-0.32768           Up             7
vcp-1.32768           Up             7

fpc2:
--------------------------------------------------------------------------
IS-IS interface database:
Interface             State         Metric
internal-0/24         Up             7
internal-1/25         Up             7
internal-2/24         Up             7
internal-2/27         Up             7
vcp-0.32768           Down           7
vcp-1.32768           Down           7
vcp-255/1/0.32768     Up             240

Upgrading

When upgrading, all member switches will be upgraded:

[email protected]> request system software add /tmp/usb/jinstall-ex-4200-13.2X50-D19.2-domestic-signed.tgz

[Mar 13 10:55:09]: Retrieving software images. This process can take several minutes. Please be patient..

[Mar 13 10:56:19]: Retrieving version and model information from /tmp/usb/jinstall-ex-4200-13.2X50-D19.2-domestic-signed.tgz

[Mar 13 10:57:37]: Checking pending install on fpc0

[Mar 13 10:57:37]: Checking pending install on fpc2

[Mar 13 10:57:38]: Checking pending install on fpc1
[Mar 13 10:58:04]: Pushing bundle to fpc0
[Mar 13 10:58:30]: Pushing bundle to fpc2

[Mar 13 10:58:59]: Validating on fpc0

[Mar 13 10:59:13]: Validating on fpc2

[Mar 13 10:59:14]: Validating on fpc1
[Mar 13 10:59:14]: Done with validate on all virtual chassis members

fpc0:
Verify the signature of the new package
Verified jinstall-ex-4200-13.2X50-D19.2-export.tgz signed by PackageProduction_13_2_0
WARNING: A reboot is required to install the software
WARNING:     Use the 'request system reboot' command immediately

fpc2:
Verify the signature of the new package
Verified jinstall-ex-4200-13.2X50-D19.2-export.tgz signed by PackageProduction_13_2_0
WARNING: A reboot is required to install the software
WARNING:     Use the 'request system reboot' command immediately

fpc1:
Verify the signature of the new package
Verified jinstall-ex-4200-13.2X50-D19.2-export.tgz signed by PackageProduction_13_2_0
WARNING: A reboot is required to install the software
WARNING:     Use the 'request system reboot' command immediately

You can reboot individual switches, but a member in the wrong version will not join the VC stack:

[email protected]> request system reboot member 2
Reboot the system ? [yes,no] (no) yes


Rebooting fpc2
[email protected]> show virtual-chassis

Virtual Chassis ID: f365.a9c6.1714
Virtual Chassis Mode: Enabled
                                           Mstr           Mixed Neighbor List
Member ID  Status   Serial No    Model     prio  Role      Mode ID  Interface
0 (FPC 0)  Prsnt    BN0208105351 ex4200-24p 255  Backup       N  1  vcp-0
                                                                 2  vcp-255/1/0
                                                                 1  vcp-1
1 (FPC 1)  Prsnt    BN0208084463 ex4200-24p 255  Master*      N  0  vcp-0
                                                                 0  vcp-1
2 (FPC 2)  Inactive BP0213260138 ex4200-48t 255  Linecard     N  0  vcp-255/1/0

The last switches remains inactive until all versions match. You can reboot all switches by issuing a request system reboot

Note, it’s possible to do NSSU on EX switches. Capabilities and versions matter. Juniper has a long document here showing how it works so I won’t repeat the information here.

NSR/NSB/GRES

A VC stack gives you multiple routing-engines of which one is active and a second is backup. Graceful routing engine switchover and non-stop bridging and routing are supported, but not enabled by default. It’s a simple matter to enable:

{master:1}[edit]
[email protected]# set chassis redundancy graceful-switchover
{master:1}[edit]
[email protected]# set ethernet-switching-options nonstop-bridging
{master:1}[edit]
[email protected]# set routing-options nonstop-routing

In order to verify you need to issue show system switchover on the backup RE:

[email protected]> show system switchover
fpc0:
--------------------------------------------------------------------------
Graceful switchover: On
Configuration database: Ready
Kernel database: Ready
Peer state: Steady State

GRE Tunneling

Juniper added support for GRE on EX in 12.1 onwards. Juniper requires you to convert a hardware port into a tunnel interface to do GRE encapsulation. The issue with this is that the gre interface is configured on the tunnel interface that was created. As this is tied to a single physical port, the loss of that port means the GRE tunnel goes down. Essentially this means if you lose the switch that is doing the tunnelling you lose the GRE tunnel. The only way around this is to create multiple tunnel interfaces with multiple GRE tunnels to systems that require it.
Configuring Generic Routing Encapsulation Tunneling

Embedded traffic capture on Junos and IOS-XE

IOS-XE and Junos both give you the ability to sniff packets directly on the device itself. This is pretty handy for troubleshooting without having to send an engineer to site with a laptop, potentialy with downtime.

Both are very flexible, so I won’t go over every single option possible on both. Rather I’ll just go over a basic capture and view on both platforms. For this post I’ll use a simple topology with an LACP interface between them to show how to get around a limitation or two:

I’ve enabled OSPF over the aggregated interface.

IOS-XE Setup

I want to view the OSPF hello packets over the port-channel. IOS-XE will not allow you to specify a port-channel interface, but you can specify a range. I’ll simply use a range of interfaces currently in the port-channel. Note that this is done in privileged exec mode and not in configuration mode:

C3850#monitor capture NEW_CAP interface range gi1/0/1 , gi2/0/1 both
C3850#monitor capture NEW_CAP match any
C3850#monitor capture NEW_CAP file location flash:CAP1.pcap

You are able to push the capture through an ACL to match all kinds of particular things. There are a load of options to change if needed. On a 3850 stack, the output needs to go to the current active switches’ flash or USB.

Without configuring any other options, take a look at the defaults used:

C3850#show monitor capture NEW_CAP

Status Information for Capture NEW_CAP
  Target Type:
   Interface: GigabitEthernet1/0/1, Direction: both
   Interface: GigabitEthernet2/0/1, Direction: both
   Status : Inactive
  Filter Details:
    Capture all packets
  Buffer Details:
   Buffer Type: LINEAR (default)
  File Details:
   Associated file name: flash:CAP1.pcap
  Limit Details:
   Number of Packets to capture: 0 (no limit)
   Packet Capture duration: 0 (no limit)
   Packet Size to capture: 0 (no limit)
   Packets per second: 0 (no limit)
   Packet sampling rate: 0 (no sampling)

There are no limits imposed anywhere. If you leave a capture on running to the flash, it could very easily fill the flash. I’ll impose a limit of 60 seconds on this capture to ensure we don’t fill up the flash:

C3850#monitor capture NEW_CAP limit duration 60

IOS-XE Capture

Let’s start the capture:

C3850#monitor capture NEW_CAP start
*Feb 26 08:23:48.854 GMT: %BUFCAP-6-ENABLE: Capture Point NEW_CAP enabled.

I can either run this for 60 seconds, or stop it manually:

C3850#monitor capture NEW_CAP stop
*Feb 26 08:24:19.584 GMT: %BUFCAP-6-DISABLE: Capture Point NEW_CAP disabled.

Very simple.

IOS-XE – View Captures

IOS-XE has a terse output:

C3850#show monitor capture file flash:CAP1.pcap
  1   0.000000     10.0.0.2 -> 224.0.0.5    OSPF Hello Packet
  2   7.868018     10.0.0.2 -> 224.0.0.5    OSPF Hello Packet
  3  15.429030     10.0.0.2 -> 224.0.0.5    OSPF Hello Packet
  4  23.035002     10.0.0.2 -> 224.0.0.5    OSPF Hello Packet

You can also see the entire detail:

C3850#show monitor capture file flash:CAP1.pcap  detailed
Frame 1: 94 bytes on wire (752 bits), 94 bytes captured (752 bits)
    Arrival Time: Feb 26, 2014 08:23:53.939938000 UTC
    Epoch Time: 1393403033.939938000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 94 bytes (752 bits)
    Capture Length: 94 bytes (752 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:ospf]
Ethernet II, Src: 3c:61:04:d9:73:80 (3c:61:04:d9:73:80), Dst: 01:00:5e:00:00:05 (01:00:5e:00:00:05)
    Destination: 01:00:5e:00:00:05 (01:00:5e:00:00:05)
        Address: 01:00:5e:00:00:05 (01:00:5e:00:00:05)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: 3c:61:04:d9:73:80 (3c:61:04:d9:73:80)
        Address: 3c:61:04:d9:73:80 (3c:61:04:d9:73:80)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.2 (10.0.0.2), Dst: 224.0.0.5 (224.0.0.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)
        .... ..0. = ECN-Capable Transport (ECT): 0

etc....
etc....

It’s also possible to capture directly to the screen:

C3850#monitor capture NEW_CAP start display detailed
A file by the same capture file name already exists, overwrite?[confirm]
Frame 1: 94 bytes on wire (752 bits), 94 bytes captured (752 bits)
    Arrival Time: Feb 26, 2014 08:31:20.753958000 UTC
    Epoch Time: 1393403480.753958000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 94 bytes (752 bits)
    Capture Length: 94 bytes (752 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:ospf]
Ethernet II, Src: 3c:61:04:d9:73:80 (3c:61:04:d9:73:80), Dst: 01:00:5e:00:00:05

IOS-XE Notes

  • The capture configuration is not saved in global config, but the config is still there. In order to remove your monitor session you need to explicitly delete it from privileged exec mode:
C3850#no monitor capture NEW_CAP
  • Embedded wireshark can capture data-plane traffic, as well as control-place traffic

Junos Capture

Start up a shell:

[email protected]> start shell user root
Password:

Junos has tcpdump built-in. For this part I’ll write a file to the tmp folder which we can the view later:

[email protected]% tcpdump -i ae0.0 -w /tmp/CAP2.pcap
Address resolution is ON. Use  to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ae0.0, capture size 96 bytes

Junos – view captures

We can use tcpdump to view the files we created:

[email protected]% tcpdump -qn -r /tmp/CAP2.pcap
23:51:58.856149 Out IP truncated-ip - 20 bytes missing! 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 60
23:51:58.991515  In IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:08.531670  In IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:08.744550 Out IP truncated-ip - 20 bytes missing! 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:17.460023 Out IP truncated-ip - 20 bytes missing! 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:17.640020  In IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:25.978974 Out IP truncated-ip - 20 bytes missing! 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:26.888403  In IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:33.517479 Out IP truncated-ip - 20 bytes missing! 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:36.858979  In IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:42.147688 Out IP truncated-ip - 20 bytes missing! 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:46.407409  In IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:49.663809 Out IP truncated-ip - 20 bytes missing! 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 60
23:52:55.448971  In IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length 60

If you wanted to quickly see traffic going over an interface without saving a file, you can do it directly from the cli:

[email protected]> monitor traffic interface ae0.0 detail
Address resolution is ON. Use  to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ae0.0, capture size 1514 bytes

Reverse lookup for 10.0.0.1 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use  to avoid reverse lookups on IP addresses.

23:56:24.203372  In IP (tos 0xc0, ttl   1, id 65445, offset 0, flags [none], proto: OSPF (89), length: 80) 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48]
        Router-ID 192.168.255.100, Backbone Area, Authentication Type: none (0)
        Options [External, LLS]
          Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 1
          Neighbor List:
            10.0.0.2
          LLS: checksum: 0xfff6, length: 3
            Extended Options (1), length: 4
              Options: 0x00000001 [LSDB resync]
23:56:24.527779 Out IP (tos 0xc0, ttl   1, id 62974, offset 0, flags [none], proto: OSPF (89), length: 80) 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48]
        Router-ID 10.0.0.2, Backbone Area, Authentication Type: none (0)
        Options [External, LLS]
          Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.0, Priority 128
          Neighbor List:
            192.168.255.100
          LLS: checksum: 0xfff6, length: 3
            Extended Options (1), length: 4
              Options: 0x00000001 [LSDB resync]

Junos notes

  • Traffic captured on Junos is control-plane traffic only. It cannot capture data-plane traffic

So how does the JNCIE-SP compare to the CCIE R&S?

This is not an apples to apples comparison. The tracks are different so it’s difficult to give a thorough review.

Now that I have taken and passed both I can give a little info on how they compare. I’ll be blunt right from the start. The CCIE R&S was a LOT more difficult.

I work in an ISP for a living and so MPLS/BGP is a quite an easy subject. Requirements in exams can be quite ‘odd’ – but no more so than real life. I’ve been in this game too long to know that you some customer requirements are simply off the charts in craziness.

The CCIE R&S is a lot more time-intense. You have a 2 hour TS section followed by 6 hours config. In the JNCIE-SP it certainly felt like I had roughly the same amount of config work, but I had 8 hours to do so. Yes there was some TS in the config section itself, but it’s certainly not like the CCIE TS. It’s perhaps this reason I finished with well over 3 hours to spare and simply used that time to verify everything at least three times.

On the way to my CCIE I learned a lot of lessons which I pulled over into my JNCIE prep. One of the most important ones is learning how to verify. Config is easy. How do you prove that something works though? This is absolutely vital in both exams as well as real life. Another lesson was don’t believe what you read until you’ve labbed it up and seen for yourself. Not just how your devices operate, but what kind of packets do they send at each stage? Load up wireshark and see for yourself.

I much preferred the CCIE lab room over the JNCIE lab room. Cisco provide much bigger screens which is helpful on an 8 hour lab exam. Juniper provided only laptops which was upsetting considering we pay a lot of money for these exams.

Cisco provide you with a result generally within 3 days, but usually by the next day. I waited just over two weeks to get my JNCIE result. Sitting a lab exam is a bit of a rush and that rush dies out pretty quickly. By the time I got my JNCIE the lab rush was long gone and it certainly felt that way when I received my result. While result time is not ‘vital’ to get quick, it made a big difference to how I felt. Maybe that’s just me?

resource-wise there is a lot more training out there for CCIEs. I used the very excellent INE vol2 workbook for my CCIE prep. For the JNCIE-SP I used the InetZero SP workbook. There is less material in the InetZero book compared to the equivalent INE WB. For this reason I think it’s a bit too expensive for what it is, however it’s still a great resource to learn though. If you need go deep configuring MPLS and BGP policies in Junos it’s most certainly the book for you.

I also took one Proteus Networks SP mock exam which I felt was very close to the real exam in difficulty. I initially wanted to take two but ran out of time to get my second one in.

Overall I would have spent a lot more time in the lab if I had not done my CCIE first. Once your know OSPF you know it. The biggest thing is simply learning how a different vendor does it’s defaults, and how you configure what you need.

I’ve definitely have a lot of fun doing both. What next?