INE’s CCIE R&S v5 topology for EVE-NG using CSR1000v

In my previous blog post I’ve adapted the INE’s CCIE Routing and Switching topology to be used with EVE-NG using IOSv (or vIOS) L3 images for routers and L2 images for switches.

Following the promise in that blog post, I’ve adapted the same topology using Cisco CSR1000v images for routers and IOSv L2 images for switches. There isn’t much to say about this topology since mostly is matching the original INE’s one for routers (including the configuration files) and the major difference is the utilization of virtual switches.

Since we’re using virtual switches, the configuration files for switches are still different. I’ve adapted these ones to match the interface names of IOSv-L2:

Real Switches – vIOS-L2

Fa0/1  - Gi0/0 - SW1 only connection to bridge

Fa0/19 - Gi0/2
Fa0/20 - Gi0/3
Fa0/21 - Gi1/0
Fa0/22 - Gi1/1
Fa0/23 - Gi1/2
Fa0/24 - Gi1/3

For convenience, the switches topology looks like this in EVE-NG:

CCIE R&S V5 Switches

For routers, the interfaces stays the same since we’re using CSR1000v images.

Here is how the network topology looks like. No surprise here, just added for convenience:

INE CCIE R&S v5 topology with csr1000v

If you don’t have the CSR1000v image added to your installation of EVE-NG, please download it (Cisco.com is a good starting point) and add it following these How-to:
HowTo add Cisco Cloud Service Router (CSR1000V NG) Denali and Everest
or
HowTo add Cisco Cloud Service Router (CSR1000V) – for pre Denali or Everest images.

If you’re curious I’m using csr1000v-universalk9.03.12.03.S.154-2.S3-std image when testing for this lab.

Before sharing the download links, a word of advice.

It may be that CSR1000v images are more stable and support all features when compared with IOSv-L3, however this comes with a cost in term of resources. Each node has by default 3GB RAM assigned and I wouldn’t recommend trying to decrease it.

Once the nodes boot up, the actual used RAM will be less, but still you need more resources to use CSR1000v.
My recommendation for 10 routers using CSR1000v images would be at least 16GB RAM assigned to the EVE-NG virtual machine. The same if you’re using EVE-NG on a bare metal machine.

Last but not least, somebody asked me when I’m going to provide the same topology with 20 routers.
No need. You can extend the default topology with as many devices as you want. The modified configuration files for labs with 20 routers are already modified and present in the archive you download. Just add the missing R11 until R20 devices.

If you encounter errors that are critical, please let me know and I’ll try to correct them.

Download files:
EVE-NG-INE-CCIEv5-Topology-CSR1000v.zip
INE-CCIEv5-RS-Initial-Configuration-for-EVE-NG-CSR1000v.zip

Happy labbing and let me know if you find these materials useful!

INE’s CCIE R&S v5 topology for EVE-NG

The last days I was working on adapting INE‘s lab topology, most specific the CCIE Routing and Switching v5 one, to be used in EVE-NG.

In my opinion, INE offers some of the best training materials for Cisco and Juniper certifications. Along certification training you can find in their All Access Pass Subscription valuable learning materials for Network Automation, Security and Traffic Analysis (like Wireshark).
By the way I’m not affiliated with nor this post is the result of some sponsorship from INE. I just wanted to have the possibility to use their materials on using the entire topology, including the Switches, in EVE-NG.

I’ve picked Cisco‘s vIOS L3 and L2 images to support the topology in EVE-NG. You can argue that vIOS is a bit unstable and lacks some features, that CSR1000v images are better when combined with real Cisco switches and so on. Yes yes, all these are quite right, but I’m not here to debate about the best way to create a topology, rather a simple and sustainable one which works even for low end devices with less resources (CPU, RAM). Is no secret that vIOS will use less resources than CSR1000v images.

It brings me great happiness to let you know that I’ve succeeded in adapting not only the topology (not that hard honestly), but also the initial configuration files. The challenge lies in the fact that vIOS L2 images are build to support Ethernet ports in group of four, resulting in a slight different naming convention.

If you’ll check INE’s CCIE R&S v5 topology, the Cisco switches are using the Port from 19 to 24 to interconnect. On switch SW1, Port 1 is used to bridge the switching part to the routing one. You cannot replicate this exact port configuration scheme using vIOS L2 images.

