Nov 11

Simple topology: two routers, connected via a (serial) link, each with a loopback interface configured on it.

Loopback 0 on R1 has the IP 2001:A::1/64 and Loopback 0 on R2 has the IP 2001:B::1/64.  We want to make R1 aware of the 2001:B::0/64 network and R2 aware of the 2001:A::0/64 network. RIPng would be the the easiest way of doing that.

First we need to enable IPv6 unicast routing, and then start the RIP process on the interfaces.

R1(config)#ipv6 unicast-routing
R1(config)#ipv6 router rip SIMPLE_RIP
R1(config)#interface lo0
R1(config-if)#ipv6 address 2001:A::1/64
R1(config-if)#ipv6 rip SIMPLE_RIP enable

R2(config)#ipv6 unicast-routing
R2(config)#ipv6 router rip SIMPLE_RIP
R2(config)#interface lo0
R2(config-if)#ipv6 address 2001:B::1/64
R2(config-if)#ipv6 rip SIMPLE_RIP enable

We also need to activate the RIP process on the transit link and make the interface IPv6 enabled.

R1(config)#interface s0/1/1

R1(config-if)#ipv6 rip SIMPLE_RIP enable

R1(config-if)#ipv6 enable

R2(config)#interface s0/1/1

R2(config-if)#ipv6 enable

R2(config-if)#ipv6 rip SIMPLE_RIP enable

As it can be noticed, we haven’t configured a global IPv6 address on the interface, yet, RIP will do it’s job.

R2#sh ipv6 route
IPv6 Routing Table – 5 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route
I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
D – EIGRP, EX – EIGRP external
R   2001:A::/64 [120/2]
via FE80::219:E8FF:FEF2:8F3A, Serial0/1/1

C   2001:B::/64 [0/0]
via ::, Loopback0
L   2001:B::1/128 [0/0]
via ::, Loopback0
L   FE80::/10 [0/0]
via ::, Null0
L   FF00::/8 [0/0]
via ::, Null0

The reason why it works, it’s a link local address, which is automatically configured once you turn on IPv6 on the interface. If the command “(config-if)#ipv6 enable” would have been missing, there would have been no exchange of routes.

Let us now analyze a possible misconfiguration. Let’s configure a global address on the link. What first comes to mind is IPv4 rule that stated that the serial interface of each router has to be configured in the same broadcast domain.  We will configure the serial interface on R1 with 2001:C::1/64 and serial interface on R2 with 2001:D::1/64 (clearly in different subnets).

R1#show ipv6 interface serial 0/1/1
Serial0/1/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::219:E8FF:FEF2:8F3A
No Virtual link-local address(es):
Global unicast address(es):
2001:C::1, subnet is 2001:C::/64

R2#show ipv6 interface serial 0/1/1
Serial0/1/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::21A:2FFF:FE2A:2118
No Virtual link-local address(es):
Global unicast address(es):
2001:D::1, subnet is 2001:D::/64

Even if we don’t have the two routers in the same subnet from the global address perspective, they are in the same broadcast domain from the link local address point of view. The traffic will still be routed via the link local address, because it’s actually “closer”.

R   2001:A::/64 [120/2]
via FE80::219:E8FF:FEF2:8F3A, Serial0/1/1

So, if your routes are flowing when you are thinking that they shouldn’t, you might want to remember the link local address.

Thanks go out to BogdanD for help with case study.

Nov 8

To lower broadcast traffic in our network or for some extra security we use Virtual LANs. Cisco switches can be configured with Ethernet VLAN IDs ranging from 1 to 1001 and, with the extended VLANs, from 1006 to 4096. For trunking, we can use the IEEE 802.1Q (dot1q) protocol that can support the extended VLANs (1-4096).

The fisrt important rule of implementing VLANs in a network tells us that a switch won’t forward a frame from a VLAN if it does not know about that VLAN. All the switches in a network need to know about all the VLANs regardless of the fact that they have or not local access ports in those VLANs. So, we need to go to every switch and configure all the VLAN IDs, or we could use VTP (VLAN Trunking Protocol), Cisco’s proprietary protocol that automatically configures network-wide all the VLANs. Remember, VTP is on by default, in Server mode.

But the use of VTP can sometimes lead to unexpected behavior on the switch. Most common is when you try to reset your switch and you delete the running-config and the flash:vlan.dat, reload the IOS and find all your VLANs still there. If you have VTP configured in your network (without authentication), upon boot-up, the switch will get the VLAN information from it’s VTP neighbors, the reason being that the default configuration is Server mode. The solution would be to set the switch in Transparent mode and delete the VLANs.

The configuration of VTP Transparent mode causes another strange exception. As we are have studied in CCNA, the vlan.dat file in flash holds the VLAN information for a switch, not the running-config in NVRAM. This is not true when dealing with Transparent mode. If the switch is in VTP transparent mode, the VLAN information IS stored in running-config. So, if you configure vtp mode transparent, configure some VLANs, delete the vlan.dat and reboot, you will find the VLANs still there.

