Month: August 2013

There are different documents and books which are claiming that Administrative distance for static routes configured using exit interface is 1 and for the static route configured using next-hop IP address Administrative distance is 0.

R1(config)#ip route 20.0.0.0 255.255.255.0 10.10.2.1
R1(config)#ip route 20.0.0.0 255.255.255.0 fastEthernet 0/0

This is not true. Both of them are having AD value of 1. The confusion is coming from the info that directly connected interface has AD of 0, but static route outbound that interface is having the AD of 1.

For a long time I was confused about this. It was not clear to me what is the difference between setting the static route using next hop interface IP address instead of exit interface (outgoing interface) syntax. It seemed that both methods are the same and that you have basically two different ways to define static route on specific device for no particular reason.

It was not clear to me why would someone do this kind of option on networking device OS if there were no reason for doing so. In other words I was strongly convinced that there must be some difference between two configs and learning more detail about the process of routers recursive searches and Proxy ARP function did answer all my doubts.

So now is time to put it all on paper for you to see it:

You can define static route like this:

R1(config)#ip route 10.0.0.0 255.255.255.0 10.10.2.1

This means that all packets from R1 with destination address from 10.0.0.0/24 subnet will be forwarded out the interface leading to next hop device with 10.10.2.1 address on its interface.

Other way is to define the same static route like this:

R1(config)#ip route 10.0.0.0 255.255.255.0 fastEthernet 0/0

If fastEthernet 0/0 is the interface on R1 router that leads to next hop router with best path to 10.0.0.0/24

What’s the difference, which is better?

If you use next-hop address, you can conclude that your router will not have the information which interface must he use in order to route those packets out towards destination. R1 must then find an interface that is having 10.10.2.1 on other side.

Some of these things I read in books and some of them took me few days of troubleshooting and sweating to get to them so I give them for free here to save you fellow networker some time:

SLAAC

The mighty SLAAC is the preferred method of IPv6 allocation, but is it so mighty? Or it only seems to be mighty and magic? Your computers or mobile phones in order to use SLAAC must be convinced to do so by the router RA message. That message includes the A flag set beside the prefix and all other info. That kind of RA message will tell the device receiving the RA that he needs to make the “A” autoconfiguration on his interface using EUI-64 method.

But that’s not all.

RA messages will need to have also the O flag set. With the O flag end hosts will tell the router that they will use DHCP but only for the “O” other options. In the first place that other option will be DNS server IPv6 address which is not possible to get from router RA messages. Why? I’m sure that’s the most frequent IPv6 question. The fellows who made the RFC 4861 documents didn’t put that option inside RA Router Advertisement Message Format.

I did try to find a reason why not. Maybe the only partially reasonable answer is that DNS is a hierarchical system that needs to be centralised inside a network architecture and routers as devices that are running routing processes are distributed system (at least before we see SDN in real life). So the answer will be that is not okay to put allocation of DNS address rule on a system that is not centralised. It means that if you need to change DNS in a network with a lot of routers that are sending RA messages on their local subnets you would need to change the config on all routers one by one. That is the best answer that I did find until now, but this sounds more like an excuse that a real reason for this decision. If you put all the info together with the answer that fellows from RFC 4861 did actually make the wrong decision is in existence of fairly new RFC 6106 that proposes addition od DNS IPv6 address allocation in RA message.

Virtualisation

In a world in which every day I hear virtualization at least 50 times it would be very strange that there is some part of our digital environment which is not yet virtualised. Today we can see that almost every piece of our server equipment is going to the cloud hence is being virtualised. That is not a new story, server virtualisation i basically existing for decades now. Todays story is about next step in the virtualization process. There is finally a big desire to do the same thing with networking equipment. That’s obviously the way to go as there are more and more server on one hypervisor or on one cluster in the data centers and that implies that would be too expensive to implement any kind of hardware networking devices for each virtual server instance. And that implies that we are living in a world where switches and routers are more and more becoming part of different virtualisation host kernels or hypervisors.

But now when that virtualization technology is basically a normal way of deploying almost all machines and there is nothing standing in between network devices virtualization and us why there is no way to use that technology and make for us a virtualized modeling tool for network design and troubleshooting to?

GNS3 vs VIRL

Yes, there is GNS3 for years now but to be sincere, I tried to use if for some design and troubleshooting sessions and it is so time-consuming to set everything to work right that is was at the end easier to do it on a piece of paper.