Saturday, November 14, 2015

Drawing OSPF Road Map Manually

Ever wondered how an OSPF Link State Graph or Shortest Path Tree (SPT) will look like? Well this is just modeling the Road Map which can be drawn using the Link State Database of an OSPF process. This is how the router uses self-originated and received LSAs to calculate the best path via a graph.
Download the configuration files from here.


Let's think as the router. He only understand what other routers say via LSAs. I am taking a random router named as R3 (router-id: 3.3.3.3) in a lab network.

Starting form viewing the LSDB which has all the LSAs he can see that there are 6 routers in the OSPF process numbered as 1 in the area 0 which he is also in.

(click on the images for full view)

The the SPT is drawn using the Router LSAs.



1st he sees what His own Router LSA says to others.

It says that there are 2 transit networks connected to him. Transit networks are network segments.

Their DRs are 10.0.35.5 and 10.0.34.4 and the Cost is 10 for the routers in those segments.












So the road map from him will start like this.




 Now it's the time to query Network LSAs to find out what those DRs are adjacent or connected with.













Network LSAs say that those DRs are connected to 5.5.5.5 & 4.4.4.4 nodes as well.



So he can continue drawing his map.








It's time to query the Router LSAs received from 4.4.4.4 & 5.5.5.5 to figure out their neighbors, attached links and costs.































Now he can continue drawing his map using these information like before.









Now he queries Network LSAs of new 3 DRs to find out other routers in those segments.




















Now the map will be like below.





Now he queries other Router LSAs of 1.1.1.1 & 2.2.2.2 & 6.6.6.6 to find out their networks.















Here this router has a stub network with ip address of 1.1.1.1/32

Its a loopback.

















The new DR (10.0.12.2) found from these Router LSAs is connected to 1.1.1.1 & 2.2.2.2 only. Following is its Network LSA.














Now the final diagram will be updated like this.























This is the road map which is used to reach & calculate the costs to all routes in the network. Every router in the same area has a copy of this. But the actual costs in the routing table will be like below.


















It will be confusing if we look at the map and try to compare the costs of the routing table to the routes. Actually there is no problem in the map. Its is confusing because of the DRs in the map. They are used to calculate the costs to the network segments only. Because the Network LSAs say which routers are advertising it we can draw a simplified map by removing the DRs now. Then it will be ok.






















By the way, the actual physical topology was like this.


Friday, November 13, 2015

Wiretapping IP Phones

It is possible to wiretap IP phones using Wireshark. If you have access to the network switch which the target phone is connected, you can capture packets of that interface and rebuild the conversation using Wireshark software easily.

Here, my target phone is connected to the Fa0/13 of a Cisco switch. And my PC is connected to the Fa0/9.

I need to start a monitoring session to mirror the port Fa0/13 as source and the destination port as Fa0/9 using following commands.

S(config)#monitor session 1 source interface Fa0/13
S(config#)monitor session 1 destination interface Fa0/9




Start a Wireshark capture from the PC & wait for a call. You can see RTP in protocol field when a call is taking place.  (click on the images to see in full size)

















When the capturing is over save the capture and go to Telephony --> VoIP Calls















Click on a completed call and click on Player






Click Decode

















You will see 2 streams for Rx side and Tx side. Tick a stream and hit Play

Note: Currently supported protocols for VoIP in Wireshark are SIP, H323, ISUP, MGCP & UNISTM. Supported codes are G711 A-Law & G711 u-Law only.

Thursday, November 12, 2015

Masking MTU Miss Match In OSPF

MTU is a common OSPF adjacency attribute. Which means that the MTU from both sides (interfaces connected) must be same. Anyhow if it is different from one side a unique problem of forming adjacency occurs.

So the neighbors will flap between in Exstart / Down states. (click on the images to view in full screen)













If the output and errors are like this, most probably the issue is with MTUs. Enter debug ip ospf adj on both routers to gather more information about the issue since this is a adjacency problem.











By reading the output we can easily say that the router with ID 1.1.1.1 (R1) has a lower MTU of 1000 Bytes & the 2.2.2.2 (R2) has the default MTU of 1500 Bytes.

MTU can be manually changed by entering ip mtu <size> command in interface level. But because MTU is a function of physical link you may not be able to change it for most cases. Even if so, you can mask the problem by entering the command ip ospf mtu-ignore in interface level on the lower MTU side so that the adjacencies will happen and the routers will work fine. But it is not a recommended solution because when the router with the larger MTU goes for a flooding event, the router with the lower MTU will not be able to handle it.

So even though you can technically issue the above command to solve the issue it will be never a valid design because it will probably call for more troubles in the future.




                                               

Wednesday, November 11, 2015

OSPF Flood War Caused by Duplicate Router-IDs

                                                (click on the images to view in full size)

If you see this error on a router it means you have 2 or more routers in the same area which has same OSPF router-id configured. Situation is called OSPF flood war.
Router-ID is a unique adjacency attribute which the SPF algorithm use as nodes to solve shortest paths to routes, in the link state graph.

Flood war occours when someone is advertising a route into the network & someone is withdrawing it.

Here a duplicate router advertises networks by LSAs which the other router thinks "old information" which needs to get aged out of it's database.

So the 2nd router reflood the LSA with the maximum age telling everyone to delete it.

side note: This mechanism is there in OSPF because if a router restarts and a connected link of that router is down during the reboot process, and if it received it's old router LSA which advertises it's old link which should not be circulating anymore. So the router floods the LSA with the maximum age telling others to ignore it.

So to troubleshoot this you must log into all routers in same area to see which router shows the same output & change one to a different ID.