A Network Artist : January 2009

Thursday, January 29, 2009

Taking Inventory on Cisco Devices

Have you ever wanted to quickly identify your router or switch platform as well as it's installed modules and the serial numbers of each? Well there is a simple command that you can use to access all of this data on a Cisco IOS device:

Router#sh inventory raw
NAME: "Chassis", DESCR: "Cisco 7206VXR, 6-slot chassis"PID: CISCO7206VXR , VID: , SN: 4294967295
NAME: "I/O and CPU Slot 0", DESCR: "I/O and Processor Slot Container"PID: , VID: , SN:
NAME: "NPE400 0", DESCR: "Cisco 7200VXR Network Processing Engine NPE-400"PID: NPE-400 , VID: , SN: 11111111
NAME: "NPE Inlet Temperature 0", DESCR: "NPE Inlet Temperature Sensor"PID: , VID: , SN:
NAME: "NPE Outlet Temperature 0", DESCR: "NPE Outlet Temperature Sensor"PID: , VID: , SN:
NAME: "+3.45 V Voltage 0", DESCR: "+3.45 V Voltage Sensor"PID: , VID: , SN:
NAME: "+5.15 V Voltage 0", DESCR: "+5.15 V Voltage Sensor"PID: , VID: , SN:
NAME: "+12.15 V Voltage 0", DESCR: "+12.15 V Voltage Sensor"PID: , VID: , SN:
NAME: "-11.95 V Voltage 0", DESCR: "-11.95 V Voltage Sensor"PID: , VID: , SN:
NAME: "module 0", DESCR: "I/O FastEthernet (TX-ISL)"PID: C7200-IO-FE-MII/RJ45=, VID: , SN: 4294967295
NAME: "Flash Card Slot Container I/O 0", DESCR: "Flash Card Slot Container I/O"PID: , VID: , SN:
NAME: "disk0", DESCR: "Cisco 7200 I/O PCMCIA Flash Disk, 64M"PID: MEM-I/O-FLD64M , VID: , SN:
NAME: "I/O Cont Inlet Temperature 0", DESCR: "I/O Cont Inlet Temperature Sensor"PID: , VID: , SN:
NAME: "I/O Cont Outlet Temperature 0", DESCR: "I/O Cont Outlet Temperature Sensor"PID: , VID: , SN:
NAME: "FastEthernet0/0", DESCR: "DEC21140"PID: , VID: , SN:
NAME: "PA Slot 1", DESCR: "PA Slot Container"PID: , VID: , SN:
NAME: "PA Slot 2", DESCR: "PA Slot Container"PID: , VID: , SN:
NAME: "PA Slot 3", DESCR: "PA Slot Container"PID: , VID: , SN:
NAME: "PA Slot 4", DESCR: "PA Slot Container"PID: , VID: , SN:
NAME: "PA Slot 5", DESCR: "PA Slot Container"PID: , VID: , SN:
NAME: "PA Slot 6", DESCR: "PA Slot Container"PID: , VID: , SN:
NAME: "PEM 0", DESCR: "Power Supply Container"PID: , VID: , SN:
NAME: "Power Supply 1", DESCR: "Cisco 7200 AC Power Supply"PID: PWR-7200-AC , VID: , SN:
NAME: "PEM 1", DESCR: "Power Supply Container"PID: , VID: , SN:
NAME: "Power Supply 2", DESCR: "Cisco 7200 AC Power Supply"PID: PWR-7200-AC , VID: , SN:

Wednesday, January 28, 2009

Reply From Brian McGahan (Internetowk Expert) on my RIP Supernet issue

This summary is not available. Please click here to view the post.

Disabling Password Recovery For The Router

Sometimes you may come across a situation where you want to disable password recovery feature on Router to protect it against the Physical Security Violations. In such situation one should prefer to disable password recovery on router. Following in the hidden command to disable password recovery feature on router, I am saying this a hidden command because if you use IOS help to find this command than you won't find any keyword or other help.

R1(config)#no service password-recovery
Password recovery disable mode is not supported by the
current ROMMON.Please upgrade the ROMMON if you want to use this feature.

As you can see the alert message generated after running this command, you may need to upgrade ROMMON codes of your router to facilitate it with this awesome feature.

Best Regards,
Deepak Arora

BGP Filtering - Which method is going to take preference over other ?

For inbound updates the order of preference is:
1. route-map
2. filter-list
3. prefix-list, distribute-list

For outbound updates the order of preference is:
1. prefix-list, distribute-list
2. filter-list
3. route-map

Best Regards,
Deepak Arora

QOS order of operation

From Cisco's Website I got this important inputs on QOS order of operation:

Inbound
1. QoS Policy Propagation through Border Gateway Protocol (BGP) (QPPB)
2. Input common classification
3. Input ACLs
4. Input marking (class-based marking or Committed Access Rate (CAR))
5. Input policing (through a class-based policer or CAR)
6. IP Security (IPSec)
7. Cisco Express Forwarding (CEF) or Fast Switching

Outbound
1. CEF or Fast Switching
2. Output common classification
3. Output ACLs
4. Output marking
5. Output policing (through a class-based policer or CAR)
6. Queueing (Class-Based Weighted Fair Queueing (CBWFQ) and Low Latency Queueing (LLQ)), and Weighted Random Early Detection (WRED)

Best Regards,
Deepak Arora

Traffic processing in Cisco Firewall

I see many people confused about this mainly when does the SSM module’s analysis engine sees the traffic.

; FYI here is complete flow starting with Receive Packets till the Transmit Packets as per my knowledge goes...

1. Receive Packet

2. Ingress Interface (ASA)

3. Existing Conn? (if yes, skip to #6, else go to #4)

4. ACL Permit (if no, drop, else if yes go to #5)

5. Match Xlate (if no, drop, else if yes, go to #6)

6. Inspections and Protocol Checks

7. NAT IP Header

8. IPS SSM Module

9. Egress Interface (ASA)

10. L3 Route (if no route, drop, else go to #11)

11. L2 Addr (if no address, drop, else go to #12)

12. Transmit Packet

Best Regards,
Deepak Arora

Cisco ASA - NAT Order of Operations

Someone shared this NAT order of operations flow and I thought it would be good info to put out on the site in case someone needed it. Here it is

1. nat 0 access-list (nat-exempt)
2. match against existing xlates
3. static
static nat with and without access-list (first match)
static pat with and without access-list (first match)
4. nat
a) nat access-list (first match)
Note: nat 0 access-list is not part of this command.
b) nat (best match) Note: When choosing a global address from multiple pools withthe same nat
id, the following order is tried
i) if the id is 0, create an identity xlate.
ii) use the global pool for dynamic NAT
iii) use the global pool for dynamic PAT
5. Error

