Archives for the month of: February, 2012

A clean and powerful design of a routing policy in Juniper JUNOS rewards many network engineers, tired of looking into Cisco IOS route-maps, for crossing the line and juniperizeing themselves.

Routing tables (Routing information base – RIB) are like a heart in the router. These tables are pumping routes from one network neighbour to another and building up the forwarding table (Forwarding information base – FIB) which actually conducts the flow of the data packets. The interaction with network neighbours is controlled by policy. Routes are imported from some neighbour via some routing protocol and through some policy into a corresponding routing table. From there they can be exported via another policy to another protocol and to the outside world. Feeding the forwarding table is also controlled by an export policy.

It is easy to remember (while keeping in mind that routing table is the one in the centre): import to a routing table, export from a routing table, import to, export from, import to, export from …
Read the rest of this entry »

I was looking into the NTP reachability numbers for many many times simply knowing that 377 means “everything is fine”, but never asked myself what do these figures mean. Until now.

The important task of keeping the accurate time on networking equipment and hosts if almost always handled by NTP (Network Time Protocol).

Most networking devices have some kind of a “show ntp associations” command which displays the status of NTP peers. Good reachability is shown with the magic number of 377. If something goes wrong in the communication with a certain NTP peer and a packet was lost during the update, the reachability number for that peer drops to 376 and might go through a serious of strange values, like 375, 373, 367 etc. What do these numbers mean? Let me answer the question from a more interesting perspective – how can we get the reachability 66?

The reachability number is a 8-bit register which keeps track of the last 8 NTP update events or transactions in a first-in-first-out manner. These numbers are not a connection metric but rather a history log, where a bit equal to 1 indicates a succesful transaction and 0 indicates a failure. On every transaction the entire register is shifted one bit left and the newest bit enters from the right as the least significant one.

The route toward reachability of 66 goes like this:

Here we go: good start with two succesful transactions (reach = 1 and 3), then one packet was lost (reach = 6). After that two more succesful transactions (reach = 15 and 33) and another lost packet (reach = 66).

If no problems occur after that, the reachability moves toward its final destination of 377:

I won’t encourage you to try this on your routers, though. Our time is too valuable to monitor the machines and wait for them to synchronizing their watches.

Just don’t miss the beat 😉