Monthly Archives: April 2016

L2TPv3 Tunneling

There are different L2VPN technologies like L2TPv3, VPLS, H-VPLS, AToM. Except L2TPv3, the others require a MPLS backbone. L2TP uses IP protocol 115



  • Layer 2 Tunneling Protocol v3 (L2TPv3)
  • Any transport over MPLS (AToM)


  • Virtual Private LAN Service (VPLS)
  • Hierarchical Virtual Private LAN Service (H-VPLS)

Payload agnostic

  • supports Ethernet, Frame-Relay, ATM, HDLC, PPP over IP
  • supports interworking (between different encap)

Note: Encapsulating means an extra MTU overhead, so we need to be careful to not fragmentation along the way.


The objective here is establish a Pseudowire (PW) between two routers (R2/R4) extending the Layer 2 between R1 and R5 for VLAN 156.

Assuming here we have connectivity for R2/R4 loopback’s, since we will use that as source for PW.

Configuration steps

  1. Define PW
    1. define local interface as the source of tunnel
  2. Define xconnect
    1. define peer, vcid and associate with PW recently created

vcid needs to be unique, in this case i choose the same as VLAN ID

R2(config)#pseudowire-class PW_156_L2TPV3
R2(config-pw-class)# encapsulation l2tpv3
R2(config-pw-class)# ip local interface Loopback0
R2(config-pw-class)# ip tos reflect

R2(config)#interface GigabitEthernet1.156
R2(config-subif)# encapsulation dot1Q 156
R2(config-subif)# no cdp enable
R2(config-subif)# xconnect 156 pw-class PW_156_L2TPV3

R4(config)#pseudowire-class PW_156_L2TPV3
R4(config-pw-class)# encapsulation l2tpv3
R4(config-pw-class)# ip local interface Loopback0
R4(config-pw-class)# ip tos reflect

R4(config)#interface GigabitEthernet1.156
R4(config-subif)# encapsulation dot1Q 156
R4(config-subif)# no cdp enable
R4(config-subif)# xconnect 156 pw-class PW_156_L2TPV3

R2#sh l2tun session all

L2TP Session Information Total tunnels 1 sessions 1

Session id 1881450243 is up, logical session id 32790, tunnel id 1984298019
Remote session id is 4260556922, remote tunnel id 82213150
Locally initiated session
Unique ID is 0
Session Layer 2 circuit, type is Ethernet Vlan, name is GigabitEthernet1.156:156
Session vcid is 156
Circuit state is UP
Local circuit state is UP
Remote circuit state is UP
Call serial number is 4100100002
Remote tunnel name is R4
Internet address is
Local tunnel name is R2
Internet address is
IP protocol 115
Session is L2TP signaled
Session state is established, time since change 00:00:06
2 Packets sent, 2 received
136 Bytes sent, 136 received
Last clearing of counters never
Counters, ignoring last clear:
2 Packets sent, 2 received
136 Bytes sent, 136 received
Receive packets dropped:
out-of-order:             0
other:                    0
total:                    0
Send packets dropped:
exceeded session MTU:     0
other:                    0
total:                    0
DF bit off, ToS reflect enabled, ToS value 0, TTL value 255
Sending UDP checksums are disabled
Received UDP checksums are verified
No session cookie information available
FS cached header information:
encap size = 24 bytes
45000014 00000000 ff73a16b 0a020202
0a040404 fdf2f07a
Sequencing is off
Conditional debugging is disabled
SSM switch id is 8212, SSM segment id is 4121

R2#sh l2tun tunnel all  

L2TP Tunnel Information Total tunnels 1 sessions 1

Tunnel id 1984298019 is up, remote id is 82213150, 1 active sessions
Locally initiated tunnel
Tunnel state is established, time since change 00:00:30
Tunnel transport is IP  (115)
Remote tunnel name is R4
Internet Address, port 0
Local tunnel name is R2
Internet Address, port 0
L2TP class for tunnel is l2tp_default_class
Counters, taking last clear into account:
70908 packets sent, 70725 received
5142824 bytes sent, 5127872 received
Last clearing of counters never
Counters, ignoring last clear:
70908 packets sent, 70725 received
5142824 bytes sent, 5127872 received
Control Ns 1925, Nr 56
Local RWS 1024 (default), Remote RWS 1024
Control channel Congestion Control is disabled
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 3
Total resends 0, ZLB ACKs sent 51
Total out-of-order dropped pkts 0
Total out-of-order reorder pkts 0
Total peer authentication failures 0
Current no session pak queue check 0 of 5
Retransmit time distribution: 0 0 0 0 0 0 0 0 0
Control message authentication is disabled

Configuring OSPF

R1(config)#router ospf 1
R1(config-router)# log-adjacency-changes
R1(config-router)# network area 0
R5(config)#router ospf 1
R5(config-router)# log-adjacency-changes
R5(config-router)# network area 0

Confirm we have OSPF neighbouring across the L2VPN

R1#show ip ospf neighborNeighbor ID     Pri   State           Dead Time   Address         Interface        1   FULL/BDR        00:00:32      GigabitEthernet1.156


