Layer 2 Traceroute - Another Cisco Baby To Help Operations Guys

Well it's been a while or probably years ago I wanted to talk and write about this interesting Cisco baby called " Layer 2 Traceroute ". I called it Cisco Baby because it requires Cisco Discovery Protocol (CDP) to be enabled in order to function.

Now Idea is simple, In traditional L2 Campus or Enterprise Network our Network Operations Team keep getting several requests such us tracing user port and change it's vlan to something else or maybe a troubleshooting call where we need to identify source port of user or server etc. The traditional approach usually was to first hop on to switch hosting SVI for given VLAN , Figure out Layer 2 address for given IP (User/Server IP) and do reverse engineering by tracing that Layer 2 Mac Address hop by hop until we hit the user port configured in access vlan or Server that might be using trunking in a virtualized network.

Here is a quick example of traditional approach:

Now Here is how this wonderful IOS tool helps you trace quickly

Further Readings:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/l2trace.html

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3550/software/release/12-1_13_ea1/command/reference/3550cr/cli3.pdf

http://packetpushers.net/tracing-a-layer-2-path-on-cisco-nexus-switches/


HTH...
Deepak Arora
Evil CCIE

How To Bring Old "wr" Command Into Cisco Nexus To Save Configs - Quick Tip

Well I always use "wr" command short for "write" onto Cisco devices to save configurations. I am just too much use to with this syntax that I even don't remember when I used other command " copy run start" last time. :)

On the flip side Cisco Nexus Series platforms don't have "wr" command.

Well the way you can solve this problem is by creating an ALIAS for "copy run start" command and it should be helpful for Operations/Support Teams as well.

In Global configuration mode run the following command:

"cli alias name wr copy running-config startup-config" 

HTH....
Deepak Arora
Evil CCIE

VRF Routing Context - Lets Make Virtualization Life Easier

VRF aware pings and test are frustrating many times specially during troubleshooting where you try to ping or trace a destination or check routing table and later you notice you forgot to run vrf aware command. To solve this problem Cisco has introduced a cool feature known as VRF Routing Context into IOS and NX-OS which makes life lot easier specially during troubleshooting. Here is a quick example and topology details:

 

 

 

HTH....

Deepak Arora

Evil CCIE

 

How To Change Regular BGP Config Format To Address Family Format

While the World of BGP is keep on changing like any other routing protocol in terms of development, one of the thing that's commonly becoming standard these days or perhaps there is lot of push towards that direction in recent times is adopting the Address Family Structure to keep things neat and clear in terms of configuration review.

Also when it comes to BGP, the configuration lines grow very quickly in Large Enterprise & Data Center environments. And BGP is taking a major place into DMVPN and Large Scale Data Center Environment where Cisco is pushing it under Best Practices in terms of Routing protocol choice.

So one of feature BGP supports to help us with Address Family Structure or it's adoption without creating much pain in butt is - BGP Upgrade CLI.

Here is a quick Example:

HTH...

Deepak Arora

Evil CCIE

IP Accounting - A Deeper Look From QOS Prospective

Got a call from one of a Friend (Network Engineer) yesterday looking for a quick way to verify QOS marking for a specific traffic.

Now there are multiple ways to get this done. One of the easiest way is to use an ACL matching specific IP Precedence values and apply it on interface in incoming direction and see if you are getting hits. Though it's a quick way but there are some limitations as well. For example - Say I am expecting incoming traffic to carry IP Precedence 5 value. And if you are matching IP Precedence 5 in ACL, you should see hits on ACL. On the flip side if for some reason traffic lost it's marking some where in middle. You won't see hits. Which is what usually we need to know while troubleshooting. But on the flip side you still couldn't determine what was actual IP Precedence value that traffic was carrying at that point which didn't create hit on the ACL. 

Now you might be thinking, that's easy. We can create one ACL per IP Precedence value (Total 8) and we should be all good. Which is Okay. But lengthy way. Specially if you are little lazy at Typing like me :)

There is an alternate way as well. All most of us have used "IP Accouting" feature at some point of our Networking Career. But this feature has couple of more branches which are not explored that much per say. One of function it provides is something that can help us with above mentioned situation and even easier and faster in terms of configuration and verification.

Let's review our topology:

Say on R3, I am expecting Server to send traffic towards R3's Loopback with IP Precedence Value 5. But on the flip side I am really not 100% sure if that is really happening.

