Routing between RIP v1 and RIP v2

By arfs -

Routers Used: 3640 w/ NM-4T and NM-1FE-TX modules

IOS: c3640-jk9s-mz.124-16a

Objective
  • In this lab, configure RIP v1 and RIP v2 routing protocols. RIP v2 will be configured to accept RIP v1 updates.
Scenario
  • RIP v1 is presently running between Jakarta, Tegal, and Surabaya. New routers that support RIP v2 and variable-length subnet mask (VLSM) have been installed at the Tegal and Surabaya headquarters. However, an upgrade of the Jakarta router, which presently does not support RIP v2 will be installed at a later time. RIP v2 will have to be configured between Tegal and Surabaya. Surabaya will then need to be configured to receive RIP v1 updates so the Jakarta router will be able to communicate with Tegal.
Step 1
  • Build the network according to the diagram and configure all routers with RIP v1. Test connectivity between the routers and troubleshoot as necessary. A ping should be successful from one end of the network to the other.
Step 2
  • Verify that RIP v1 is running. There are several commands that could be used to verify RIP v1 is enabled and running. Two of the commands are shown below:
    Jakarta#sh ip protocols
    Routing Protocol is "rip"
    Outgoing update filter list for all interfaces is not set
    Incoming update filter list for all interfaces is not set
    Sending updates every 30 seconds, next due in 24 seconds
    Invalid after 180 seconds, hold down 180, flushed after 240
    Redistributing: rip
    Default version control: send version 1, receive any version
    Interface Send Recv Triggered RIP Key-chain
    Serial0/0 1 1 2
    FastEthernet1/0 1 1 2
    Automatic network summarization is in effect
    Maximum path: 4
    Routing for Networks:
    192.168.1.0
    192.168.224.0
    Routing Information Sources:
    Gateway Distance Last Update
    192.168.224.1 120 00:00:03
    Distance: (default is 120)
  • The debug router rip command can be used to check the type of updates the router is receiving and sending.
    Jakarta#
    *Mar 1 00:28:13.111: RIP: received v1 update from 192.168.224.1 on Serial0/0
    *Mar 1 00:28:13.115: 192.168.3.0 in 1 hops
    *Mar 1 00:28:13.119: 192.168.240.0 in 1 hops
    *Mar 1 00:28:13.119: 192.168.252.0 in 1 hops
    Jakarta#
    *Mar 1 00:28:17.211: RIP: sending v1 update to 255.255.255.255 via FastEthernet
    1/0 (192.168.1.3)
    *Mar 1 00:28:17.215: RIP: build update entries
    *Mar 1 00:28:17.215: network 192.168.3.0 metric 1
    *Mar 1 00:28:17.219: network 192.168.224.0 metric 1
    *Mar 1 00:28:17.219: network 192.168.240.0 metric 1
    *Mar 1 00:28:17.223: network 192.168.252.0 metric 1
  • Notice that all RIP v1 updates are sent using broadcast addresses through all the interfaces. The advertisements are also classful. That is, no mask information is carried in a RIP v1 update. RIP v1 does not support classless interdomain routing (CIDR) and VLSM.
  • Turn debug off if it is enabled and check that a route to 192.168.1.0 exists in the routing tables of the Tegal and Surabaya routers.
Step 3
  • The next step is to configure RIP v2 on the Tegal and Surabaya routers.
    Tegal(config)#router rip
    Tegal(config-router)#version 2

    Surabaya(config)#router rip
    Surabaya(config-router)#version 2
  • Issue a show running-config command on either Tegal or Surabaya and notice that RIP version 1 was replaced by RIP version 2. Issue the clear ip route * command to flush the
    routing table.
  • Check the routing table of the Tegal and Surabaya routers. Is there still a route to 192.168.1.0 on either router?
  • By default, RIP v1 will accept RIP v2 updates. However, RIP v2 will not accept RIP v1 updates. Therefore, RIP v2 must be configured to accept RIP v1 updates.
  • When debug ip rip is issued on the Jakarta and Tegal routers, it is possible to view RIP v1 accepting RIP v2 updates and RIP v2 ignoring RIP v1 updates. A sample output is shown below.
    Jakarta#
    *Mar 1 00:40:21.275: RIP: sending v1 update to 255.255.255.255 via FastEthernet
    1/0 (192.168.1.3)
    *Mar 1 00:40:21.279: RIP: build update entries
    *Mar 1 00:40:21.279: network 192.168.3.0 metric 1
    *Mar 1 00:40:21.283: network 192.168.224.0 metric 1
    *Mar 1 00:40:21.283: network 192.168.240.0 metric 1
    *Mar 1 00:40:21.287: network 192.168.252.0 metric 1
    *Mar 1 00:40:22.239: RIP: received v2 update from 192.168.224.1 on Serial0/0
    *Mar 1 00:40:22.243: 192.168.3.0/24 via 0.0.0.0 in 1 hops
    *Mar 1 00:40:22.247: 192.168.240.0/24 via 0.0.0.0 in 1 hops
    *Mar 1 00:40:22.247: 192.168.252.0/24 via 0.0.0.0 in 1 hops

    Tegal#
    *Mar 1 00:40:04.551: RIP: ignored v1 packet from 192.168.224.2 (illegal version
    )
    *Mar 1 00:40:04.719: RIP: sending v2 update to 224.0.0.9 via FastEthernet1/0 (1
    92.168.3.1)
    *Mar 1 00:40:04.723: RIP: build update entries
    *Mar 1 00:40:04.723: 192.168.1.0/24 via 0.0.0.0, metric 1, tag 0
    *Mar 1 00:40:04.727: 192.168.224.0/24 via 0.0.0.0, metric 1, tag 0
    *Mar 1 00:40:04.727: 192.168.240.0/24 via 0.0.0.0, metric 1, tag 0
    *Mar 1 00:40:04.731: 192.168.252.0/24 via 0.0.0.0, metric 1, tag 0
