Hey Folks,

Here is an interesting Link State Protocol, which is rare to be used in SMB or Small Enterprises but most of ISPs are using this protocol, since it doesn’t require any enhanced or advance design concepts, however there are some restrictions and some features associated with this protocol so let’s first see how it is different from other protocols which are EIGRP and OSPF and then will digg onto the nice and simple lab:

– Intermediate System to Intermediate System (IS-IS), in this case Intermediate System is referred to Router which means Router to Router
– It is Link State Protocol Same as OSPF
– Mostly used in SP Core Network which has a Flat and Simple Network Design for high scalable platforms
– It Support both Version of IPs which are IPv4 and IPv6 under same routing process (Different from other protocols which are OSPF and EIGRP)
– It is actually not part of IP Protocol which is part of CLNS Stack
– It can be enabled on the Global mode of the router same as other protocols with the issuance of Router ISIS and Process ID (Process ID is unique to the default Interior Router)
– We need to specify the NET (Network Entity Title) which is essentially CLNS Router-ID
– NET use the NSAP Addressing format which is Maximum of 20 Bytes and Minimum of 8 Bytes
– NET Format is as below:

AA.AAAA.AAAA.AAAA.AAAA.AAAA.AAAA.SSSS.SSSS.SSSS.NN

It can be easily classified as below:

A = Area ID ( NOT SAME AS OSPF )
S = System ID ( ROUTER – ID Inside the AREA )
N = N-Selector ( ALWAYS ZERO )

ISIS will form adjacency same as other routers but it has two specific Levels which are:

1. Level 1

• Intra Area Adjacency Only
• Like Not So Totally Stubby Area in OSPF
• Default Route to Exit
• Redistribution Allowed

2. Level 2

• Inter or Intra Area Adjacency
• Like AREA 0 in OSPF
• Must also be Contiguous ( BUT NOT SUPPORT VIRTUAL_LINKs)
• Can be used as a ABR for exit

Default when you enable the ISIS Process under any specific interface it is by default L1L2 and each level has a separate LSP Database (LSDB).

NOTE: In ISIS each router is one AREA and each interface is configured in different Domains with the Level Concept.

Level Adjacency must also match, if we want to connect one Domain to another we need to connect and form adj with L2 and L2 Router, and Each interface must form adj with it’s equivalent Level.

We have 2 Network Types in ISIS:

1. Broadcast
2. Point-to-Point

SO the basic understanding of the above protocol is enough to create and establish a Core Network with ISIS Protocol, let’s proceed with our LAB which is consists of Following Routers and IOSs:

– R1 – R6  = 7204 VXR (C7200-ADVIPSERVICEK9-M), Version 12.2 SRE
– XR1, XR2 = Cisco Official XRv Platform which Runs under VM

The topology which we will use as below:

 

In The above scenario EM ISP is providing the MPLS VPN Service For Base 4 Company which we will only focus on the ISIS Routing protocol since we have already shared and discussed with MPLS VPN Connection so doesn’t require to have the MPLS Implement here for this lab.

In the above topology R1 and XR2 are the CE Router, which R2 and XR1 are PE Routers, and rest which are R3,R4,R5,and R6 are all P Routers running in our Core Infrastructure.

Let’s see the Initial Configuration on all the routers and a verification:

Above configuration are the basic Layer 2 and Layer 3 connectivity and keep in mind that in between the routers there is Layer 2 Switch which is providing L2 connectivity between the Routers and that is only configured as a Trunk Links along with the VLANs for the specific Link.

Also we have the loopback interfaces assigned with the ip address of the Routers which is like Router 1, 1.1.1.1 and so on…

So now let’s start with the IS-IS Configuration on the Router 1 and onward upto XR2 and after that we will verify the configuration:

In the above configuration you can see that we simply enabled the ISIS routing process with the process ID of 10 which unique to the router and then we add the NET (network entity title).

NOTE: we start the Area ID from 49 and you might probably saw many configuration starting from 49. Actually this is the Private Range of the Area ID for the ISIS, which is same as RFC 1918 IP addresses starting from 10, 172 and 192.

We need to also specify the interface in which we need the ISIS process to be running, in this case we have our Interface GigaEthernet 0/0 which is connected to our R2 (PE Router). The default behavior is L1L2 and we will saw later how to change and what are the drawbacks.

You can see in the above configuration that the System ID is 01, which we used for Router 1 and we will ensure to have the unique System-ID for all other routers (System-iD is like the Router-ID in OSPF)