Now we can create 8 ACLs matching IP Precedence Values 0-7 and apply that ACL on F0/0 of R3 in incoming direction. And than later look at "sh access-list " command output to see which one out of eight ACL entries actually got hit to figure out which IP Precedence value traffic was actually carrying.

Nahhh..... Let's look at other way

Lets enable the feature on R3's F0/0 interface for incoming packets. Though this feature is supported in outbound direction as well.


R3#sh run int f0/0
Building configuration...

Current configuration : 125 bytes
!
interface FastEthernet0/0
 ip address 23.0.0.3 255.255.255.0
 ip accounting precedence input
 duplex auto
 speed auto
end

Lets send couple of pings to see our traffic is carrying which IP Precedence value:


SERVER#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 352/428/524 ms
 
 Lets verify back on R3

R3#sh int f0/0 precedence
FastEthernet0/0
  Input
    Precedence 0:  5 packets, 570 bytes

As you can see we received the traffic on R3 marked with IP Precedence 0, Which means default value.

Hmmm... Seems like our QOS policy is not working.

Lets set up one and see if that changes the situation as per our requirement.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#class-map match-all ICMP
R2(config-cmap)#match protocol icmp
R2(config-cmap)#exit
R2(config)#
R2(config)#policy-map PREC5
R2(config-pmap)#class ICMP
R2(config-pmap-c)#set ip precedence 5
R2(config-pmap-c)#exit
R2(config-pmap)#
R2(config-pmap)#int f0/1
R2(config-if)#service-policy output PREC5
R2(config-if)#end

Now as configuration seems to be in place to get our job done. Let's re-send the Pings from Server and see if they are carrying IP Precedence 5 now.


SERVER#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 232/488/688 ms

Let's re-verify on R3

R3#sh int f0/0 precedence
FastEthernet0/0
  Input
    Precedence 0:  10 packets, 1140 bytes
    Precedence 5:  5 packets, 570 bytes

Hmmm....The policy seems to be working now. But old matches are still there and seems to be increased. Which looks confusing.

Okay, lets clear the mess and re-run the test and verify one last time.

R3#clear counters f0/0
Clear "show interface" counters on this interface [confirm]

R3#sh int f0/0 precedence
FastEthernet0/0
  Input
    (none)


Now counters are cleared. Let's Re-Test

SERVER#ping 3.3.3.3 r 10

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

Final Verification:

R3#sh int f0/0 precedence
FastEthernet0/0
  Input
    Precedence 5:  10 packets, 1140 bytes

 Nice... Isn't It ? :)

Further Readings

http://www.ciscopress.com/articles/article.asp?p=764234&seqNum=4

HTH...
Deepak Arora
Evil CCIE

HSRP Preemption On Standby Router - Required Or Not ?

Often I ask this question to CCNPs during interviews - "Do we require PREEMPT command on HSRP Standby router or not ? "

And often candidates either reply "NO" or looks Struggling.

Although Short answer is "YES". But here is the detailed explanation using a test bed.

For those which are new to HSRP. I would recommend first read following posts from Gr8 CCNP Intructor Chris Bryant, CCIE#12933


http://www.thebryantadvantage.com/CCNPCertificationBCMSNExamHSRPInterfaceTracking.htm

http://www.thebryantadvantage.com/CCNPCertificationExamBCMSNHSRPPriorityActive.htm

http://www.thebryantadvantage.com/CCNPCertificationBCMSNExamHSRPMACAddress.htm


Now lets get started with topology details later followed by Detailed Explanation using Test Bed:

 

 

 

 

 

 

 

Further Readings:

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_q_and_a_item09186a00800a9679.shtml

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094a91.shtml

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml 

 

HTH...

Deepak Arora

EVIL CCIE

Network Design Challenge

PHYSICAL TOPOLOGY

       LOGICAL TOPOLOGY

Recently one of the customer I am working for came up with an interesting requirement.

Current customer setup look alike something similar to topology (logical) given above. Customer has two locations per say connected through back to back T1 Circuits. In current setup R1-R3 is the primary path, and if a failure occurs in that case traffic should fall back to backup path using R2-R4. Customer is using One HSRP group on each side for auto failover purpose and currently static routing is in place.
 
So considering all this, following is how over all traffic flow looks like at the moment from A to C and from B to C perspective:
 