Step 4
  • Configure RIP v2 to accept RIP v1 updates.
    Tegal(config-if)#interface serial 0/0
    Tegal(config-if)#ip rip receive version 1
  • Issue the clear ip route * command to flush the routing table. Check the Tegal and
    Surabaya routing tables again. Is there a route for network 192.168.1.0?
  • Enable the debug ip rip command on Tegal to see RIP v2 now accepting RIP v1 updates. A sample output is shown below.
    Tegal#
    *Mar 1 00:52:00.659: RIP: received v1 update from 192.168.224.2 on Serial0/0
    *Mar 1 00:52:00.663: 192.168.1.0 in 1 hops
    Tegal#
    *Mar 1 00:52:08.675: RIP: sending v2 update to 224.0.0.9 via Serial0/1 (192.168
    .240.1)
    *Mar 1 00:52:08.679: RIP: build update entries
    *Mar 1 00:52:08.679: 192.168.1.0/24 via 0.0.0.0, metric 1, tag 0
    *Mar 1 00:52:08.683: 192.168.3.0/24 via 0.0.0.0, metric 1, tag 0
    *Mar 1 00:52:08.683: 192.168.224.0/24 via 0.0.0.0, metric 1, tag 0
    Tegal#
    *Mar 1 00:52:10.631: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (192.168
    .224.1)
    *Mar 1 00:52:10.631: RIP: build update entries
    *Mar 1 00:52:10.631: 192.168.3.0/24 via 0.0.0.0, metric 1, tag 0
    *Mar 1 00:52:10.631: 192.168.240.0/24 via 0.0.0.0, metric 1, tag 0
    *Mar 1 00:52:10.631: 192.168.252.0/24 via 0.0.0.0, metric 1, tag 0
Download

Popular posts from this blog

Cisco binary image unpacker

By arfs -
Image
Cisco binary image unpacker is a software that allows you to unpack the IOS and ASA images. Follow this steps to use this software for GNS3. With this way the Router loading process can be faster. This is useful for those of you that do start and stop Router frequently. Donwload Cisco image unpacker 0.1  for Windows. Extract thi zip file to your specific folder.. Copy the IOS file to this folder, for example "c3640-jk9s-mz.124-16a.bin". On windows command prompt, type the following command: "unpack c3640-jk9s-mz.124-16a.bin" (without ""). The output file stored in temporary folder, in my case "C:\Documents and Settings\dion\Local Settings\Temp". Open the folder and you will find the unpacked file "C3640-JK.bin", file size is about twofold. Copy "C3640-JK.bin" to your IOS folder. Your can also rename the file to "c3640-jk9s-mz.124-16a(unpacked).bin" Open GNS3, On the Edit menu, choose IOS image and hyper...
Read more

Connecting to Cisco Router console port using Linux

By arfs -
Image
I tried to connect my Ubuntu laptop to Cisco Router console port. I did successfully. What you will need: A roll-over cable (Cisco Console Cable). These are usually RJ-45 on the router side and serial on the PC side. If your laptop doesn’t have a serial port (like mine) you can get a 9-pin D-sub serial to USB cable. I got the BAFO USB Serial to DB9. I bought it in Ambassador Mall Kuningan Jakarta last night. Get Connected: Connect all the cables: USB -> Serial -> Crossover –> Console Port Download and Install Putty . root@dion-laptop:~# apt-get install putty Make sure that the USB to serial cable is recognized. root@dion-laptop:~# dmesg | grep tty [ 0.004000] console [tty0] enabled [ 1.923508] tty ptyx4: hash matches [ 131.637904] usb 3-2: pl2303 converter now attached to ttyUSB0 [ 173.768300] type=1503 audit(1243914954.561:5): operation="inode_permission" requested_mask="w::" denied_mask="w::" fsuid=0 name="/dev/ttyUSB0" pid=...
Read more

Examining the DR/BDR Election Process

By -
Image
Routers Used : 3640 w/ NM-1FE-TX IOS : c3640-jk9s-mz.124-16a Objective : In this lab, observe the OSPF DR and BDR election processing using debug commands. Then assign each OSPF interface a priority value to force the election of a specific router as a DR. Scenario The backbone of International Travel Agency’s enterprise network consists of three routers connected using an Ethernet core. Asterix1 has more memory and processing power than the other core routers. Unfortunately, other core routers are continually elected as the DR under the default settings. In the interest of optimization, ensure that Asterix1 is elected the DR, because it is best suited to handle associated extra duties, including management of Link State Advertisements (LSA) for Area 0. Investigate and correct this situation. Step 1 Build and configure the network according to the diagram. Use the configuration files from the previous lab if available . Configure OSPF on all Ethernet interfaces. A switch or hub is req...
Read more