Category Archives: Cisco

ISIS Authentication types (packet captures)

In this post i would like to highlight a couple of “features” of ISIS.
More specifically the authentication mechanism used and how it looks in the data plane.

I will do this by configuring a couple of routers and configure the 2 authentication types available. I will then look at packet captures taken from the link between them and illustrate how its used by the ISIS process.

The 2 types of Authentication are link-level authentication of the Hello messages used to establish an adjacency and the second type is the authentication used to authenticate the LSP’s (Link State Packet) themselves.

First off, here is the extremely simple topology, but its all thats required for this purpose:

Simple, right? 2 routers with 1 link between them on Gig1. They are both running ISIS level-2-only mode, which means they will only try and establish a L2 adjacency with their neighbors. Each router has a loopback interface, which is also advertised into ISIS.

First off, lets look at the relevant configuration of CSR-02 for the Link-level authentication:

key chain MY-CHAIN
 key 1
  key-string WIPPIE
!
interface GigabitEthernet1
 ip address 10.1.2.2 255.255.255.0
 ip router isis 1
 negotiation auto
 no mop enabled
 no mop sysid
 isis authentication mode md5
 isis authentication key-chain MY-CHAIN

Without the same configuration on CSR-01, this is what we see in the data path (captured on CSR-02’s G1 interface):

And we also see that we dont have a full adjacency on CSR-01:

CSR-01#sh isis nei

Tag 1:
System Id       Type Interface     IP Address      State Holdtime Circuit Id
CSR-02          L2   Gi1           10.1.2.2        INIT  26       CSR-02.01

Lets apply the same authentication configuration on CSR-01 and see the result:

key chain MY-CHAIN
 key 1
  key-string WIPPIE
!
interface GigabitEthernet1
 ip address 10.1.2.1 255.255.255.0
 ip router isis 1
 negotiation auto
 no mop enabled
 no mop sysid
 isis authentication mode md5
 isis authentication key-chain MY-CHAIN

We now have a full adjacency:

CSR-01#sh isis neighbors 

Tag 1:
System Id       Type Interface     IP Address      State Holdtime Circuit Id
CSR-02          L2   Gi1           10.1.2.2        UP    8        CSR-02.01     

And we have routes from CSR-02:

CSR-01#sh ip route isis | beg Gate
Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets
i L2     2.2.2.2 [115/20] via 10.1.2.2, 00:01:07, GigabitEthernet1

Now, this is what we now see from CSR-02’s perspective again:

The Link-level authentication is fairly easy to spot in no time, because you simply wont have a stable adjacency formed.

The second type is LSP authentication. Lets look at the configuration of CSR-02 for this type of authentication:

CSR-02#sh run | sec router isis
 ip router isis 1
 ip router isis 1
router isis 1
 net 49.0000.0000.0002.00
 is-type level-2-only
 authentication mode text
 authentication key-chain MY-CHAIN

In this example, i have selected plain-text authentication, which i certainly dont recommend in production, but its great for our example.

Again, this is what it looks like in the data packet (from CSR-01 to CSR-02) without authentication enabled on CSR-01:

As you can see, we have the LSP that contains CSR-01’s prefixes, but nowhere is authentication present in the packet.

Lets enable it on CSR-01 and see the result:

CSR-01#sh run | sec router isis
 ip router isis 1
 ip router isis 1
router isis 1
 net 49.0000.0000.0001.00
 is-type level-2-only
 authentication mode text
 authentication key-chain MY-CHAIN

The result in the data packet:

Here we clearly have the authentication (with type = 10 (cleartext)) and we can see the password (WIPPIE) because we have selected cleartext.

The result is we a validated ISIS database on both routers.

Thats all folks, hope it helps to understand the difference between the 2 types of authentication in ISIS.

Take care!

 

 

Progress update – 10/07-2017

Hello folks,

Im currently going through the INE DC videos and learning a lot about fabrics and how they work along with a fair bit of UCS information on top of that!

Im spending an average of 2.5 hours on weekdays for study and a bit more in the weekends when time permits.

I still have no firm commitment to the CCIE DC track, but at some point I need to commit to it and really get behind it. One of these days 😉

I mentioned it to the wife-to-be a couple of days ago and while she didn’t applaud the idea, at least she wasn’t firmly against it, which is always something I guess! Its very important for me to have my family behind me in these endeavours!

Im still a bit concerned about the lack of rack rentals for DCv2 from INE, which is something I need to have in place before I order a bootcamp or more training materials from them. As people know by now, I really do my best learning in front of the “system”, trying out what works and what doesn’t.