Hmmm... sounds like a pretty flat and easy network... isn't it ? :-)


Now here is the new requirement: As you guys can see we are wasting our bandwidth here on the backup circuit between R2-R4. And Bandwidth in our real life means $$$$$$ :-)

So here is new desired flow: When Host A talks to Host C, It should use Path through R1-R3. At the same time if Host B talks to Host C, It should use Path through R2-R4. At the same time both links should be redundant for each other for all traffic flow. So based on this requirement , the traffic flow needs to look like following:

As you can see , we need to account 8 potential FAILURE DOMAINS to ensure our fail-over scenarios works just fine. 

Also requirement is to ensure we don't have any asymmetric routing into the network. And of course NO dynamic routing protocol should be introduced.

So how you gonna do this ? :-) , since from very high level perspective it looks very easy. But it ain't :-)

            
Current Configuration
++++++++++++++                                                                                                                        
SW-A
=====
!
en
!
conf t
!
ho SW-A
!
no ip do lo
!
no cdp run
!
ip routing
!
int f1/1
 sw mo acc
 sw acc vl 10
 exit
!
int vlan 10
 ip add 10.0.0.1 255.255.255.0
 no sh
 exit
!
ip route 20.0.0.0 255.255.255.0 12.0.0.1
ip route 30.0.0.0 255.255.255.0 12.0.0.1
!
int f1/0
 no switchport
 ip add 12.0.0.2 255.255.255.0
 no sh
 exit
!
end

!


SW-B
=====
!
en
!
conf t
!
ho SW-B
!
no ip do lo
!
no cdp run
!
ip routing
!
int f1/0
 no switchport
 ip add 34.0.0.2 255.255.255.0
 no sh
 exit
!
int f1/1
 sw mode access
 sw acc vl 20
 exit
!
int f1/2
 sw mode access
 sw acc vl 30
 exit
!
int vlan 20
 ip add 20.0.0.1 255.255.255.0
 no sh
 exit
!
int vlan 30
 ip add 30.0.0.1 255.255.255.0
 no sh
 exit
!
ip route 0.0.0.0 0.0.0.0 34.0.0.1
!
end
!

R1
====
!
en
!
conf t
!
ho R1
!
no ip do lo
!
int f0/0
 ip add 12.0.0.111 255.255.255.0
 standby 1 ip 12.0.0.1
 standby 1 pri 105
 standby 1 pree
 standby 1 track s1/0
 exit
!
int s1/0
 ip add 13.0.0.1 255.255.255.0
 encap ppp
 no sh
 exit
!
ip route 20.0.0.0 255.255.255.0 13.0.0.3
ip route 30.0.0.0 255.255.255.0 13.0.0.3
ip route 0.0.0.0 0.0.0.0 13.0.0.3
!
ip route 10.0.0.0 255.255.255.0 12.0.0.2
!
end
!


R2
===
!
en
!
conf t
!
ho R2
!
no ip do lo
!
no cdp run
!
int f0/0
 ip add 12.0.0.112 255.255.255.0
 standby 1 ip 12.0.0.1
 standby 1 pree
 no sh
 exit
!
int s1/0
 ip add 24.0.0.2 255.255.255.0
 encap ppp
 no sh
 exit
!
ip route 20.0.0.0 255.255.255.0 24.0.0.4
ip route 30.0.0.0 255.255.255.0 24.0.0.4
ip route 0.0.0.0 0.0.0.0 24.0.0.4
!
ip route 10.0.0.0 255.255.255.0 12.0.0.2
!
end
!

R3
===
!
en
!
conf t
!
ho R3
!
no ip do lo
!
no cdp run
!
int f0/0
 ip add 34.0.0.3 255.255.255.0
 standby 1 ip 34.0.0.1
 standby 1 pri 105
 standby 1 pree
 standby 1 track s1/0
 no sh
 exit
!
int s1/0
 ip add 13.0.0.3 255.255.255.0
 encap ppp
 no sh
 exit
!
ip route 10.0.0.0 255.255.255.0 13.0.0.1
ip route 0.0.0.0 0.0.0.0 13.0.0.1
!
ip route 20.0.0.0 255.255.255.0 34.0.0.2
ip route 30.0.0.0 255.255.255.0 34.0.0.2
!
end
!
 