Best Regards,
Deepak Arora

Tuesday, January 27, 2009

Difference between a Trunk port and a Tunnel port

Trunk - physical port, dot1q or ISL protocol, encapsulates multiple VLAN's

Tunnel - logical port, can be layer 2 (L2TP) or layer 3 (GRE)

I would say trunk port can be configured to carry multiple vlan's.

Tunnel port will carry only 2 Vlan. Mainly used in service provider environment. say for example you have two switch

SW1(Trunk Port)---------(tunnel Port VLAN-ID 2)SW2

In the above example SW1 is at customer end can have any vlan configured but SW2 which is at SP end will have only one VLAN-ID 2 as access VLAN ok this VLAN-ID 2 will be dedicated for That perticular customer to segregate the traffic from that customer to SP network

Multiple VLANs from multiple customer sites can be transported through the Service Provider's network using 802.1Q tunneling. This is accomplished by adding an additional VLAN tag for each customer - when packets arrive at the edge switch, the VLAN tag assigned to that customer is removed, leaving the packets tagged as they were when they entered the Service Provider network.

Best Regards,
Deepak Arora

CCIE SP Mini-Scenarios

http://pwp.netcabo.pt/amsoares/dynamips/dynamips.htm

http://ccie18473.net/dynamips/dynamips.htm

Cisco Design Zone

Design Zone is a consolidated resource for design guides, application deployment guides, white papers, videos, and other technical reference materials. Refer to the categories organized under network architectures, technologies, and industry solutions for specific resources.

http://www.cisco.com/en/US/netsol/ns742/networking_solutions_program_category_home.html

BGP Path Selection Algorithm

Hello Friends,

While some Internetworking articles on web I came across this great blog by Mr. Richard. He is also pursuing his CCIE R&S Lab exam . He has written lots of articles on various technologies and they are extremely good. Just Check it out @ http://rbcciequest.wordpress.com/

Monday, January 26, 2009

Comparing EIGRP & OSPF

EIGRP and OSPF are both excellent routing protocols and each provides a unique set of benefits for designing and implementing a scalable network. Both protocols can be used for a wide variety of networks from small regional networks to large global network systems. A question which is frequently asked is, "Which protocol, EIGRP or OSPF, is best?" This is not an easy question, as both protocols have their benefits. This paper compares EIGRP and OSPF and provides criteria to compare the two protocols and determine which is most suitable for your network application. The following criteria have been analyzed so that key differentiating features can be considered when selecting the routing protocol which best fits your network requirements. This paper does not cover the basic operation and features of each protocol; it compares the similar features of each protocol.

Network Architecture - OSPF requires your network topology to be hierarchical, EIGRP does not. It is good design practice to design EIGRP hierarchically as well, but it is not required. Thus, EIGRP is more versatile from a topology standpoint, but still care must be taken to design the network correctly. Sometimes all the versatility of EIGRP allows improper network design, whereas, OSPF forces you to design in a backbone. OSPF also has limitations in number of routers in a OSPF area (guideline - maximum 40-50*) and number of areas per router (guideline - up to 3*). Thus, designing an OSPF network can be more challenging and limiting than designing an EIGRP network.

*Note: Guideline numbers are good general numbers. These numbers can vary widely depending on the topology and number of links in an area - they are not hard and fast rules.

Ease of Use - Because OSPF requires a hierarchical topology, desires a summarized address structure, and requires manually configured summary addresses, it can be seen as harder to implement. In addition, the different rules for the several types of areas and LSA types are conceptually more difficult to understand. However, all these features can be desirable and support a large scalable network, when done properly. EIGRP can also require some difficult advanced configuration when special features are needed. However, many people feel EIGRP is more flexible than OSPF and network designs are easier to implement using EIGRP.

Neighbors - EIGRP forms adjacencies and exchanges routing updates with each neighboring router, whereas, OSPF performs an election process for a DR (Designated Router) and BDR (Backup DR) which act as a "distribution" point for routing information. In OSPF, routers only form a full adjacency to the DR and BDR (there is one DR/BDR per network segment). This means that, all things being equal, OSPF can more efficiently support a full mesh of neighboring routers per interface. This point is especially valid on high speed LAN media. As a rule of thumb, this issue gets to be important at about 20 neighbors per interface, but depends on routing table size, router platform, utilization, media type, etc.

However, many network designs do not have a large amount of neighbors per LAN interface, they have a large amount of neighbors per router. In these cases, there are design limitations regarding the number of routers in an OSPF area and the number of areas supported per router (see Network Architecture section of this document for guidelines). It is important to note that both EIGRP and OSPF have design considerations regarding neighbors. These design considerations depend on many factors include routing table size, media type, topology, etc., but a general rule of thumb is that OSPF can have more neighbors per interface, whereas, EIGRP allows more design flexibility for many neighbors per router.

Route Filtering and Aggregation - Filtering routes in OSPF is very difficult. "Distribute-list in" does not work on OSPF routes and "Distribute-list out" works only on the routes being redistributed from other processes into OSPF. Additionally, route aggregation can only be performed at OSPF area or AS boundaries. With EIGRP, information can be filtered and aggregated at any interface and at any bit boundary, theoretically allowing multiple hierarchies based on topology. Therefore, EIGRP is much more versatile and easier to work when performing route filtering and aggregation. Additionally, EIGRP is far superior to OSPF in in-bound and out-bound filtering on a per interface basis.

Route Summarization (Configuration) - EIGRP does an automatic summarization process (by default), whereas, OSPF requires you to define each summary address. As discussed above, EIGRP can thus be easier to implement. However, in many large networks with meshed links and/or redistribution points, not paying careful attention to summarization can cause routing loops and stability problems. You need to carefully understand the topology and addressing design - incorrect auto-summarization is a frequently encountered problem by many customers.

Of course, you can get around these problems in EIGRP (by using interface summary address commands) or OSPF (by using area range commands), but it takes extra steps, good practice, and some knowledge of how the routing protocol works. OSPF requires all manual summary commands and thus requires more thought to this process. With EIGRP, careful consideration should also be given to summarization, even when using the automatic summarization features. Not performing summarization properly with either protocol can cause severe network problems.