One more situation where VLANs are stored in running-config is when we use extended VLANs. Regardless of VTP mode, if we configure a VLAN with an ID greater than 1006, it will be stored as an entry in running-config. Extended VLANs will NOT be carried through VTP, so it makes sense not to store them in vlan.dat, because the switch will try to synchronize the file with the VTP information.

Nov 4

In labs we use reverse telnet to access our equipment (as in “routers and switches”) directly into console. To make things a little bit easier for our students we created a web page with “telnet://” links pointing directly to each router/switch.
That should be enough to solve all those pesky little questions like “what was that address again ?”. And it is. At least when the computer used by our students is running Windows. But we do have a little problem because all our computers in the lab are running Ubuntu. And Firefox. And it appears that Firefox in Ubuntu doesn’t know how to handle “telnet://” links.

I solved the problem by installing Opera browser and add the telnet handler in Opera. Or even better, install Opera and Putty and use Putty to handle “telnet://”. But the problem with Firefox kept bugging me and even if I’m lazy i knew that it became personal.
So I started to search the allmighty internet. I found out that I can add telnet protocol in user prefs in Firefox. But it didn’t work. So I kept searching and finally I’ved put the bits and pieces together and solved the problem. Here it goes.

First thing to do is to tell Firefox that we WANT to use telnet:// links. To do that we must open Firefox and type “about:config” in address bar. And we create a new boolean preference (right click on an empty space), name it “network.protocol-handler.expose.telnet” and set the value “false” and restart the browser. That should be enough for Firefox to let us select an external application to open “telnet://” links.
From this point forward we can choose the easy way and choose putty or the hard way and use gnome-terminal/xterm/konsole. The “hard way” because telnet in terminal doesn’t know how to handle “address:port” format. So how should we do that ? Simple, we create a shell script and we use that script as the default application to open “telnet://” links in Firefox.

The script is pretty easy :


#!/bin/sh

address=`echo ${*##telnet://} | sed 's/:/ /g'`

#For xterm junkies :
xterm -e "telnet $address"

#For gnome-terminal users :
#uncomment the next line but comment
#all other terminal launchers (xterm, konsole)
#gnome-terminal -e "telnet $address"

#For konsole hipsters :
#konsole sends args separately to command so we use "" only for telnet
#uncomment the next line but comment
#all other terminal launchers (gnome-terminal, xterm)
#konsole -e "telnet" $address

And voila, sit back, relax and enjoy a cold beer…

Nov 4

Networking is sometimes hard not because of the concepts that you need to apply, but because of the difference in implementation of some protocols on the equipment. For example, the default settings for DTP differ from one switch model to the next.

DTP (Dynamic Trunking Protocol) is used to negotiate a trunk link between two switches. From the DTP point of view, a port can be ‘desirable‘ (it will actively try to negotiate a  trunk), ‘auto‘ (it will form a trunk if the other side wants to be a trunk) and ‘non-negotiate‘ (port will not negotiate the link). The reason for this protocol is to have a working access or trunk link immediately after you connect the switch to the network.   Most of the combinations are:

  • auto – auto => access
  • auto – desirable => trunk
  • desirable-desirable => trunk
  • auto – trunk => trunk
  • auto – access => access
  • desirable – trunk => trunk
  • desirable – access => access

What you should pay attention to is the default setting of a port on different switch models. On a 2950 (Layer 2 switch) and a 3550 (Layer 3 switch), a port is, before any configurations, in desirable. If you connect two of these switches, you will have a trunk link formed. On the other hand, on a 2960 or a 3560, a port is in auto, so between these models, you will have an access port (by default, in VLAN 1). Even more problems could arrive when you have in a network switches of different models. If you connect a 2960 and a 2950, because the first is in auto and the second  is in desirable, a trunk link will be negotiated, so you should be careful when dealing with these kinds of situations.

Nov 3

Run remote procedures & GNS3

Posted by Dragos Draghicescu

An interesting and pretty new capability of Cisco IOS is scripting through TCL language. What is not that well documented is that you can configure a router in some situations and the interesting thing is that you can store the configuration procedure remotely, like on a tftp server for example. What I will present may be useful in lab environments, for simulation purposes. I used it to prepare a huge exercise for the CCNA 2 class.

First of all, I will suppose that you have configured a tftp server somewhere in your LAN. Second thing is you can configure a bridge between your Ethernet interface and a tap interface (a virtual interface, for use with the emulated router). In Linux, you can use the Bridge-utils and uml-utilities to do that. You can find a tutorial on how to do a bridge <here>.

Now lets get to work! :)

In GNS3 (ran as root) you have to link the router with a clouds tap interface. In the cloud configuration panel, add a tap interface into the NIO tap tab (lets say tap0). Next, configure the router interface IP address like its part of your LAN. You can ping your gateway to verify that.

It’s all said and done. The script I wrote reads a number of Loopback interfaces to be configured from the user input. The output looks like this:

IOS output

IOS output

The output is incomplete, but the script configured Loopback 0 to 4 with ip addresses.

I hope some will find what can be done with IOS TCL pretty interesting.

Good luck!

DD