R4
===
!
en
!
conf t
!
ho R4
!
no ip do lo
!
no cdp run
!
int f0/0
 ip add 34.0.0.4 255.255.255.0
 standby 1 ip 34.0.0.1
 standby 1 pree
 no sh
 exit
!
int s1/0
 encap ppp
 ip add 24.0.0.4 255.255.255.0
 no sh
 exit
!
ip route 10.0.0.0 255.255.255.0 24.0.0.2
ip route 0.0.0.0 0.0.0.0 24.0.0.2
!
ip route 20.0.0.0 255.255.255.0 34.0.0.2
ip route 30.0.0.0 255.255.255.0 34.0.0.2
!
end
!

So let's see who among you is a Real Network Warrior  :-)

Final Config

R1
====

!
en
!
conf t
!
ho R1
!
no ip do lo
!
ip sla 2
 icmp-echo 34.0.0.3 source-interface f0/0
 freq 5
 timeout 5000
 exit
!
ip sla schedule 2 life forever start-time now
!
track 2 rtr 2 reachability
!
int f0/0
 ip add 12.0.0.111 255.255.255.0
 standby 1 ip 12.0.0.1
 standby 1 pri 105
 standby 1 pree
 standby 1 track s1/0
 standby 1 track 2
 standby 2 ip 12.0.0.11
 standby 2 pree
 no sh
 exit
!
int s1/0
 ip add 13.0.0.1 255.255.255.0
 encap ppp
 no sh
 exit
!
ip route 20.0.0.0 255.255.255.0 13.0.0.3
ip route 0.0.0.0 0.0.0.0 13.0.0.3
!
ip route 10.0.0.0 255.255.255.0 12.0.0.2
!
end
!





R2
===

!
en
!
conf t
!
ho R2
!
no ip do lo
!
no cdp run
!
ip sla 1
 icmp-echo 34.0.0.4 source-interface s1/0
 time 500
 freq 3
 exit
!
ip sla schedule 1 life forever start-time now
!
track 2 rtr 1 reachability
!
int f0/0
 ip add 12.0.0.112 255.255.255.0
 standby 1 ip 12.0.0.1
 standby 1 pree
 standby 2 ip 12.0.0.11
 standby 2 pri 105
 standby 2 pree
 standby 2 track 2
 no sh
 exit
!
int s1/0
 ip add 24.0.0.2 255.255.255.0
 encap ppp
 no sh
 exit
!
ip route 30.0.0.0 255.255.255.0 24.0.0.4
ip route 0.0.0.0 0.0.0.0 24.0.0.4
!
ip route 10.0.0.0 255.255.255.0 12.0.0.2
!
end
!


SW-A
=====

!
en
!
conf t
!
ho SW-A
!
no ip do lo
!
no cdp run
!
ip routing
!
int f1/1
 sw mo acc
 sw acc vl 10
 exit
!
int vlan 10
 ip add 10.0.0.1 255.255.255.0
 no sh
 exit
!
ip route 20.0.0.0 255.255.255.0 12.0.0.1
ip route 30.0.0.0 255.255.255.0 12.0.0.11
!
int f1/0
 no switchport
 ip add 12.0.0.2 255.255.255.0
 no sh
 exit
!
end
!



R3
===


!
en
!
conf t
!
ho R3
!
no ip do lo
!
no cdp run
!
int f0/0
 ip add 34.0.0.3 255.255.255.0
 standby 1 ip 34.0.0.1
 standby 1 pri 105
 standby 1 pree
 standby 1 track s1/0
 no sh
 exit
!
int s1/0
 ip add 13.0.0.3 255.255.255.0
 encap ppp
 no sh
 exit
!
ip route 10.0.0.0 255.255.255.0 13.0.0.1
ip route 0.0.0.0 0.0.0.0 13.0.0.1
!
ip route 20.0.0.0 255.255.255.0 34.0.0.2
ip route 30.0.0.0 255.255.255.0 34.0.0.2
!
ip route 24.0.0.0 255.255.255.0 34.0.0.4
!
access-l 100 permit ip 30.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
!
ip sla 1
 icmp-echo 24.0.0.4 source-ip 34.0.0.3
 timeout 5000
 frequency 3
!
ip sla schedule 1 life forever start-time now
!
ip sla 3
 icmp-echo 12.0.0.112 source-interface FastEthernet0/0
 frequency 5