Convergence - To recover from a network topology change, EIGRP uses DUAL (Diffusing Update Algorithm) which provides very fast convergence if a "feasible successor" exists. OSPF sends a LSA and recalculates the Diskjtra SPF algorithm. From this perspective, EIGRP can converge faster than OSPF and can require less CPU processing. However, convergence is dependent on many factors including topology, metric, type of failure, etc., so a definitive conclusion can not be made here.

When a feasible successor does not exist, EIGRP will query neighboring routers for the lost route which then query their neighbors creating an expanding tree of queries until the route is found or determined to be unavailable. In this case, the speed of convergence depends on many factors including the network topology and it is impossible to explicitly state which protocol is faster.

Memory and CPU - EIGRP sends partial updates and only sends updates when a topology change occurs. The existence of a "feasible successor" in EIGRP limits the effect of topology changes to directly affected routers and routes. OSPF multicasts LSAs to all routers in the area upon a topology change and sends periodic database updates. Memory and CPU utilization come into account when considering the routing table size, number of neighbors, and how frequently the routing protocol is actively running it's algorithm. OSPF is generally more CPU intensive on the DR router and this router should have more memory and CPU power to accommodate this function. Also, OSPF may require more CPU and memory resources on other routers in the network.Vendor Interoperability - OSPF is supported by a variety of router vendors and is an industry standard (RFC 1583); EIGRP is not. If a vendor independent routing protocol is required, EIGRP can not meet this criteria. However, care should be take when interoperating with other vendor’s OSPF routers because some vendor’s OSPF implementations can not handle large routing table sizes (as few as 200 maximum routes with 4 neighbors as been reported). It should also be noted that multiple routing protocols can be supported on a router so it is possible to implement EIGRP and still interoperate with OSPF routers by adding another routing process.

Multi-protocol Support - EIGRP can be used for IP, IPX, and AppleTalk, whereas, OSPF is just for IP. EIGRP for IPX and AppleTalk offers significant improvements over IPX RIP and AppleTalk RTMP by reducing routing information exchanged, improving network convergence, and increasing scalability. Additionally, EIGRP reduces IPX SAP traffic by performing incremental update-only based SAP updates instead of full periodic SAP updates like IPX RIP. EIGRP is therefore superior if one multi-protocol routing protocol is desired for IP, IPX, and AppleTalk support. Keep in mind that although EIGRP is conceptually similar for IP, IPX, and AppleTalk, multi-protocol EIGRP processes are "ships in the night" processes and, therefore, EIGRP is not an integrated multi-protocol routing protocol and should not be treated as such.

Route Selection - OSPF uses the interface cost (inversely proportional to bandwidth) to determine the shortest path. EIGRP builds a topology table and computes shortest paths using link bandwidth and delay as criteria. EIGRP thus offers more versatility and control in selecting the best routing path.

Routing Overhead - OSPF synchronizes router databases every 30 minutes and exchanges Link State Advertisements (LSA) whenever a topology change occurs. EIGRP builds a topology table which does not have to be periodically synchronized and does not send LSAs when the network topology changes. Instead, EIGRP sends out queries only when an acceptable "feasible successor" does not exist to an effort to find a route. Therefore, depending on the network topology, state, and configuration, EIGRP can be more efficient than OSPF by minimizing routing information exchanged.

Link Bandwidth Conservation - OSPF utilizes whatever bandwidth it requires. EIGRP will default to consume only 50% of a link bandwidth, worst case. EIGRP allows you to configure bandwidth utilization parameters, whereas, OSPF does not. Also, EIGRP changes hello timers and hold down timers on NBMA interfaces to minimize the bandwidth used and to increase network convergence reliability. EIGRP further conserves WAN bandwidth by suppressing ACKs and using unicast data packets for this function. Thus, EIGRP is better suited for WAN applications where link bandwidth is precious.

Reliable Delivery of Routing Information - EIGRP provides reliable delivery of query, update, and reply packets to ensure routing information is not lost. OSPF multicasts update information and uses acknowledgments for the packets. Both protocols provide a reliable mechanism to exchange routing information.

Security - OSPF supports password and message digest authentication key security for routing information. EIGRP also supports authentication using an encrypted key. Both protocols have a good degree of security available.

Best Regards,
Deepak Arora
CCIE#2XXXX...Oops that number is still missing

Sunday, January 25, 2009

Does RIPv2 Support CIDR/SUPERNET Networks?...Continued

Ok Friends...it's time to continue the mysterious RIPv2's CIDR/Supernet support issue. It took me a while to solve this issue but more time I spent was to understand the logic behind it.

In the first look most of the people I know thought that RIPv2 will work fine in this scenario. They said: just configure RIPv2 than disable classful summarization behavior using "no auto-summary" key-word and that is pretty much enough to make this scenario work.

But I had already tried those things and I knew it's not gonna work in that way. So I though lets go through rfc for RIP and also I went through Routing TCP/IP Vol 1 by Jeff Doyle. But more I read more I got confused. RFC clearly says that RIP flavors do not support supernet ip addressing at all, on the other hand Jeff Doyle was mentioning that Classless and CIDR support is there in RIPv2.

Hmmmm.....pretty confusing :-( isn't it......

Anyways...I spoke one of my very close friend who is also preparing for CCIE Lab exam Mr. Mrityunjay Rai....he was also not sure why RIPv2 was not working but anyhow we discussed the issue and then decided to run PPP as encapsulation on WAN interfaces of both R1 and R2. As soon as we did that the RIP started working :-)

Wow..........We made it work :-)

But the next question in my mind was how RIP started working by just configuring PPP as encapsulation on WAN interfaces of both routers...I mean come on we all know that PPP is just a Layer 2 encapsulation and how come it can change the behavior of Layer 3 routing protocol's behavior.

So one journey ended and another begin...

So again I started working on the new issue about how PPP made RIPv2 work in this scenario.

I check the routing table prior and after setting encapsulation as ppp and finally I found the clue with help of my CCIE Security friend Mr. Deptanshu Singh CCIE#20679. Again the clue was our very old friend PPP peer neighbor route feature. Here is the routing table of R1 before and after changing encapsulation to PPP:

Before:

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 192.168.4.0/23 is directly connected, Serial0/0
C 192.168.0.0/23 is directly connected, FastEthernet0/0

After:

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

192.168.4.0/32 is subnetted, 1 subnets
C 192.168.4.2 is directly connected, Serial0/0
C 192.168.4.0/23 is directly connected, Serial0/0
C 192.168.0.0/23 is directly connected, FastEthernet0/0
R 192.168.2.0/23 [120/1] via 192.168.4.2, 00:00:09, Serial0/0