I was forced to come with an alternative scheme, to map the original interface to the virtual ones and to adapt the configuration files.

This is what I came with:

INE CCIE R&S v5 switches

The interface mapping is as follows:

Real Switches – vIOS-L2

Fa0/1  - Gi0/0 - SW1 only connection to bridge

Fa0/19 - Gi0/2
Fa0/20 - Gi0/3
Fa0/21 - Gi1/0
Fa0/22 - Gi1/1
Fa0/23 - Gi1/2
Fa0/24 - Gi1/3

For the Routers is easy, since the interfaces are almost the same:

CSR1000v – vIOS-L3

Gi1 - Gi0/1

Here is how the network topology looks like:
INE CCIR R&S v5 Topology

We have 10 Routers using vIOS-L3 and 4 Switches using vIOS-L2. The connections between routers and switches are facilitated by the Net bridge.
10 routers should be sufficient for most of the labs. However if you need more, just add nodes and connect them to the Net bridge using the Gi0/1 interface.

As said previously, the configuration files have been adapted to match the interfaces listed above. I’ve tried my best not to have any errors, I also did some testing, everything looks to be fine. Most probably you’ll notice some errors at the copy / paste, but these are just cosmetic and related mostly to some proprietary CSR1000v commands or management interface which is not needed in EVE-NG. If you encounter errors that are critical, please let me know and I’ll try to correct them.

If somebody from INE’s team reads this post (that would be something :)) and consider inappropriate to share the modified initial configuration files, please let me know and I’ll take them down. They are derived from the public available ones on the CCIE R&S v5 Topology Diagrams & Initial Configurations page and do not contain any workbook information or somehow else related to INE’s training materials.

Download files:
INE-CCIEv5-RS-Topology-for-EVE-NG.zip
INE-CCIEv5-RS-Initial-Configuration-for-EVE-NG.zip

Happy labbing and let me know if you find these materials useful!

Cisco switches and smartport macros

Smartport macros are not more than some templates you can define on Cisco switches that will apply the same configuration on multiple ports. It’s not a subject that needs too many discussions, but it can be useful for your Cisco certification preparation or real life Cisco switch administration.

Configuration is very simple and it goes something like this:

macro name ACCESS-PORT
switchport mode access
switchport access vlan 6
switchport voice vlan 7
spanning-tree portfast
spanning-tree bpdufilter enable
@

After this you apply the macro to a port or a range of ports:

interface range fa0/1 - 6
macro apply ACCESS-PORT

That’s it :)

A less known fact is that Cisco switches are having some predefined smartport macros, which can be really helpful. The smartport macros which you configure can be spotted with a simple “show running-config” command. This is not the case for the default smartport macros which cannot be seen in the running-config, so you may not be aware that they exist.

The default smartport macros can be seen using the following commands:

SW1#show parser macro brief
    default global   : cisco-global
    default interface: cisco-desktop
    default interface: cisco-phone
    default interface: cisco-switch
    default interface: cisco-router
    default interface: cisco-wireless

This will show you only a summary of the default smartport macros. If you want to see what are they configure to do, check the following command:

SW1# show parser macro
Total number of macros = 7
--------------------------------------------------------------
Macro name : cisco-global
Macro type : default global
# Enable dynamic port error recovery for link state failures.
errdisable recovery cause link-flap
errdisable recovery interval 60
 
# Config Cos to DSCP mappings
mls qos map cos-dscp 0 8 16 24 32 46 46 56
 
# Enable aggressive mode UDLD on all fiber uplinks
udld aggressive
 
# Enable Rapid PVST+ and Loopguard
spanning-tree mode rapid-pvst
spanning-tree loopguard default
spanning-tree extend system-id
--------------------------------------------------------------
Macro name : cisco-desktop
Macro type : default interface
# macro keywords $access_vlan
# Basic interface - Enable data VLAN only
# Recommended value for access vlan should not be 1
switchport access vlan $access_vlan
switchport mode access
 
# Enable port security limiting port to a single
# MAC address -- that of desktop
switchport port-security
switchport port-security maximum 1
 
# Ensure port-security age is greater than one minute
# and use inactivity timer
switchport port-security violation restrict
switchport port-security aging time 2
switchport port-security aging type inactivity
 
