Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

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

Comments

8 Responses to “What’s The Deal With RIP Triggered Extensions?!”

  1. Scott V on October 29th, 2008 11:40 pm

    Hey Joe,

    I have no idea what was meant by whatever you were reading about that database. Just doesn’t fundamentally make sense, does it? RIP triggered should eliminate periodic refresh in the absense of change but I would think the datebases need to populate no matter what (given that routing tables always derive from information contained in databases).

    As for why it might not be working as you expect…

    I assume you have RIP triggered enable on both ends of the link? That’s a requirement. OK, next step is to see what you see with:

    ‘debug ip rip trigger’

    (on both ends – and possibly also ‘debug ip rip’)

    I’m no RIP expert, nor am I any great fan of Frame Relay. But I’ll be glad to try to help you figure it all out if I can (no promises, naturally).

    Cheers,

    Scott

  2. Joe A on October 30th, 2008 11:17 am

    Hey Scott, thanks for the comments. What I was reading is in the command reference guide:

    http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_rip.html#wp1011787

    “show ip rip database

    Displays the contents of the RIP private database when triggered extensions to RIP are enabled. ”

    What you are saying definitely makes sense though.

  3. Joe A on October 30th, 2008 11:38 am

    Well…I dunno but I tried it again and now it works…mmmmmmm whatever.

  4. Scott V on October 30th, 2008 11:45 am

    Don’t you hate when that happens!

    Well, just remember that debug command. It should help to lead you to any problems with that feature.

    Best,

    Scott

  5. CCIE Journey on October 30th, 2008 11:46 am

    “no router rip” always seems to be the best way to fix RIP 😀

  6. Scott V on October 30th, 2008 5:19 pm

    LOL, that is so true! I had planned to overlook RIP entirely in my review of R&S material but ultimately wimped out and at least glanced at it. You never know what someone might toss your way as part of the “stump the CCIE” game in technical interviews. Furthermore, we still have to recertify every two years and v2 is still on the blueprint…

  7. M Khan on May 18th, 2009 8:48 pm
  8. Vivek on September 29th, 2009 1:28 am

    What i thought About RIPv2 is used the IP rip trigger command when we work on slower links and it must be configured on both of side, as per you config you have not cleared it that the Ip rip trigger is configured in both the end. and scott is right if you need to check u can use Debug,

    Vivek
    CCNA

Leave a Reply