So if you look closely at the routing tables you will see that before setting encapsulation as ppp the WAN subnet 192.168.4.0 was appearing in routing table with /23 prefix as 192.168.4.0/23; but as soon as we changed the encapsulation to ppp, the ppp peer neighbor route feature installed a /32 prefix for the same WAN subnet and now it appears in routing table as 192.168.4.0/32. So with /32 prefix it is not a supernet network anymore and became subnetted network and we all know that RIPv2 does support subnetting and vlsm.

So finally we found the reason why ppp made this scenario working. But......still But? :-(

Still I wanted to figure out the difference between the statement of RIP rfc and statement of respected Mr. Jeff Doyle about CIDR/Classless support.

After working on while on this new mystery I conclude that rfc and Jeff's statements are right I mean both of them are right......Huhh.....don't worry.....You need not to panic :-)

The final conclusion is RIP routers won't exchange routes on WAN links which contain supernet ip addresses by default or in other words no supernet support. On the other hand if we are receiving a supernet route on a RIP router through some other routing protocol or may be even through static routing, in that case after redistributing that supernet route learned through other routing protocol into RIP routing process, RIP will forward this supernet route information to other routers running RIP in the same domain.

To test this thing I added one more router in our existing topology and run EIGRP on R3 and R1's S0/1 interface. After that I assigned a supernet ip address 172.16.100.1 on R3's F0/0. Later I saw that router R1 was able to see this supernet network. See below the routing table of R1 :

R1(config)#do sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/30 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Serial0/1
192.168.4.0/32 is subnetted, 1 subnets
C 192.168.4.2 is directly connected, Serial0/0
D 172.0.0.0/10 [90/2195456] via 1.1.1.1, 00:00:41, Serial0/1
C 192.168.4.0/23 is directly connected, Serial0/0
C 192.168.0.0/23 is directly connected, FastEthernet0/0
R 192.168.2.0/23 [120/1] via 192.168.4.2, 00:00:03, Serial0/0

And after redistributing EIGRP 100 process into RIP Process; R2 was also able to see the 172.0.0.0/10 supernet route :-)

R1(config)#do sh run | be router rip
router rip
version 2
redistribute eigrp 100 metric 1
network 192.168.0.0
network 192.168.4.0
no auto-summary

R2(config)#do sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/30 is subnetted, 1 subnets
R 1.1.1.0 [120/1] via 192.168.4.1, 00:00:01, Serial0/0
192.168.4.0/32 is subnetted, 1 subnets
C 192.168.4.1 is directly connected, Serial0/0
R 172.0.0.0/10 [120/1] via 192.168.4.1, 00:00:01, Serial0/0
C 192.168.4.0/23 is directly connected, Serial0/0
R 192.168.0.0/23 [120/1] via 192.168.4.1, 00:00:01, Serial0/0
C 192.168.2.0/23 is directly connected, FastEthernet0/0

I hope you enjoyed this topic... If you have any opinions or suggestions on this please feel free to drop an email to me @ deepakarora.1984@gmail.com

Best Regards,
Deepak Arora
CCIE#2XXXX...Oops that number is still missing

CCIE Preparation

When I started my CCIE Lab Exam preparation journey in April 2008 last year I didn't know about from where I should start. While searching on the Internet I came to know about various workbook vendors which provides scenarios that can really help someone to prepare for CCIE Lab Exam.

The next question in my mind was which workbook will be enough to prepare for Lab Exam. So I asked my friends who either passed the lab or were preparing for it. So finally I chose my path of preparation based on inputs from them. Let me share the entire list of vendors which provides CCIE lab preparation material and than I'll share my own strategy for CCIE R&S Lab Preparation :

http://www.internetworkexpert.com

http://www.net-workbooks.com/workbooks.html

http://www.ipexpert.com

http://netmasterclass.net

http://www.ccbootcamp.com

http://www.iementor.com

http://www.voicebootcamp.com

http://www.netmetric-solutions.com

http://www.cciecert.net

http://www.deepakarora1984.blogspot.com

However my own workbook will take time but the best thing would be it will be free for everyone.

I'll share my strategy in my next post under this section :-)

Best Regards,
Deepak Arora

Undocumented OSPF, EIGRP and interface commands with samples

While working on my CCIE lab I was trying to know about the people in Industry which provides CCIE lab training and preparation material. So I came to know about a Great CCIE Heinz Ulms. He is one of the people which passed their lab exam soon after Cisco announced CCIE Lab Exam in 1994. While going through his website I found few interesting collections of Commands which he says are still not properly documented any where. So here they are :-)

http://www.heinzulm.com/ioscommands.php

http://www.madness.at/~mad/cisco_ios_udc.html

Best Regards,
Deepak Arora

Saturday, January 24, 2009

Subnetting Practice - For CCNA ... may be for CCNP too :-)

Ok Friends, let me share an another story of my CCNA days...hmmm...late 2005. While preparing for CCNA 640-801 exam....which I think was not easy at all for me, I was not comfortable with subnetting. I was reading books like CCNA by Todd Lamle and Cisco Press CCNA book by Wendell Odom. Both books were pretty good. People usually ask me specially people pursuing CCNA about which book is better for CCNA exam preparation or sometimes they ask Todd Lamle's book is better or Wendell Odom's. I would say Todd Lamle's CCNA book is pretty good to start with and thats the simplest book on CCNA I have ever read. The material is too friendly in nature but on the other side Wendell Odom is covering each topic in much more depth. So I would suggest to read both books to pass CCNA exam. Start with Todd Lamle's book and once you know all the basic stuff and you can make things working than jump on to Wendell Odom's book.

Also while preparing for CCNA exam I always tried to find some good tool for subnetting practice; finally I found a good online subnetting practice tool with help of one of my old friend. So here it is and best of luck :-)

http://www.nybi.org/subnet-2.php

Best Regards,
Deepak Arora

show parser dump command

Handy tip from Cisco TAC - if you've ever wanted to generate a command guide for your router, you can use the show parser dump command. Just type show parser dump <mode> where <mode> is the config mode of the router you'd like to see. For example:

CAT3550#show parser dump interface
Mode Name :interface