!
ip sla schedule 3 life forever start-time now
!
track 1 rtr 1 reachability
!
track 3 rtr 3 reachability
!
track 2 list boolean and
 object 1
 object 3
!
route-map PBR per 10
 match ip address 100
 set ip next-hop verify-availability 34.0.0.4 1 track 2
route-map PBR per 20
 exit
!
int f0/0
 ip policy route-map PBR
 no ip route-cache cef
 exit
!
ip sla 5
 icmp-echo 12.0.0.111 source-interface Serial1/0
 frequency 5
 timeoute 5000
!
ip sla schedule 5 life forever start-time now
!
track 5 rtr 5 reachability
!
int f0/0
 standby 1 track 5
 exit
!
end
!



R4
===

!
en
!
conf t
!
ho R4
!
no ip do lo
!
no cdp run
!
int f0/0
 ip add 34.0.0.4 255.255.255.0
 standby 1 ip 34.0.0.1
 standby 1 pree
 no sh
 exit
!
int s1/0
 encap ppp
 ip add 24.0.0.4 255.255.255.0
 no sh
 exit
!
ip route 10.0.0.0 255.255.255.0 24.0.0.2
ip route 0.0.0.0 0.0.0.0 24.0.0.2
!
ip route 20.0.0.0 255.255.255.0 34.0.0.2
ip route 30.0.0.0 255.255.255.0 34.0.0.2
!
end
!





SW-B
=====


!
en
!
conf t
!
ho SW-B
!
no ip do lo
!
no cdp run
!
ip routing
!
int f1/0
 no switchport
 ip add 34.0.0.2 255.255.255.0
 no sh
 exit
!
int f1/1
 sw mode access
 sw acc vl 20
 exit
!
int f1/2
 sw mode access
 sw acc vl 30
 exit
!
int vlan 20
 ip add 20.0.0.1 255.255.255.0
 no sh
 exit
!
int vlan 30
 ip add 30.0.0.1 255.255.255.0
 no sh
 exit
!
ip route 0.0.0.0 0.0.0.0 34.0.0.1
!
end
!

HTH...
DEEPAK ARORA
Evil CCIE

IP Netmask Format - Good To Know For Troubleshooting

Last weekend around 2 AM I got a call from a Help Desk guy stating that one of Unix Server is not reachable from certain parts of my client network. And my first reaction was :

but it's all part of job and entertainment. So few minutes later I logged into the network using my VPN access to see what's going on. So as I logged in into the network, I found ..... "Nothing". I mean everything was looking ok and there wasn't any log into the ACS (Used For AAA based Access) suggesting someone made changes into the network on Friday. Also no log into local log of concerned devices stating any reason.


So after this initial investigation I was pretty sure now that there wasn't any change made in the network since Friday. Which leads to conclusion that it's either problem with the Unix server itself or there is some configuration issues with the server.


Next I dropped any email back to unix guy stating I didn't find anything unusual, please confirm if:


> Any changes were made into the configuration of Unix Server recently ?
> Restart the network Services of the Unix Server
> Send me "ifconfig -a" command output from Unix Server command prompt.


BTW... "ifconfig -a" is equivalent to "sh protocols" in Cisco IOS world and "ipconfig /all" from Windows OS world.


and just a minute later the Unix guy replied me back stating:


> There were no changes made into the configuration since last few days
> Restarting network services didn't help
> ifconfig -a results attached



# ifconfig -a
lo0: flags=2001000849LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
bge0: flags=1000843BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 10.136.110.149 netmask ff000000 broadcast 10.255.255.255
        ether 0:3:ba:f8:2e:39
bge1: flags=1000843BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
        inet 172.17.1.132 netmask ffff0000 broadcast 172.17.255.255
        ether 0:3:ba:f8:2e:3a


So as you guys can see, the E0 Ethernet interface is Running fine and even IP was looking good from my prospective since I already had checked the VLAN subnet for it. But did you see the mask highlighted with YELLOW color ? Isn't that looking weird ? I mean did you ever know that there are some devices out there which takes netmask/subnet mask into Hexadecimal format ?

At-least I didn't....


So next step was to determine the subnet mask into Decimal format to see if it matches my network device configuration. So I quickly took the windows calculator and tried to conver ff000000 into binary. Though It took a min or two to figure out how many digits from Hex needs to be picked up for each decimal block. And the answer was "Two"