Do you like dissect packets? You can do it here

References: – Layer Two Tunneling Protocol – Version 3 (L2TPv3)

IOS-XR Secure Domain Router (SDR)

Before we start with SDR concept, we need an introduction about virtualization techniques for creating virtualized router entities. A Hardware-Isolated Virtual Router (HVR) has hardware-based resource isolation between routing entities, whereas a Software-Isolated Virtual Router (SVR) comprises software-based resource isolation between routing entities.

Within SVRs, there are several models for achieving virtualization. One model allows for multiple guest operating systems to overlay on a host operating system.This approach tends to have a detrimental impact on scale because it introduces significant contention of resources.
In contrast, the HVR approach dedicates both control plane and data plane resources on a per-module boundary to individual virtual entities, so there is no sharing of either control plane or data plane resources.

Secure Domain Routers

Cisco routers (running IOS XR) can be partitioned into multiple, independent routers known as secure domain routers (SDRs), not VRFs’. With SDRs we can split a single physical system into multiple logically separated routers, with their own routing functions, but they share resources with the rest of the system. For example, the software, configurations, protocols, and routing tables assigned to an SDR belong to that SDR only, but other functions, such as chassis-control and switch fabric, are shared with the rest of the system.
To accommodate the high bandwidth and control plane needs in provider networks, especially POPs, Cisco IOS XR Software includes support for an HVR technology known as Secure Domain Routers (SDRs). SDRs provide full isolation between virtualized routing instances through the use of Distributed Route Processors (DRPs) for extra control plane resources. SDRs are defined on per-slot boundaries, with entire Route Processors (RPs) and Modular Services Cards (MSCs) dedicated to an SDR.


Comparison of Virtualization Technologies with Cisco IOS XR Software-Supported Secure Domain Router


Cisco Revises the CCNP Wireless Certification Program

The CCNP Wireless Exam Revisions document  will provide you with a summary of the updates that have been made to the new version of each exam.Through September 21, 2016, candidates can choose to take either the existing exams or the new exams or any combination of them both.
Effective September 22, 2016, if a candidates is still in process of attaining their CCNP Wireless certification, any existing exam they have passed will have earned them full credit towards the corresponding new exam as indicated in the chart below. Candidates will be required to complete their certification using the new exams.

A CCNP Wireless Migration Tool is available to assist students with the transition to the new exams.


CCNP Wireless certification

Cisco nV Technology

Cisco nV allows you to simplify operations and deployment of new services across different boundaries in a Service Provider network. But what is exactly this technology? It’s a single logical switch/router built by interconnecting an ASR9K and one or more smaller satellite switches. This switches act as a remote line cards, they are provisioned in ASR9K (called Host).



nV Edge Overview



nV System Overview


  • Control plane extension: Active RSP and standby RSP are on the different chassis,
    they sync up via external EOBC links “AS IF” they are in the same physical chassis
  • Data plane extension: bundle regular data links into special “nV fabric link” to simulate
    switch fabric function between two physical chassis to data packet across
  • No dedicated fabric chassis -> flexible co-located or different location deployment (No distance limitation)

nV Satellite


  • All Satellite Configuration is done on the Host (zero touch)
  • nV Satellite can greatly simplify access and aggregation networks
  • Support flexible access and agg network topologies
  • Satellite is a remote line card: Access ports have feature parity with ASR9K local ports
  • nV Satellite interface naming follows the same local interface naming convention:sat-ID / sat-slot / sat-bay / sat-port

Control Plane

Discovery Phase

  • CDP like protocol to discover Satellites
  • Heartbeat sent every second to detect failures

Control Phase

  • Inter-process Communication Channel (TCP socket)


On Satellite

  • Add nV-Tag to frames before forward to Edge

On the Host

  • Receive Frames with nV-Tag identifies Satellite Virtual Interface

Satellite Deployment Models

Mode 1: Static pinning (Any access ports could be mapped to any single fabric port.)

Mode 2:Fabric bundle (access ports are mapped to a fabric bundle)

Satellite Types: asr9000v, asr901, asr903


nV Satellite L2fabric, Ring Topologies

Since XR 5.1.1

  • Extending satellite connection across a Layer 2 network
  • A native 802.1Q tag is added to the Satellite-Host control and data plane protocol
  • Expanding to support ring, & cascaded topologies
  • Maintains the same plug & play operationalsimplicity
  • CFM/CCM used for fast failure detection*

* CFM/CCM for simple ring and cascading will be in future releases



BRKARC-2024 – Cisco ASR 9000 nV Technology and Deployment (2014 San Francisco)

Are you ready to R80?It is finally in!

No, it’s not fouls day…After a long delay we have the New generation Management Platform.

What is the R80 Upgrade Verification Service?

R80 Upgrade Verification Service is an upgrade verification and environment simulation service. You get customized support to help make your transition to R80 as seamless as possible, so you can optimize the features of R80, while ensuring compatibility with the existing security infrastructure. Click on follow link to get more information