0 exit
0 help
15 description
15 switchport access vlan Number
15 switchport access vlan dynamic
15 switchport host
15 switchport mode access
15 switchport mode trunk
15 switchport mode dynamic auto
15 switchport mode dynamic desirable
15 switchport mode dot1q-tunnel
15 switchport trunk allowed vlan add
15 switchport trunk allowed vlan remove
15 switchport trunk allowed vlan except
15 switchport trunk allowed vlan all
15 switchport trunk allowed vlan none
15 switchport trunk allowed vlan
15 switchport trunk encapsulation isl
15 switchport trunk encapsulation dot1q
15 switchport trunk encapsulation negotiate
...

Generates a list of all commands from interface configuration mode. You can even see all the sub-commands and syntax description by typing show parser dump <mode> extend.

For further reference kindly refer the below URL:

http://blog.internetworkexpert.com/2009/01/22/using-the-show-parser-dump-command/#more-600

Onion Routing......Oops whats that ?

Directly from Wikipedia.....The new world of Onion Routing :-)

http://en.wikipedia.org/wiki/Onion_routing

http://www.onion-router.net/

Someday I'll develop may be Tomato Routing :-) ..... bad joke I guess

Best Regards,
Deepak Arora

Wednesday, January 21, 2009

That Pesky Frame-Relay Interface-DLCI Command!

Okey.... I must say that while preparing for CCIE lab exam sometimes I get stuck too. Once a while I got stuck with a Fame Relay issue. I was just studying Frame Relay from doc cd and got stuck with use of "frame-relay interface dlci command". You won't believe but it was documented incorrectly in few Cisco documentation references. So finally I dropped an email to InterNetwork Expert's Quad CCIE Instructor Scott Morris and soon got reply from him :-), he also posted this question and reply on his blog.

My Query:

Can you please help me understand use of Frame-Relay Interface-dlci command. It’s getting mysterious for me day by day as I am studying FR. The reason being is I earlier thought that I should only use this command on FR point to point subinterface. As Point to Point subinterface don’t allow us to put Frame relay map statements. Also in such case Inverse arp should be turned off. But while I was going through Cisco’s FR documentation on website I saw that in almost all examples they used interface dlci command on interface not on sub interface and also without turning off inverse arp. So the question now is if inverse arp is turned on then as per my understanding we need not to put this command as it will discover dlci settings through lmi signals automatically.

Kindly explain Interface Dlci command to me....

Reply From Scott Morris:
When I saw this post, I got to thinking a little bit. Mostly about the fact that the interface-dlci appears to be a much more misunderstood command than I ever gave it credit for! (poor thing…)

The quick answer is that the “frame-relay inteface-dlci” command simply says “This DLCI goes here” to the router.

On a physical interface, this command is largely irrelevant (more in a minute) because ALL DLCIs are assigned to the physical interface by default. If you are ever interested, concerned or otherwise bored, just check out “show frame-relay pvc” and you will see where they are assigned.

So in the case of sub-interfaces, there is no automagical assignment of DLCI numbers. Even if your subinterface number and DLCI number are the same. That’s just a sign of being anal-retentive (or as we consultants call it, “good at documentation”) or a little OCD. But you can technically have DLCI 100 on subinterface Serial 0/0.223. Kinda strange, but perfectly workable!

So whenever you have a subinterface, you need to do SOMETHING to tell the router “this DLCI goes here”.

So now let’s look at the next portion: Mapping. Layer3 to Layer2 mapping in particular. We can learn about L3-L2 mapping via Inverse ARP. This is on by default, but frowned upon in the CCIE Realm! “Show frame-relay map” will let you know if you have learned any addresses dynamically or not.

So if we DID allow Inverse ARP, whether our subinterfaces were point-to-point or multipoint ones, we COULD just use the “frame-relay interface-dlci” command and nothing else. (Yes, I know inverse ARP requests are not sent by default on subinterfaces, but responses still are. Watch your debugs!)

So the Interface-DLCI command assigned the PVC to a subinterface. Inverse ARP then took care of the mapping. What if we aren’t allowed to use Inverse ARP? Like for the CCIE lab? Ok, what are our options? Well, the “frame-relay map” command is the most obvious and well known. That works very well. The “frame-relay map” command both assigned L3-L2 mapping AND says “this DLCI goes here” all in one command!

Unless of course you are on a point-to-point subinterface. As you pointed out, you can’t use the map command there! But that’s ok, it’s not needed anyway! Point-to-point links have a different way of thinking. They view the world as “If it’s not my address it must be yours” and sends things out.

So that covers our two primary issues with PVC operations in Frame Relay. #1 is assigning the DLCI to an interface (no magic). #2 is the L3-L2 mapping to make IP actually work!

The last part I want to add (re: my “more in a minute” above) was that the “frame-relay inteface-dlci” command also serves another purpose which sometimes gets confusing in terms of where we just got through with things!

So where we left things with “frame-relay interface-dlci” commands:

1. Definitely used on point-to-point subinterfaces
2. Can be used on multipoint subinterfaces if Inverse ARP works
3. Not used on physical interfaces because all DLCIs belong there by default.

Now, just to mess with that logic a bit. When studying frame-relay, and particularly by the time you get into QoS configurations you will become familiar with frame-relay map-classes. Map classes can be assigned to an interface or subinterface without any problem. When this occurs, the information in the map-class gets appled to EVERY DLCI on that interface or subinterface.

So what happens if you have different QoS parameters for different PVCs that just happen to be on the same interface/subinterface? Hmmmm… Well, in comes the “frame-relay inteface-dlci” command again! See, it really IS a cool command!

The “frame-relay map” command does not have any parameter for adding a map-class. After you hit enter on your “frame-relay interface-dlci” command though, you’ll get a new sub-command prompt. Try using “?” here. You’ll see that you have the opportunity to specify a separate map-class for each and every DLCI that you have.

So if you see “frame-relay interface-dlci” commands on a physical interface. Or if you see them AND a “frame-relay map” command under a multipoint subinterface, this is the reason why. If you use the “frame-relay inteface-dlci” command AND the “frame-relay map” command for the same PVC, you will need to make sure the “frame-relay map” command comes first. Otherwise the router will express its displeasure!

So there are some very simple, but also some very powerful things the little “frame-relay interface-dlci” command does. Hopefully that will help you take some of the mystery out of things!
http://blog.internetworkexpert.com/category/ccie-routing-switching/frame-relay/
Best Regards,
Deepak Arora

Handy Switch Security Feature

While going through Cisco's Website I came to know about a handy security feature for Cisco IOS Catalyst Switches.

Scenario: - In order to reduce risk of a direct physical device exposure, administrator want to ensure that no one could reload your switches and start the initial configuration using the "Mode" button on the front panel.

