August 2008


CCIE labs changing from UniversCD to Cisco Documentation

On Sept 24 2008 CCIE labs will no longer support using the UniversCD documentation for the lab exam.

All labs are migrating to Cisco Documentation only. For those scheduled to take the CCIE lab prior to Sept 24 access will still be available for UniversCD.

The Cisco Documentation pages have the same information that currently resides on UniversCD, please refer to the links on the CCIE web pages to view these pages and become familiar with the new format.

After Sept 24 2008 only the Cisco Documentation web pages will be available for CCIE labs.

Cross posted: http://www.cisco.com/web/learning/le3/ccie/announcements/index.html#universcd

We continue from the tutorial part 1 on RIP.  This tutorial will show you how to enable authetication for RIPv2.

In this scenario, we enable the simple authentication using plaintext password between R1 and R2 and Md5 authentication between R2 and R3.

Pls follow on the configuration and verification commands below.

Two options:

1. Plain text
2. MD5 Hash.

Step 1. Create a key chain, from global config mode using the “key chain” command. Give it a name (local significant)
Step 2. Create a key number, and put the password using the “key-string command” the string is your password so this should match on both routers.
Step 3. Apply the authentication on the interface facing the remote router. To apply use the  “ip rip authentication” command. Use mode MD5 for Md5 authentication and “mode text” for plain text (default).

Note: Cisco documentation says Key number should match but it was found out not true. see for your self.

Verification:

Step 4. Debug ip rip, this should tell you “RIP: ignored v2 packet from .. invalid authentication” means remote side has not yet been configured for authentication or the password is not correct.    So make sure password is the same on the both ends of the router. You can also see “RIP: received packet with MD5 authentication” if your MD5 auth is good. Plain text password can be seen on the debug ip rip output so a text password is never a secure option.

Step 5. Show key chain. This will show you the configured key available.

For more documentation of key chains for other IGP’s visit Cisco Doc CD.

HTH. Now back to the labs.

————————-R1—————————
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#key chain ?
WORD  Key-chain name
R1(config)#key chain R1-R2-Key
R1(config-keychain)#key ?
<0-2147483647>  Key identifier
R1(config-keychain)#key 0 ?
<cr>
R1(config-keychain)#key 0
R1(config-keychain-key)#?
Key-chain key configuration commands:
accept-lifetime  Set accept lifetime of key
default          Set a command to its defaults
exit             Exit from key-chain key configuration mode
key-string       Set key string
no               Negate a command or set its defaults
send-lifetime    Set send lifetime of key
R1(config-keychain-key)#key-string ?
0     Specifies an UNENCRYPTED password will follow
7     Specifies a HIDDEN password will follow
LINE  The UNENCRYPTED (cleartext) user password
R1(config-keychain-key)#key-string cisco123
R1(config-keychain-key)#int serial0/0
R1(config-if)#ip rip authentication ?
key-chain  Authentication key-chain
mode       Authentication mode
R1(config-if)#ip rip authentication key-chain R1-R2-Key
R1(config-if)#end
R1#deb
*Mar  1 07:34:49.366: %SYS-5-CONFIG_I: Configured from console by console
R1#debug ip rip
RIP protocol debugging is on
R1#
*Mar  1 07:35:12.070: RIP: sending v2 update to 192.168.1.2 via Serial0/0 (192.168.1.1)
*Mar  1 07:35:12.074: RIP: build update entries
*Mar  1 07:35:12.074:   172.16.10.0/24 via 0.0.0.0, metric 1, tag 0
*Mar  1 07:35:12.078:   172.16.40.0/24 via 0.0.0.0, metric 1, tag 0
R1#
*Mar  1 07:35:19.638: RIP: ignored v2 packet from 192.168.1.2 (invalid authentication)
R1#
———————–R2—————————-
!
key chain R2-Key-Name
key 200
key-string cisco123
!
R2#show key chain
Key-chain R2-Key-Name:
key 200 — text “cisco123″
accept lifetime (always valid) – (always valid) [valid now]
send lifetime (always valid) – (always valid) [valid now]
R2#s
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/0                  192.168.1.2     YES manual up                    up
Serial0/1                  10.10.10.2      YES NVRAM  up                    up
Serial0/2                  202.78.98.2     YES NVRAM  up                    up
Serial0/3                  unassigned      YES NVRAM  administratively down down
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s0/1
R2(config-if)#ip rip authentication ?
key-chain  Authentication key-chain
mode       Authentication mode
R2(config-if)#ip rip authentication mode ?
md5   Keyed message digest
text  Clear text authentication
R2(config-if)#ip rip authentication mode md5 ?
<cr>
R2(config-if)#ip rip authentication mode md5
R2(config-if)#ip rip authentication key-chain R2-Key-Name
R2(config-if)#
!
interface Serial0/0
ip address 192.168.1.2 255.255.255.0
ip rip authentication key-chain R2-Key-Name
serial restart-delay 0
!
interface Serial0/1
ip address 10.10.10.2 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain R2-Key-Name
serial restart-delay 0
!
———————-R3——————-
R3#sh key chain
Key-chain R3-key:
key 333 — text “cisco123″
accept lifetime (always valid) – (always valid) [valid now]
send lifetime (always valid) – (always valid) [valid now]
R3#sh run int s0/0
Building configuration…
Current configuration : 160 bytes
!
interface Serial0/0
ip address 10.10.10.3 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain R3-key
serial restart-delay 0
end
R3#