# Configure port as an edge network port
spanning-tree portfast
spanning-tree bpduguard enable
--------------------------------------------------------------
Macro name : cisco-phone
Macro type : default interface
# Cisco IP phone + desktop template
 
# macro keywords $access_vlan $voice_vlan
 
 
# VoIP enabled interface - Enable data VLAN
# and voice VLAN
# Recommended value for access vlan should not be 1
switchport access vlan $access_vlan
switchport mode access
 
# Update the Voice VLAN value which should be
# different from data VLAN
# Recommended value for voice vlan should not be 1
switchport voice vlan $voice_vlan
 
# Enable port security limiting port to a 2 MAC
# addressess -- One for desktop on data vlan and
# one for phone on voice vlan
switchport port-security
switchport port-security maximum 2
 
# Ensure port-security age is greater than one minute
# and use inactivity timer
switchport port-security violation restrict
switchport port-security aging time 2
switchport port-security aging type inactivity
 
# Enable auto-qos to extend trust to attached Cisco phone
auto qos voip cisco-phone
 
# Configure port as an edge network port
spanning-tree portfast
spanning-tree bpduguard enable
--------------------------------------------------------------
Macro name : cisco-switch
Macro type : default interface
# macro keywords $native_vlan
# Access Uplink to Distribution
# Do not apply to EtherChannel/Port Group
switchport trunk encapsulation dot1q
 
# Define unique Native VLAN on trunk ports
# Recommended value for native vlan should not be 1
switchport trunk native vlan $native_vlan
 
# Update the allowed VLAN range such that it
# includes data, voice and native VLANs
switchport trunk allowed vlan ALL
 
# Hardcode trunk
switchport mode trunk
 
# Configure qos to trust this interface
auto qos voip trust
 
# 802.1w defines the link as pt-pt for rapid convergence
spanning-tree link-type point-to-point
--------------------------------------------------------------
Macro name : cisco-router
Macro type : default interface
# macro keywords $native_vlan
# Access Uplink to Distribution
switchport trunk encapsulation dot1q
 
# Define unique Native VLAN on trunk ports
# Recommended value for native vlan should not be 1
switchport trunk native vlan $native_vlan
 
# Update the allowed VLAN range such that it
# includes data, voice and native VLANs
switchport trunk allowed vlan ALL
 
# Hardcode trunk
switchport mode trunk
 
# Configure qos to trust this interface
auto qos voip trust
mls qos trust dscp
 
# Ensure fast access to the network when enabling the interface.
# Ensure that switch devices cannot become active on the interface.
spanning-tree portfast trunk
spanning-tree bpduguard enable
--------------------------------------------------------------
Macro name : cisco-wireless
Macro type : default interface
# macro keywords $native_vlan
# Access Uplink to Distribution
switchport trunk encapsulation dot1q
 
# Define unique Native VLAN on trunk ports
# Recommended native vlan should NOT be 1
switchport trunk native vlan $native_vlan
 
# Update the allowed VLAN range such that it
# includes data, voice and native VLANs
switchport trunk allowed vlan ALL
 
# Hardcode trunk and disable negotiation to speed up convergence
switchport mode trunk
switchport nonegotiate
 
# Configure qos to trust this interface
auto qos voip trust
mls qos trust cos
 
# Ensure that switch devices cannot become active on the interface.
spanning-tree bpduguard enable
--------------------------------------------------------------
Macro name : VLAN_146
Macro type : customizable
switchport mode access
switchport access vlan 146
spanning-tree bpdufilter enable
--------------------------------------------------------------

To be honest I never used them like this, but they were a pretty good starting point to customize new smartport macros.

If you are rather interested in the Cisco switch interface macro command, I did write a post on this topic some years ago and you can read it here.


EtherChannel over 802.1q Tunneling

Consider the following topology:
EtherChannel over 802.1q Tunneling Topology

We have one Customer with two distributed locations (SW1, R1 and SW2, R2) connected over Provider backbone. What we want to create is something like this:

EtherChannel over Provider L2 cloud

If Provider support 802.1q and L2 tunneling we can achieve a nice Etherchannel between our 2 remote locations with direct CDP visibility. Also STP and VTP is supported, just like when these SW1 and SW2 switches are directly connected.