Huuhh

Sounds good if we can do this...isn't it :-)

just run "no setup express" command and we are done :-) ....Bingo

and for verification "sh setup express"

Best Regards,
Deepak Arora

How To Schedule Reload For Cisco Router

Did you know that you can schedule WHEN your Cisco IOS Device reboots? Yes, it's true.

Say if the change you are making could possibly lock you out of the router (or worse, disconnect the router from the network) set it to auto reload as an emergency back-out mechanism. You can always cancel it if everything goes well. :-)

Simple to do.

Router# reload in 5

Router# reload at 22:00:00 May 27 2008

***
*** --- RELOAD SCHEDULED ---
***
* Mar 1 23:18:42: %SYS-5-SCHEDULED_RELOAD: Reload requested for 22:00:00 UTC Mon May 27 2008 by console

You can also cancel it by using:

Router# reload cancel

Best Regards,
Deepak Arora

Monday, January 19, 2009

Netstat for Cisco Routers :-)

With the introduction of Control Plane Policing features (available from 12.3(4)T), you can easily inspect all the open ports (servers and clients) on a router with the show control-plane host open-ports command, resulting in a printout very similar to the netstat -a printout on a Unix/Windows workstation.

For example, on the router where I've configured BGP, HTTP server, NTP and DHCP, this command produces the following output (a session to a BGP neighbor as well as a telnet session was established):

R1#show control-plane host open-ports
Active internet connections (servers and established)
Prot   Local Address  Foreign Address          Service    State
tcp            *:23              *:0           Telnet   LISTEN
tcp            *:80              *:0        HTTP CORE   LISTEN
tcp           *:179              *:0              BGP   LISTEN
tcp           *:179   10.0.7.2:43962              BGP ESTABLIS
tcp            *:23   10.0.7.2:18036           Telnet ESTABLIS
udp            *:67              *:0    DHCPD Receive   LISTEN
udp            *:68              *:0     BootP client   LISTEN
udp           *:123              *:0              NTP   LISTEN

This show command does not display non-TCP/UDP servers
(OSPF, EIGRP, RSVP)or even some UDP-based services (RIP).

Prior to IOS 12.4T You can use both show ip sockets
and show tcp brief.

Best Regards,
Deepak Arora

Sunday, January 18, 2009

Helpful Blogs - Related to Internetworking

http://lostintransit.se/

http://brbccie.blogspot.in/

http://www.shafagh.net/

http://bigevilsciscoworld.wordpress.com/

http://tacack.com

http://www.fragmentationneeded.net/2010/11/bgp-adjacency-spot-error.html

http://www.ccie1.com/

http://www.jeremyfilliben.com/

http://packetattack.wordpress.com/

http://www.xpresslearn.com/cisco/mpls-cisco/configure-a-basic-mpls-network

http://tcpmag.com/qanda/

http://www.ccie1.com

http://blog.alwaysthenetwork.com/

http://cciep3.blogspot.com

http://eminent-ccie.blogspot.com/

http://www.nanog.org/meetings/

http://blog.sflow.com/

http://dans-net.com/TS_mini/

http://lovemytool.blip.tv/posts?view=archive

http://ccieat21.wordpress.com/

http://blog.alwaysthenetwork.com/

http://networking.ventrefamily.com/

http://aconaway.com/

http://perlmonkey.blogspot.com/

http://routemyworld.com/

http://globalconfig.net/

http://reloadin10.wordpress.com/2010/08/28/catalyst-3750-are-they-really-that-bad/

http://sites.google.com/site/amitsciscozone/home/gre/gre-tunnel-keepalives

http://ciscodreamer.blogspot.com/

http://www.ciscocciebootcamp.com/

http://www.networkexperttraining.com/

http://darbyslogs.blogspot.com/

http://wlaniconoclast.blogspot.com/

http://dvk-net.com/

http://willroute4food.blogspot.com/

http://theciscotech.blogspot.com/

http://itdaddy.blogspot.com/

http://ccietrek.wordpress.com/

http://blog.phillips.tc/

http://ccieby30.wordpress.com/

http://rizzitech.blogspot.com/

http://www.ciscobibles.com

http://freeradius.org/

http://www.msen.com/~clif/TclTutor.html

http://noshut.blogspot.com/

http://packetsanalyzed.blogspot.com/

http://www.tcpipguide.com/free/index.htm

http://www.xpresslearn.com/cisco/mpls-cisco/configure-a-basic-mpls-network

http://www.firstdigest.com

http://ccie18473.net/dynamips/dynamips.htm

http://www.nicholasgolden.com/index.html

http://dancwilliams.com/

http://it-certification-network.blogspot.com

http://dorreke.wordpress.com/

http://routerric.blogspot.com/

http://iptechtalk.wordpress.com/

http://routemyworld.com/

http://amplebrain.blogspot.com/

http://kpjungle.wordpress.com

http://ccie-chronicles.blogspot.com/

http://www.matthillccie.com/

http://dorreke.wordpress.com/

http://ccie20728.wordpress.com/

http://ciscoexpert.wordpress.com/

http://ccielab.wordpress.com/

http://cciecisco.blogspot.com/

http://mellowd.co.uk/ccie/

http://www.networkstraining.com/

http://www.sunpenguin.net/

http://ccieforme.blogspot.com/

http://dans-net.com/

http://makezine.com/

http://fryguypa.wordpress.com/

http://prakashkalsaria.wordpress.com/

http://ccie-in-3-months.blogspot.com/

http://eminent-ccie.blogspot.com/

http://dans-net.com/

http://ciscodreamer.blogspot.com/

http://routerjockey.com/

http://cciepursuit.wordpress.com

http://dorreke.wordpress.com/

http://sesano.wordpress.com/

http://noshut.blogspot.com/

http://www.bitbucketblog.com/

http://www.netcordia.com/community/blogs/terrys_blog/

http://21500.net/

http://www.cciecandidate.com

http://eminent-ccie.blogspot.com/

http://prakashkalsaria.wordpress.com

http://debugip.blogspot.com/

http://www.netqos.com/resourceroom/articles/06_bandwidth_sharing.html

http://aconaway.com/

http://www.globalconfig.net/

http://darbyslogs.blogspot.com

http://networkingtips-tricks.blogspot.com/

http://www.sunpenguin.net/?p=889

http://www.bradreese.com/blog/ccie-6-4-2010.htm

