I was just finishing up my technology specific lab on RIP (IPexpert Volume 1, Lab 8). Step 14 gives the following requirement:

“Routes learned from BB1 that have an odd number in the third octet should be seen with a metric of 10 at R5. The access-list used should contain a single line”

To give you a little backround on the topology, BB1 connects to R1, which connects over ethernet to R2, which connects via frame to R5.

OK…

access-list 5 permit 0.0.1.0 255.255.254.255
router rip
offset-list 5 in 8 e0/0

show ip protocols (supressed output below)
Incoming routes in Ethernet0/0 will have 8 added to metric if on list 5

Now, the very next step in the lab gives this requirement:

“routes in the 64.0.0.0/7 range should not be allowed in your network at all. The access-list should contain a single line”

OK…

access-list 10 permit 64.0.0.0 1.255.255.255
router rip
offset-list 10 in 15 e0/0

show ip protocols (supressed output)
Incoming routes in Ethernet0/0 will have 15 added to metric if on list 10

That’s it! So the moral of the story here is that so far as I can tell you can not apply 2 seperate offset-lists to a single interface in RIP. I suppose to do this task I could just use a distribute-list for the 2nd task.

– Joe

So I am labbing away last night on RIPv2. I come across a task in the IPX Volume 1 workbook to configure 2 routers connected via p2p serial interfaces for triggered updates…OK no problem. I configure the commands, but never see the correct validation under the show command. If anybody can explain to me what the hell is going on here, I would greatly appreciate it! My only thought is it must be some sort of bug…running 12.4 code.

Here is my p2p link on one side for instance:

R2(config-if)#do sh run int s2/0.24
Building configuration…

Current configuration : 231 bytes
!
interface Serial2/0.24 point-to-point
description Frame Relay Cloud 2
ip address 150.100.24.2 255.255.255.0
ip rip triggered
ip rip authentication key-chain R2R4
snmp trap link-status
frame-relay interface-dlci 204
end

According to the proctor guide, when doing “show ip protocols” you should see “Yes” in the column regarding triggered updates, but alas, nothing!

R2(config-if)#do sh ip proto
Routing Protocol is “rip”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Serial2/0.25 filtered by 1, default is 1
Incoming routes in Serial2/0.25 will have 4 added to metric if on list 1
Incoming routes in Serial2/0.26 will have 4 added to metric if on list 1
Incoming routes in Serial2/1 will have 4 added to metric if on list 1
Sending updates every 30 seconds, next due in 24 seconds
Invalid after 180 seconds, hold down 0, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
Ethernet0/0 2 2
Serial2/0.24 2 2 R2R4
Serial2/0.25 2 2 R2R5
Serial2/0.26 2 2 R2R6
Serial2/1 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
150.100.0.0
200.0.0.0
Passive Interface(s):
Passive Interface(s):
Ethernet0/1
Serial2/0
Serial2/2
Serial2/3
Loopback0
VoIP-Null0
Routing Information Sources:
Gateway Distance Last Update
150.100.100.6 120 00:00:02
150.100.100.5 120 00:00:03
150.100.24.4 120 00:00:06
150.100.25.5 120 00:00:19
150.100.12.1 120 00:00:18
Distance: (default is 120)

BUT ….

I’ve found cisco documentation that states the output of the “show ip rip database” command will be blank unless you have configured triggered updates…

and alas…I can issue that command and see output:

R2(config-if)#do show ip rip database
100.0.0.0/8 auto-summary
100.0.0.0/8
[15] via 150.100.25.5, 00:00:14, Serial2/1
100.100.100.0/24
[1] via 150.100.12.1, 00:00:13, Ethernet0/0
150.100.0.0/16 auto-summary
150.100.12.0/24 directly connected, Ethernet0/0
150.100.24.0/24 directly connected, Serial2/0.24
150.100.25.0/24 directly connected, Serial2/1
150.100.40.0/24
[1] via 150.100.24.4, 00:00:19, Serial2/0.24
150.100.41.0/24
[1] via 150.100.24.4, 00:00:19, Serial2/0.24
150.100.69.0/24
[1] via 150.100.100.6, 00:00:14, Serial2/0.26
150.100.78.0/24
[2] via 150.100.100.6, 00:00:14, Serial2/0.26
[2] via 150.100.25.5, 00:00:14, Serial2/1
150.100.81.0/24
[3] via 150.100.100.6, 00:00:14, Serial2/0.26
[3] via 150.100.25.5, 00:00:14, Serial2/1
150.100.91.0/24
[2] via 150.100.100.6, 00:00:14, Serial2/0.26
150.100.100.0/24 directly connected, Serial2/0.26
150.100.220.0/24
[1] via 150.100.25.5, 00:00:16, Serial2/1
[1] via 150.100.100.6, 00:00:15, Serial2/0.26
150.100.221.0/24
[1] via 150.100.25.5, 00:00:16, Serial2/1
[1] via 150.100.100.6, 00:00:15, Serial2/0.26
172.1.0.0/16 auto-summary
172.1.0.0/16
[15] via 150.100.25.5, 00:00:16, Serial2/1
172.1.0.0/22
[1] via 150.100.12.1, 00:00:14, Ethernet0/0
200.0.0.0/24 auto-summary
200.0.0.0/24 is possibly down
200.0.0.1/32
[1] via 150.100.12.1, 00:00:14, Ethernet0/0
200.0.0.2/32 directly connected, Loopback0
200.0.0.4/32
[1] via 150.100.24.4, 00:00:21, Serial2/0.24
200.0.0.5/32
[1] via 150.100.25.5, 00:00:16, Serial2/1
200.0.0.6/32
[1] via 150.100.100.6, 00:00:15, Serial2/0.26
200.0.0.7/32
[2] via 150.100.100.6, 00:00:17, Serial2/0.26
[2] via 150.100.25.5, 00:00:17, Serial2/1
200.0.0.8/32
[7] via 150.100.100.5, 00:00:20, Serial2/0.25
[7] via 150.100.25.5, 00:00:17, Serial2/1
[7] via 150.100.100.6, 00:00:17, Serial2/0.26
200.0.0.9/32
[2] via 150.100.100.6, 00:00:17, Serial2/0.26