Now to spin up a few N9K’s in the lab and play around with NX-OS unicast and multicast routing!

Take care.

Snippet: The story of the EFP

For a while now, the concept of EVC’s (Ethernet Virtual Circuits) and EFP’s (Ethernet Flow Points), has eluded me.

In this short post, i will provide you with a simple example of a couple of EFP’s. In a later post i will discuss the MEF concept of EVC’s.

As always, here is the topology i will be using:

topology

Its a very simple setup. R1 connects to R2 through its G1 interface and connects to R3 through its G2 interface.

On R2 and R3, we have the very common configuration of using subinterfaces for the individual Vlan’s in question. Namely Vlan 10 for the connection between R1 and R2 and Vlan 20 between R1 and R3.

Here is the configuration of R2 and R3:

R2#sh run int g1.10
Building configuration...
Current configuration : 98 bytes
!
interface GigabitEthernet1.10
encapsulation dot1Q 10
ip address 10.10.10.2 255.255.255.0
end

R3#sh run int g1.20
Building configuration...
Current configuration : 98 bytes
!
interface GigabitEthernet1.20
encapsulation dot1Q 20
ip address 10.10.10.3 255.255.255.0
end

Now on R1 is where the “different” configuration takes place:

R1#sh run int g1
Building configuration...
Current configuration : 182 bytes
!
interface GigabitEthernet1
no ip address
negotiation auto
service instance 10 ethernet
encapsulation dot1q 10
rewrite ingress tag pop 1 symmetric
bridge-domain 10
!
end

R1#sh run int g2
Building configuration...
Current configuration : 182 bytes
!
interface GigabitEthernet2
no ip address
negotiation auto
service instance 20 ethernet
encapsulation dot1q 20
rewrite ingress tag pop 1 symmetric
bridge-domain 10
!
end

R1#sh run int bdi10
Building configuration...
Current configuration : 96 bytes
!
interface BDI10
description -= Our L3 interface =-
ip address 10.10.10.1 255.255.255.0
end

So what does this all mean!? – Well, basically what you are looking at is the very nature of an EFP. One on each physical interface in this case. It is defined under the “service instance” command structure.

An Ethernet Flow Point (EFP) is a way to match a certain ethernet frame, do an action on it ingress (and also in our case egress). On top of that you can attach it to a bridge-domain.

The result of the above configuration is that on G1, we match on the dot1q tag when its tagged with vlan 10. On ingress we then pop 1 tag before performing any other “upstream” action. With the symmetric keyword, we attach the vlan 10 tag when egressing.

On G2, we are doing the same, but with vlan 20 instead.

With both EFP’s we attach a bridge-domain (ID 10), which can be verified like this:

R1#show bridge-domain
Bridge-domain 10 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
BDI10 (up)
GigabitEthernet1 service instance 10
GigabitEthernet2 service instance 20
AED MAC address Policy Tag Age Pseudoport
- 001E.7AE0.11BF to_bdi static 0 BDI10

Right now we only have one mac address learned, namely of our L3 BDI interface. But we can see that both G1 and G2 has a service instance in this bridge-domain.

Lets try and do some ICMP tests from R2:

R2#ping 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/120/598 ms

Lets again verify our bridge-domain on R1:

R1#show bridge-domain
Bridge-domain 10 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
BDI10 (up)
GigabitEthernet1 service instance 10
GigabitEthernet2 service instance 20
AED MAC address Policy Tag Age Pseudoport
- 001E.7AE0.11BF to_bdi static 0 BDI10
0 0050.56BE.18D8 forward dynamic 276 GigabitEthernet1.EFP10

What we see now, is that a Mac address has been dynamically learned through the G1.EFP10 EFP.

Since we are technically “bridging” these two distinct vlans, we should be able to ping R3 from R2 as well:

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

And again on R1:

R1#show bridge-domain
Bridge-domain 10 (3 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
BDI10 (up)
GigabitEthernet1 service instance 10
GigabitEthernet2 service instance 20
AED MAC address Policy Tag Age Pseudoport
- 001E.7AE0.11BF to_bdi static 0 BDI10
0 0050.56BE.320A forward dynamic 287 GigabitEthernet2.EFP20
0 0050.56BE.18D8 forward dynamic 287 GigabitEthernet1.EFP10

We have now learned all the Mac addresses in our small test environment.

So thats basically all there is to an EFP. A simple way of providing a flexible way of matching frames.

Until next time! – Take care.