http://cciesuccessstories.blogspot.com/2009/04/gobind-singh-gill-ccie-19910.html

http://jaredscrivener.com/

http://idontwannabeaccie.blogspot.com/

http://cisco.markom.info/

http://www.911networks.com/pmwiki.php/Cisco/BGP

http://www.ciscobible.net

http://blog.zakir.net/index.php?/archives/16-BGP-Things-to-remember.html

http://www.sunpenguin.net/?p=434

http://www.networkstraining.com/

http://www.bitbucketblog.com/

http://www.wr-mem.com/

http://www.cisco-tips.com/category/cisco-routers/

http://blog.humanmodem.com/?cat=11

http://www.gns3-labs.com/

http://www.irongeek.com/i.php?page=security/hackingillustrated

http://rbcciequest.wordpress.com/

http://www.networkworld.com/community/node/36925

http://connection.netcordia.com/blogs/terrys_blog/default.aspx

http://www.gho.no/

http://routemyworld.com/

http://ccie-chronicles.blogspot.com/search/label/IOS%20Features.

http://routerric.blogspot.com

http://cciehof.wordpress.com/

http://www.davidsudjiman.info/

http://denyip.wordpress.com/

http://cciepilot.com/2008/11/05/trivia-cdp-tunneling/

http://sesano.wordpress.com/

http://blogs.cisco.com/datacenter/

http://cciethebeginning.wordpress.com/

http://cciepursuit.wordpress.com/

http://www.davidsudjiman.info/

http://anetworkerblog.com/

http://cciejourney.wordpress.com/

http://kpjungle.wordpress.com/

http://iosadventures.wordpress.com

http://ccie-in-3-months.blogspot.com/

http://ccietobe.blogspot.com

http://ccie20728.wordpress.com/

http://roy.ccieblog.com/

http://www.debugall.co.uk

http://www.ciscobible.ne

http://brokenpipes.blogspot.com/

http://blog.zakir.net/

http://www.nil.com/ipcorner

http://ccie11440.blogspot.com/

http://ccielab.wordpress.com/

http://pushkarbhatkoti.wordpress.com/

http://www.colinmcnamara.com/

http://routemyworld.com

http://www.mail-archive.com/ccie_rs@onlinestudylist.com/

http://www.mail-archive.com/ccie_sp@onlinestudylist.com/

https://supportforums.cisco.com/community/netpro?view=overview

https://supportforums.cisco.com/index.jspa

http://cauew.blogspot.com/

http://www.blindhog.net/

http://www.netvibes.com/ccie

http://ciscotips.wordpress.com/

http://www.networkworld.com/community/odom

http://www.networkworld.com/community/?q=doyle

http://www.markholloway.com/blog/

http://ccie-en-espanol.blogspot.com/

http://www.ccie.net/groups/ccie-service-provider

http://ciscogeek.wordpress.com/

http://www.rickmur.com/

http://cciepilot.wordpress.com/

http://www.broadband-forum.org/technical/trlist.php

http://www.mplsvpn.info/

http://blog.ru.co.za/

http://blog.ipexpert.com/

http://blog.ine.com/

http://ieoc.com/default.aspx

http://blog.ioshints.info/

http://www.ciscoblog.com/

http://packetlife.net/

Saturday, January 17, 2009

Jeff Doyle's Blog

While searching IPv6 stuff on internet I came across a nice blog by Jeff Doyle :-)

http://www.networkworld.com/community/?q=doyle

There are some gr8 posts out there,just check it out

Best Regards,
Deepak Arora

Does RIPv2 Support CIDR/SUPERNET Networks?

Hi Guys,

I hope you are finding some good information on my blog :-). Recently I shared an interesting RIP scenario with you people. So after that I felt that Ok...Now I know RIP. But two days later I came across another RIP scenario and which really made me feel that in CCIE ... E doesn't always mean Expert.

Anyways: So this is the question of the day for you guys. In above mentioned sceanrio you are supposed to run RIPv2 which as far I know supports CIDR. You have to establish connectivity from R1's Ethernet ip address to R2's ethernet ip address. I have mentioned the IP Addressing for both serial interfaces and fast ethernet interfaces in Diagram. Let see if you are a Routing Champion :-)

I'll post the solution on Monday which I figured out to make it possible...Best of luck

Best Regards,
Deepak Arora

Wednesday, January 14, 2009

Biggest CCIE Announcement - 2009

Changes to CCIE Lab and Written Exam Question Format and Scoring

Effective February 1, 2009, Cisco will introduce a new type of question format to CCIE Routing and Switching lab exams. In addition to the live configuration scenarios, candidates will be asked a series of four or five open-ended questions, drawn from a pool of questions based on the material covered on the lab blueprint. No new topics are being added. The exams are not been increased in difficulty and the well-prepared candidate should have no trouble answering the questions. The length of the exam will remain eight hours. Candidates will need to achieve a passing score on both the open-ended questions and the lab portion in order to pass the lab and become certified. Other CCIE tracks will change over the next year, with exact dates announced in advance.

Effective February 17th, 2009, candidates will also see two other changes in CCIE written exams. First, candidates will now be required to answer each question before moving on to the next question; candidates will no longer be allowed to skip a question and come back to it at a later time. Second, there will be an update to the score report. The overall exam score and the exam passing score will now be reported as a scaled score, on a scale from 300-1000. This change will not affect the difficulty of the current set of exams and will assure CCIE written exams will be consistent with Cisco’s other career certification exams.

Tuesday, January 13, 2009

UDLD - Few Words

Unidirectional link failure occurs when a system can transmit or receive on a link but cannot communicate in the other direction. This problem is not discovered by the normal data link layer error detection mechanisms of the router. As a result, unidirectional link failures can lead to Layer 2 loops. While both UDLD and Loop Guard can prevent Layer 2 loops as a result of unidirectional link failures, only Loop Guard can also guard against STP failures caused by problems in software. UDLD is limited to just the detection of unidirectional link failures.

Loop Guard - Few Words

Loop Guard is a mechanism that modifies normal STP behavior in a very conservative fashion
in order to prevent any possibility of a Layer 2 loop. As the more information link details,
this feature should be enabled on root and alternate ports.

Sunday, January 11, 2009

Handy Cisco IOS COPY command trick

