ISP LAB (Implementing IGP) – Part 2

In this post we are going to accomplish the first task of our simple ISP LAB which is Implementing IGP “Interior Gateway Protocol“, as we mentioned before and shown in the topology we are going to use ISIS as the main L3 routing protocol “IGP”.

It is known that IGPs are used to exchange internal network routes/prefixes, so it is the same for any ISP but to be accurate in the ISP core we only care about Loopback addresses, so every single router will advertise it’s own Loopback address to all network partners to be used in reaching any IP or VPN networks beyond it. after exchanging the Loopbacks – and connected interfaces too but we don’t care about them – every router will assign labels for own advertised prefixes and inform it’s neighbors with these labels then the neighbor will assign random labels for these prefixes and inform it’s neighbors till reaching the Edge of the MPLS “Multi-Protocol Label Switching” network, these labels are assigned and distributed using LDP “Label Distribution Protocol“.

The usage of labels will be illustrated in the upcoming parts, but our task implementing the IGP which will be frankly used by the LDP in the next tasks in labeling.

Actually inside the ISP core we have multiple choices of IGPs to use like the well known OSPF “Open Shortest Path First” and the powerful Integrated ISIS “Intermediate System – Intermediate System”. Choosing IGP depends on the current network and the needs which is illustrated before in ISIS vs OSPF. In our network we are going to implement ISIS which is easy and straight forward but actually if you didn’t deal with it before, this time it may appears scary and it’s addressing scheme as a monster which is totally wrong idea and you could check the history of ISIS and the addressing scheme in Integrated IS-IS [Part 1], trust me you will find it so easy.

Ok lets start and finish our task… [refer to the topology: ISP LAB Topology – Part 1]

Our ISP network consists of P1, P2, P3, PE01, PE02 and PE03. “P” means Provider (core) and “PE” means Provider Edge which is connected to “CEs” Customer Edges.

First of all we are going to configure the Loopbacks and directly connected interfaces as mentioned in the Topology. Loopbacks should be configured as host routes /32 for reasons shown in MPLS PHP misbehavior.

P1 interfaces configuration
interface Loopback0
 ip address
 ip router isis abc
interface FastEthernet1/0
 ip address
 ip router isis abc
interface FastEthernet1/1
 ip address
 ip router isis abc
interface FastEthernet2/0
 ip address
 ip router isis abc

Directly connected interfaces are configured as the below example: 10.X.Y.ME, X is the small end, Y is the big end and ME so that if P1 is connected to P3 it would be like that: 10.10(X).30(Y).10(ME)

Also we configured these interfaces to start sending IIH “ISIS Hellos” out to discover neighbors you can read more about discovering neighbors in Integrated ISIS [Part2]. but we didn’t configure the ISIS instance so the “ip router isis abc” is not functional yet.
I am not going to show other routers configurations as it will be the same way and once you’re interested to reach this part of the topic so you’re aware enough how to figure out the rest.

Ok let’s configure the ISIS itself.

P1 ISIS configuration
router isis abc
 net 02.0010.0010.0010.0010.00
 is-type level-2-only

in this part of configuration we mentioned that we are configuring the ISIS instance abc so we should mention the same instance under used interfaces like shown before and this instance could be anything like a number or nothing at all, we also configured the net address showing that we are using the Area “02” and the System ID “0010.0010.0010.0010” again you would know more about these NSAP addresses in Integrated IS-IS [Part 1]  we also mentioned that we only maintain Level-2 neighborships and databases which is also illustrated in the mentioned article.

According to the configuration part we could mention the level type under each interface by the command “isis circuit-type level-2-only” but making it as default is much better to save time and avoid human errors.

Also as long as we don’t need the Loopback interfaces trying to send out – to nothing it is virtual – IIHs so it is better to make it passive:

all routers
R(config)#interface loopback 0
R(config-if)#no ip router isis abc
R(config)#router isis abc
R(config-router)#passive-interface loopback 0

Now we are finished with this task by doing the same to all ISP routers, I hope that it was interesting to you and be with us we still have more to do…

Please follow and like us:

2 thoughts on “ISP LAB (Implementing IGP) – Part 2

Leave a Reply