NOTE: First 00001 will be consider under the AREA ID and Second will consider as a System-ID.

Let’s see the configuration on Router 2:

We have configured the ISIS on the Router 2 with the System ID of 2 and enabled under all the interfaces. Let’s see R3,R4,R5 and R6:

NOW we will configure the ISIS Protocol under IOS XR, which is really nice and easy and only requires the basic understanding of the IOS XR, let’s see the configuration on XR1:

In the above configuration you can see that the enabling of the ISIS process under IOS XR is same as we enable it under IOS platform, and the NET command will still remain the same, now as we mentioned above that ISIS support both IPv4 and IPv6 under same process and same contexts so you can see that the process is enabling on each interface under the default ISIS router process, which is really quite powerful then IOS, and we also see how we can enable the IPv4 Unicast under the Interface category.

NOTE: the process will not start working unless you specify the address-family which is IPv4 in our case. Let’s see XR2’s Config:

There is really nothing special on XR 2 configuration.

Let’s start the Verification process from R1 onward:

You can see that we can easily reach the XR2’s interface connected to XR1, and the routing table on R1 shows us the full routing entries individually toward XR2, this is really not good design in real environment, since our Core Network is also visible to the end client, well there is many way to resolve this matter, but since we are focusing on ISIS we can proceed as below:

R1 has only connection to R2 so if we change the configuration of Level on R1 from default behavior which is L1L2, it will decrease the total amount of entries and reduce the database size, let’s see the clns neighborship of R1 with R2 along with ISIS neighbor table with R2:

You can see that R1 has the two neighborship with R2 which are Level 1 and Level 2, and as we mentioned above each level has it’s own database so let’s see the R1 ISIS Database for both levels:

You can see that R1 has two separate database for L1 and L2, which is really over killing for the router process, and each route is installed on the database not only once but twice, let’s resolve this issue by changing the R1 interface type to L1 from it’s default behavior which is L1L2:

Note: We can change the level type either globally or per interface, if we would like to have our full router to be resides on L1 or L2 then we can change under the global mode, else if we are running L2 and L1 then we can change per interface, in our case only R1 and XR2 will run the only L1 process, while R3,R4,R5 and R6 will run only L2. and our PE routers which are XR1 and R2 will run mutually both Levels:

For R1 we can change the level type as below:

You can see that we have inserted the is-type command under the ISIS routing process and we can see that we have the option of level-1 and level-1-2 along with level-2-only, in the above scenario we only need to have level-1 enabled on the R1, let’s see the ISIS Neighborship:

From the above changes you can see that R1 now only have Level 1 neighborship with R2 only and it will surely reduce the database size as well like below:

Perfect !! You can see that the size of the Database has been decreased and we only have one database for our L1 LSD, now let’s verify our routing table:

Wow that is looking pretty nice, so you can see the default route on Routing table of R1, but also you can see the two other routes of R2 which are all advertised to R1, this is because we have not yet changed the Levels on R2, let’s change and see the impact, but before let’s verify the nieghborship on R2:

You can see that R2 has the Level 1 process going with R1 but we need to also change the level type for the specific interface, as below:

As mentioned above R2 will act as a ABR so we need to have both L1 and L2 interfaces, in our case the link connected to R1 is the L1 and Link connected to R3 and R4 will be L2.

NOTE: we can also advertise the loopback addresses under the ISIS interface in one of the three ways:

1. Through the Enabling the ISIS Process Under Loopback Interface
2. Redistribute Connected
3. Passive-Interface loopback X (This will ensure that the route has been distributed but the hello’s will not be sent from this interface)

We will do the same as above on all the router except XR Routers which will be configured as below:

The same will be for XR2.

Now let’s jump back to R1 and see the routing table, and we can see that we have only one entry for the Loopback of R2 and all other entries are changed as soon as we changed the interface level type on R2 as well we can see the default route to exit:

Now let’s change the level type on all P routers which are R3,R4,R5 and R6 as below:

On IOS XR we can change the Level Type as below:

Now our end to end configuration is perfectly fine and we are having R1 > Loopback to XR2 > Loopback reachibility through a well-known and nice link-state protocol which is ISIS.

NOTE: If you want to also remove the Loopback interface from Router 1 Routing table, you can also change the Level-type of Loopback interface on R2, after changing the circuit type you can see only default route toward R2.

I hope this lab is pretty simple and well-understandable.

Cheers,