People always hate it when Cisco IOS asks you for things that you have already supplied in a command line, the most notable case being the copy command. For example, if you supply the complete source and destination file name in the command line, IOS still insists on asking you all the same questions (at least filling in the parameters I've supplied in the command line):

fw#copy system:running-config tftp://10.0.0.2/fw-test
Source filename [running-config]?
Address or name of remote host [10.0.0.2]?
Destination filename [fw-test]?
!!
2009 bytes copied in 0.604 secs (3326 bytes/sec)

You can disable the annoying questions with the file prompt quiet configuration command (the default value of this parameter is noisy).

fw#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
fw(config)#file prompt quiet
fw(config)#^Z
fw#copy system:running-config tftp://10.0.0.2/fw-test
!!
2009 bytes copied in 0.616 secs (3261 bytes/sec)

However, if you decide to use this configuration command, you might be surprised by its side effects - whenever you don't specify a parameter, the router tries to use its default value and you might not like what you get. Consider this sequence:

fw#copy system:running-config tftp:
Address or name of remote host []? 10.0.0.2
!!
2009 bytes copied in 0.600 secs (3348 bytes/sec)

Could you guess what the remote file name is in this case? I couldn't and had to look into the TFTP server log. Turns out the router uses router-name-confg as the default file name.

Best Regards,
Deepak Arora

Can RIP get this much complicated ? :-(

While working on my CCIE LAB preparation I always thought that I am too good with RIPv1 & RIPv2 and I can make it work easily. The main reason was that as far I know, Jeff Doyle's Routing TCP/IP Volume 1 covers pretty much everything about all RIP flavors. Later I came to know about some other references which I used and found some new things about RIP as well. So let me summarize the list of material which I used to study RIP.

1.) Jeff Doyle's Routing TCP/IP Vol 1 - This book covers at least 80% of all RIP terminologies &
scenarios.

2.) Cisco IOS Cookbook - I don't know if many people know about this book. But trust me even
if you are done with all CCIE lab preparation workbooks still you gonna
find some interesting things.

3.) Cisco's IOS 12.4 Routing Configuration Guide

4.) Internetwork Expert's Routing and Switching Workbooks Ver 4.1

So after reading lots of stuff like this I believe you will feel the same way I was feeling :-)

hhuurrraaahhh ... I can make RIP working in any situation :-) ----- Sounds pretty good..but then...

Bangggg.......... :-(

When I came across this interesting scenario.....I felt initially that this scenario is not gonna work any how.

Here is the scenario. We have two routers say R1 & R2, both routers are connected to a L2 switch ( say 2950 :-) ...its all Cisco World) through their Fast Ethernet interfaces. On R1's Fast Ethernet interface we have ip address configured as 10.0.0.1/8 and on R2's fast Ethernet interface we have configured ip address as 20.0.0.1/8. Both the switch ports of 2950 switch are configured in same VLAN. On Router R1 we have configured one loop back interface with ip address 1.0.0.1/8 and on R2's loopback interface we have configured ip address as 2.0.0.2/8. Now the requirement was to establish connectivity between R1's loopback interface & R2's loopback interface using RIPv2. Also I was not allowed to use secondary ip address on any interface. They asked me to use RIPv2 but RIPv1 can also work in this scenario. Anyways.... I took some time and after thinking about 10 minutes I tried some thing out and it worked for me.

First let me explain the problem with scenario: As both RIP routers are connected to each other through a broadcast media so definitely they can hear each others RIP updates. However the problem was... as both routers are configured with two different subnet's ip addresses on ethernet interfaces so they will hear each others RIP updates but won't accept it. I run debug ip rip command and found the clue :-)

R1#*Mar 1 00:13:56.487: RIP: ignored v2 update from bad source 20.0.0.1 on FastEth
ernet0/0

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 1.0.0.0/8 is directly connected, Loopback0
C 10.0.0.0/8 is directly connected, FastEthernet0/0

And this clue saved my life. I read a small terminology of SANITY CHECKS while reading Jeff Doyle's book a long time ago. This terminology is only applicable to RIP and IGRP, in which they validate that the update which they are receiving is belong to same ip subnet or not, and if update is from different ip subnet in that case update will be ignored and a debug message is generated which states that update has been ignored as it is received from a bad source (means different ip subnet).

So I disabled this SANITY CHECK FEATURE on both router and finally I found that now both routers are exchanging prefixes with each other which belongs to their loopback interfaces :-)

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 1.0.0.0/8 is directly connected, Loopback0
R 2.0.0.0/8 [120/1] via 20.0.0.1, 00:00:13
C 10.0.0.0/8 is directly connected, FastEthernet0/0

But when I tried to ping R2's loopback address sitting on R1 ....ahhhh...still not able to ping :-(

R1#ping 2.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

So I checked the routing table again and found the reason why ping failed. However both routers had learned loopback's addresses prefixes but still they don't have any information about the how to reach to the next hop address like from R1 to R2's fast ethernet interface ip 20.0.0.1...R1 don't have any route or information about how to reach to that network.

So Finally I fixed it by pointing a host static route (or some people call it alternate static route) which was pointing to each others fast ethernet ip address. I used it with exit interface option.

R1(config)#ip route 20.0.0.1 255.255.255.255 fastEthernet 0/0

Any Finally after that my ping worked :-)

R1#ping 2.0.0.2 rep 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 2.0.0.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 48/129/404 ms

huurraahhh

Below is the configuration for both routers...anyways happy ???? I didn't tell you the command which disabled SANITY CHECKS...here it is :-)

Under Router RIP process run this command: no validate-update-source

Best Regards,
Deepak Arora
CCIE#2XXXX....Oops that number is still missing :-)

-----------------------------------------------------------------------

R1#sh run
Building configuration...

Current configuration : 737 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
memory-size iomem 5
ip cef
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 1.0.0.1 255.0.0.0
!
interface FastEthernet0/0
ip address 10.0.0.1 255.0.0.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
router rip
version 2
no validate-update-source
network 1.0.0.0
network 10.0.0.0
no auto-summary
!
ip route 20.0.0.1 255.255.255.255 FastEthernet0/0
!
ip http server
no ip http secure-server
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
!
!
end

----------------------------------------------------------------------------

R2#sh run
Building configuration...

Current configuration : 737 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
memory-size iomem 5
ip cef
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 2.0.0.2 255.0.0.0
!
interface FastEthernet0/0
ip address 20.0.0.1 255.0.0.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
router rip
version 2
no validate-update-source
network 2.0.0.0
network 20.0.0.0
no auto-summary
!
ip route 10.0.0.1 255.255.255.255 FastEthernet0/0
!
ip http server
no ip http secure-server
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
!
!
end
-----------------------------------------------------------------------------------------