so finally I had answer that subnet mask was put by unix administrator was "255.0.0.0" where my vlan subnet configuration was configured for different subnet mask. So I quickly replied unix administrator suggesting to change the subnet mask to the correct one and of course that fixed the issue.


After that next morning I did some research on Subnet mask in Hex format and found that some old Unix box use to support it in that format only.


But one interesting thing I found was that our very own Cisco IOS also supports that format. And I was like :

Yes. So I quickly did some test and here are results:

R1#sh ver | i IOS

Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T5, RELEASE SOFTWARE (fc4)

R1#sh ip int brief | e una|do

Interface                  IP-Address      OK? Method Status                Protocol

FastEthernet0/0            20.20.20.20     YES manual up                    up

FastEthernet0/1            30.30.30.30     YES manual up                    up

Loopback0                   10.10.10.10      YES manual up                    up

R1#sh protocols

Global values:

  Internet Protocol routing is enabled

FastEthernet0/0 is up, line protocol is up

  Internet address is 20.20.20.20/8

FastEthernet0/1 is up, line protocol is up

  Internet address is 30.30.30.30/16

Loopback0 is up, line protocol is up

  Internet address is 10.10.10.10/30

R1#terminal ip netmask-format ?

  bit-count    Display netmask as number of significant bits

  decimal      Display netmask in dotted decimal

  hexadecimal  Display netmask in hexadecimal

R1#terminal ip netmask-format hexadecimal

R1#sh protocols

Global values:

  Internet Protocol routing is enabled

FastEthernet0/0 is up, line protocol is up

  Internet address is 20.20.20.20 0xFF000000

FastEthernet0/1 is up, line protocol is up

  Internet address is 30.30.30.30 0xFFFF0000

Loopback0 is up, line protocol is up

  Internet address is 10.10.10.10 0xFFFFFFFC

R1#sh run int f0/0

Building configuration...

Current configuration : 92 bytes

!

interface FastEthernet0/0

 ip address 20.20.20.20 255.0.0.0

 duplex auto

 speed auto

end

R1#terminal ip netmask-format decimal

R1#sh protocols

Global values:

  Internet Protocol routing is enabled

FastEthernet0/0 is up, line protocol is up

  Internet address is 20.20.20.20 255.0.0.0

FastEthernet0/1 is up, line protocol is up

  Internet address is 30.30.30.30 255.255.0.0

Loopback0 is up, line protocol is up

  Internet address is 10.10.10.10 255.255.255.252

R1#sh run int f0/0

Building configuration...

Current configuration : 92 bytes

!

interface FastEthernet0/0

 ip address 20.20.20.20 255.0.0.0

 duplex auto

 speed auto

end

R1#terminal ip netmask-format bit-count

R1#sh protocols

Global values:

  Internet Protocol routing is enabled

FastEthernet0/0 is up, line protocol is up

  Internet address is 20.20.20.20/8

FastEthernet0/1 is up, line protocol is up

  Internet address is 30.30.30.30/16

Loopback0 is up, line protocol is up

  Internet address is 10.10.10.10/30

R1#sh run int f0/0

Building configuration...

Current configuration : 92 bytes

!

interface FastEthernet0/0

 ip address 20.20.20.20 255.0.0.0

 duplex auto

 speed auto

end

Few other interesting facts I found were :

> If you ever change the netmask format from global mode, it never shows up into the running config

R1#terminal ip netmask-format hexadecimal


R1#sh run | i terminal
R1#

> You can change the format for particular line (VTY Vs Aux Vs Con) And this time it will reflect into the running configuration.

R1(config)#line con 0

R1(config-line)#ip netmask-format ?

  bit-count    Display netmask as number of significant bits

  decimal      Display netmask in dotted decimal

  hexadecimal  Display netmask in hexadecimal

R1(config-line)#ip netmask-format hexadecimal
R1(config-line)#end


R1#sh run | b netmask
 ip netmask-format hexadecimal
line aux 0
line vty 0 4
!

HTH...
Deepak Arora
Evil CCIE

Some More Troubleshooting Fun With EIGRP

Recently I got this request from a friend working on CCNP. He was looking for some troubleshooting labs. So I thought to help him out with couple of labs and to other people who are preparing for CCNP TS exam.


So to add some fun I created this small troubleshooting lab last night. Below is the topology :