First, lets configure SW1 and SW2 Customer devices.

On the three interfaces connected to provider devices we want to configure LACP Etherchannel:

SW1 / SW2 Customer

interface FastEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 1 mode active
!
interface FastEthernet0/2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 1 mode active
!
interface FastEthernet0/3
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 1 mode active

Next we will configure the SW1 and SW2 ports connected to R1 and R2 devices:

SW1 / SW2 Customer

vtp mode transparent
vtp domain Customer
vlan 100
 name End2End
!
interface Fa0/10
switchport mode access
switchport access vlan 100

Of course another approach can be taken in terms of VTP, like having Server / Client configuration, but this was the simplest one to illustrate here.

Let’s add some IP addresses on the two routers R1 and R2:

R1 Customer

interface fa0/0
ip address 10.0.0.1 255.255.255.0

R2 Customer

interface fa0/0
ip address 10.0.0.2 255.255.255.0

Our job, as Customer, is done. What about the Provider configuration? Here is where “the magic” happens.

To provide our Customer with three end to end 802.1q tunnels, we need to create three VLANs, assign them to the interfaces pointing to Customer SW1 and SW2 and enable the 802.1q tunnels.

SW1 / SW2 Provider

vlan 10
vlan 20
vlan 30
!
interface FastEthernet0/1
 switchport access vlan 10
 switchport mode dot1q-tunnel
!
interface FastEthernet0/2
 switchport access vlan 20
 switchport mode dot1q-tunnel
!
interface FastEthernet0/3
 switchport access vlan 30
 switchport mode dot1q-tunnel

Of course SW1 and SW2 from Provider should have 802.1q trunk enable and allow the tranport of VLANs 10, 20 and 30:

SW1 / SW2 Provider

int fa0/4
switchport trunk mode dot1q
switchport mode trunk
switchport trunk allowed vlan 10,20,30

OK, we have the dot1q tunneling enabled now:

SW1 / SW2 Provider

show dot1q-tunnel
 
dot1q-tunnel mode LAN Port(s)
-----------------------------
Fa0/1
Fa0/2
Fa0/3

Still, the Customer wants Etherchannel functionality, CDP visibility and the ability to transport own VLAN information (remember we did configure Vlan 100 on the interface of SW1 / SW2 Customer pointing to R1 / R2). Let’s enable also these ones:

SW1 / SW2 Provider

interface FastEthernet0/1
l2protocol-tunnel point-to-point lacp
l2protocol-tunnel cdp
l2protocol-tunnel stp
no cdp enable
!
interface FastEthernet0/2
l2protocol-tunnel point-to-point lacp
l2protocol-tunnel cdp
l2protocol-tunnel stp
no cdp enable
!
interface FastEthernet0/3
l2protocol-tunnel point-to-point lacp
l2protocol-tunnel cdp
l2protocol-tunnel stp
no cdp enable

Perfect, now let’s do some “show” commands to see that everything is working.

SW1 / SW2 Customer

show etherchannel 1 summary | b Group
Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Fa0/1(P)   Fa0/2(P)   Fa0/3(P)
show spanning-tree vlan 100
 
VLAN0100
  Spanning tree enabled protocol ieee
  Root ID    Priority    32868
             Address     0011.20ab.6180
             Cost        9
             Port        56 (Port-channel1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
 
  Bridge ID  Priority    32868  (priority 32768 sys-id-ext 100)
             Address     0014.a86b.f600
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300
 
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/10              Desg FWD 19        128.3    P2p
Po1                 Root FWD 9         128.56   P2p

OK, the Etherchannel is UP and the STP is showing correct values. Let’s see if we can do a simple “ping” from R1 to R2

R1#ping 10.0.0.2
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/24 ms

The Customer is happy, but what about the Provider, what does it see on the L2 infrastructure?

SW1 / SW2 Provider

show spanning-tree vlan 100
Spanning tree instance(s) for vlan 100 does not exist.

So, the Provider has no idea about Vlan 100 used by the Customer. This is because STP BPDUs from SW1 / SW2 Customer are tunneled inside dot1q-tunnel and hidden by the metro tags 10, 20 and 30.

One note for real life example, the Provider needs to support at least MTU 1504 so that Customer does not deal with packet fragmentation.