RIPv2 is one of the more taken for granted protocol. Here is an advance tutorial for RIPv2 that will tell you hey it’s not that bad at all. RIP version 2 in particular still exist in today’s new routing machines because of its robustness and as being an industry standard.

I made a dynamips .Net config for you to simulate. I always belived that “labbing is learning” so bring it on!

Dynamips config:

autostart = False
[localhost:7200]
    workingdir = \Working Lab\RIP Filtering\working
    [[3640]]
        image = \IOS\c3640-js-mz.124-19a\c3640-js-mz.124-19a.extracted.BIN
        idlepc = 0x604f83b4
        ghostios = True
        chassis = 3640
    [[ROUTER R4]]
        model = 3640
        console = 2004
        slot0 = NM-4T
        s0/0 = R2 s0/2
    [[ROUTER R1]]
        model = 3640
        console = 2001
        slot0 = NM-4T
        s0/0 = R2 s0/0

    [[ROUTER R2]]
        model = 3640
        console = 2002
        slot0 = NM-4T
        s0/0 = R1 s0/0
        s0/1 = R3 s0/0
        s0/2 = R4 s0/0

    [[ROUTER R3]]
        model = 3640
        console = 2003
        slot0 = NM-4T
        s0/0 = R2 s0/1

Diagram:

Step 1. Configure R1, R2, R3, R4, from scratch, do the house keeping, put corresponding router hostname according to the diagram.

Step 2. Advertise all loopbacks and serial interfaces on each router to RIPv2 process. You should see all remote loopbacks and serial p2p interface on each router accordingly. This is the basic RIP config as we commonly knew it. Passive interface by default, use version 2 and no auto-summary.

Step 3. Between R1 and R2, use unicast updates. Use neighbor statements.

Step 4. Between R2 and R3, use the multicast updates (default).

Step 5. Between R2 and R4, use  broadcast but on RIP version 2. Use the ip rip v2-broadast on the interface facing R4 on R2.

Step 6. Debug IP RIP and see how the RIP updates – sending and receiving behaves on each on the scenario on steps 3,4,5.

Filtering:

Step 7. On R1, use the common “”distributel-list” in on the serial facing R2 for network at R4.

Step 8. Poison the routes of R3 networks. Use offset-list command, use access-list to match the source network. To poison a route means putting an unacceptable metric i.e. >16 hops.

Step 9. Dont forget the AD, remember an administrative distance of 255 is considered to be invalid or not used therefore RIP will not install it on the routing table.

Conclusion:

RIPv2 uses default multicast address to 224.0.0.9 to search RIP neighbors. There are also other options line unicasting it using the neighbor command under router rip and we can also use broadcast to all host 255.255.255.255 even thoug we are using RIPv2. We use the ip rip v2-broadcast interface command facing the RIP neighbor.

Filtering RIP has also some tricks we can choose distribute-list (common), offset-list and distance command.

Download here the Routers  config: r1-r2-r3-r4-config-rip-filtering-and-updates.doc

Hope this helps. Now back to the labs.

en
conf t
alias exec s show ip interface brief
alias exec srb show run | b
alias exec sri show run | i
alias exec sr  show run
alias exec sir show ip route
alias exec sir6 show ipv6 route
alias exec sip show ip protocol
alias exec sip6 show ipv6 protocol
alias exec sib show ip bgp
alias exec sib6 show ipv6 bgp
alias exec sio  show ip ospf
alias exec sf   show frame-relay
no ip domain-lookup

enable secret cisco
logging buffered 4096

line con 0
logging synchronous
privilege level 15
exec-timeout 0 0

line vty 0 4
logging synchronous
privilege level 15
exec-timeout 0 0
no login
end
wr
conf t
hostname ?

These are my common aliases I always put on my CCIE Lab router and switch.  These commands are very useful to me because it does the house keeping for a fresh router/switch. My most favorite alias is “s”.

I am finishing on the Drill-iT labs for switching (Lab01 and Lab02). I fortified my knowledged in switching, i.e. VTP, VTP pruning, Trunking, SVI’s, etc. Most of all what I discover most is that the workbook before I found to be a very intimidating one and now as I progress my studies everyday, I learned a lot and on second glance of the workbooks it is not that hard at all.

Lessons learned: Practice is a key. More good practice is the solution.

Btw, when I put back my switches to a fresh config I do,

show run | i interface|description
wr erase
delete vlan.dat
reload

After each reload, I immediately put back the interface description and hostnames, paste the above aliases and other house keeping commands.

Now back to the the labs…

CCNA Wireless Certification Released

CCNA Wireless recognizes the critical importance of professionals supporting wireless LANS including Networking Associates/Administrators, Wireless Support Specialists and WLAN project managers.
The CCNA Wireless Certification validates candidate’s skills in the configuration, implementation and support of wireless LANs, specifically those networks using Cisco equipment. Students completing the recommended Cisco training are provided with information and practice activities to prepare them for, configuring, monitoring and troubleshooting basic tasks of a Cisco WLAN in SMB and Enterprise networks. Employers will be able to validate their staff have the skills needed for basic wireless networking on a Cisco WLAN in SMB and enterprise networks after completing certification.

Exam: 640-721 IUWNE     Implementing Cisco Unified Wireless Networking Essentials (IUWNE)