R1 should be able to reach R4's loopback and vice versa. For verification point of view the command -  R4#ping 1.1.1.1 so lo0 should have 100% success rate. Also R4 should be able to telnet R1 and get login prompt.


Here are the initial configuration files and GNS topology for you guys :


http://hotfile.com/dl/124210052/99638e1/EIGRP_ISSUE.rar.html


Also recently I saw a nice post from CCIE Anthony at blog.ipexpert.com which might help you along the way:


http://blog.ipexpert.com/2011/07/10/troubleshooting-eigrp-adjacencies


Again... Being a good network engineer, Avoid using "sh run" and instead try to find and fix the problem using other "show" commands.


HTH...
Deepak Arora

Static Routing Myth - Exit Interface Vs Next Hop

Myth : It's been long time since I wanted to talk about this Myth which every CCNA deals with once in a while. It's a very common misconception that If we point two static routes for same destination with one being having next hop address vs other with exit interface; in such case load balancing will not occur. The reason given being is that the static route with exit interface option will show up in local routing table as "connected" and as we all know that connected has AD value of  "0" Vs static route pointing towards next hop with AD value of "1". So by that rule the route with exit interface wins over route with next hop and because of that load balancing won't occur.


Let's hop on to command line to verify whats going on. I am going to use two routers connected back to back using two WAN interfaces. We will create 1 loopback on each router as "x.x.x.x/24" where X =  Router Number.


After this we will point out one static route toward destination loopback of other router with same prefix length and then we will examine if load balancing is occurring for traffic or not.


Lets Hop on to routers and put the config:



R1(config)#int lo0

R1(config-if)#ip add 1.1.1.1 255.255.255.0
R1(config-if)#exit

R1(config)#int s0/0

R1(config-if)#ip add 12.12.12.1 255.255.255.0

R1(config-if)#no sh

R1(config-if)#exit

R1(config)#int s0/1

R1(config-if)#ip add 112.112.112.1 255.255.255.0

R1(config-if)#no sh

R1(config-if)#exit

R1(config)#ip route 2.2.2.0 255.255.255.0 12.12.12.2

R1(config)#ip route 2.2.2.0 255.255.255.0 serial 0/1

=====================================================

R2(config)#int lo0

R2(config-if)#ip add 2.2.2.2 255.255.255.0

R2(config-if)#no sh

R2(config-if)#exit

R2(config)#int s0/0

R2(config-if)#ip add 12.12.12.2 255.255.255.0

R2(config-if)#no sh

R2(config-if)#exit

R2(config)#int s0/1

R2(config-if)#ip add 112.112.112.2 255.255.255.0

R2(config-if)#no sh

R2(config-if)#exit

R2(config)#ip route 1.1.1.0 255.255.255.0 12.12.12.1

R2(config)#ip route 1.1.1.0 255.255.255.0 s0/1 

=====================================================

R1#sh ip ro | b ^G

Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets

C       1.1.1.0 is directly connected, Loopback0

     2.0.0.0/24 is subnetted, 1 subnets

S       2.2.2.0 [1/0] via 12.12.12.2

                is directly connected, Serial0/1

     112.0.0.0/24 is subnetted, 1 subnets

C       112.112.112.0 is directly connected, Serial0/1

     12.0.0.0/24 is subnetted, 1 subnets

C       12.12.12.0 is directly connected, Serial0/0

R2#sh ip ro | b ^G

Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets

S       1.1.1.0 [1/0] via 12.12.12.1

                is directly connected, Serial0/1

     2.0.0.0/24 is subnetted, 1 subnets

C       2.2.2.0 is directly connected, Loopback0

     112.0.0.0/24 is subnetted, 1 subnets

C       112.112.112.0 is directly connected, Serial0/1

     12.0.0.0/24 is subnetted, 1 subnets

C       12.12.12.0 is directly connected, Serial0/0

=====================================================

R1#debug ip packet detail

IP packet debugging is on (detailed)

R1#ping 2.2.2.2 so lo0 r 4 

Type escape sequence to abort.

Sending 4, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1 

!!!!

Success rate is 100 percent (4/4), round-trip min/avg/max = 4/5/8 ms

R1#

*Mar  1 00:11:24.651: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB < Packet 1

*Mar  1 00:11:24.651: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending

*Mar  1 00:11:24.651:     ICMP type=8, code=0

*Mar  1 00:11:24.655: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB

*Mar  1 00:11:24.655: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4

*Mar  1 00:11:24.655:     ICMP type=0, code=0

*Mar  1 00:11:24.655: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB  < Packet 2

*Mar  1 00:11:24.655: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending

*Mar  1 00:11:24.655:     ICMP type=8, code=0

*Mar  1 00:11:24.663: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB

*Mar  1 00:11:24.663: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4

*Mar  1 00:11:24.663:     ICMP type=0, code=0

*Mar  1 00:11:24.663: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB < Packet 3

*Mar  1 00:11:24.663: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending

*Mar  1 00:11:24.663:     ICMP type=8, code=0

*Mar  1 00:11:24.667: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB

*Mar  1 00:11:24.667: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4

*Mar  1 00:11:24.667:     ICMP type=0, code=0

*Mar  1 00:11:24.667: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB < Packet 4

*Mar  1 00:11:24.667: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending

*Mar  1 00:11:24.667:     ICMP type=8, code=0

*Mar  1 00:11:24.671: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB

*Mar  1 00:11:24.671: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4

*Mar  1 00:11:24.671:     ICMP type=0, code=0

=====================================================

Umm....Looks like CEF is not happy with us :-P Lets turn it off :-)

R1(config)#no ip cef

R1#ping 2.2.2.2 so lo0 r 4

Type escape sequence to abort.

Sending 4, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1 

!!!!

Success rate is 100 percent (4/4), round-trip min/avg/max = 4/5/8 ms

R1#

*Mar  1 00:12:25.703: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via RIB< Packet 1

*Mar  1 00:12:25.703: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending

*Mar  1 00:12:25.703:     ICMP type=8, code=0

*Mar  1 00:12:25.707: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB

*Mar  1 00:12:25.707: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4

*Mar  1 00:12:25.707:     ICMP type=0, code=0

*Mar  1 00:12:25.707: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), routed via RIB< Packet 2

*Mar  1 00:12:25.707: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), len 100, sending

*Mar  1 00:12:25.707:     ICMP type=8, code=0

*Mar  1 00:12:25.715: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB

*Mar  1 00:12:25.715: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4

*Mar  1 00:12:25.715:     ICMP type=0, code=0

*Mar  1 00:12:25.715: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via RIB

*Mar  1 00:12:25.715: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending < Packet 3

*Mar  1 00:12:25.715:     ICMP type=8, code=0

*Mar  1 00:12:25.719: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB

*Mar  1 00:12:25.719: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4

*Mar  1 00:12:25.719:     ICMP type=0, code=0

*Mar  1 00:12:25.723: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), routed via RIB

*Mar  1 00:12:25.723: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), len 100, sending< Packet 4

*Mar  1 00:12:25.723:     ICMP type=8, code=0

*Mar  1 00:12:25.723: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB

*Mar  1 00:12:25.727: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4

*Mar  1 00:12:25.727:     ICMP type=0, code=0

Everything seems to be in shape now :-)

R1#sh ip route 2.2.2.0

Routing entry for 2.2.2.0/24

  Known via "static", distance 1, metric 0 (connected)

  Routing Descriptor Blocks:

  * 12.12.12.2

      Route metric is 0, traffic share count is 1

    directly connected, via Serial0/1

      Route metric is 0, traffic share count is 1

so conclusion is that despite of how you configure the static route (Exit Interface Vs Next Hop), the AD is always going to be 1.

Though specifying next hop has some advantages over exit interface option on Multi Access network types. But personally I like to use what I call mix of both in which while adding static route you specify exit interface with next hop address. This way we can make sure that no route-recursion issue will occur. And if you are thinking " Route Recursion issues with Static routing - what the hack is that" ?..ummm....let me save it for my next post for CCNA guys :-)

here is the syntax BTW which I just talked about

R1(config)#ip route 2.2.2.0 255.255.255.0 s0/0 12.12.12.2

R1(config)#ip route 2.2.2.0 255.255.255.0 s0/1 112.112.112.2

Further Readings: 

http://www.thebryantadvantage.com/CCNACertificationExamTutorialStaticRoutesIPRouteCommand.htm

http://cciepursuit.wordpress.com/2007/07/09/the-administrative-distance-of-a-static-route-pointed-to-an-interface-is-not-zero/

https://learningnetwork.cisco.com/message/34352

HTH...

Deepak Arora