Re: RIPv2 over Tunnels

mwickings · ‎09-23-2004

Hi,

I have a 3 site triangle, with a 2621, an 827 and a SOHO97, all have a link to each other, but when i try and do rip routing - it only works between the 2621 and the 827, the soho97 only seems to take part when it is seeing the RIP traffic via the LAN. I have done debugging and i can see both the 827 and the 2621 sending RIP updates down the tunnels, but on the soho i don't see any rip from the tunnels.

Any idea's?

i taken off all ACL's - made no differance

Upgraded to latest IOS, this coursed more issues to do with CNBAR? and nat, i had to downgrade to 12.3(2)T7 and thats whats running at the moment.

Is it just a limitation of the SOHO97's ?

Richard Burts · ‎09-23-2004

I do not have experience with the SOHO97 but there are a couple of questions to investigate. Is the tunnel successful to the SOHO97? If you traceroute from the 2621 and the 827 to addresses on the SOHO97 does the traffic go over the tunnel. If you traceroute from the SOHO97 to addresses on the 2621 or the 827 does the traffic go over the tunnel.

Can you post the output of show ip protocol on the SOHO97?

HTH

Rick

HTH

Rick

mwickings · ‎09-23-2004

Routing Protocol is "rip"

Sending updates every 30 seconds, next due in 12 seconds

Invalid after 180 seconds, hold down 180, flushed after 240

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Redistributing: static, rip

Default version control: send version 2, receive version 2

Interface Send Recv Triggered RIP Key-chain

Ethernet0 2 2

Automatic network summarization is not in effect

Maximum path: 4

Routing for Networks:

80.0.0.0

172.31.0.0

Routing Information Sources:

Gateway Distance Last Update

172.31.33.130 120 00:00:08

172.31.33.131 120 00:00:06

172.31.33.132 120 00:00:08

172.31.33.133 120 00:00:05

172.31.33.139 120 00:00:19

172.31.33.141 120 00:00:07

Distance: (default is 120)

the rip config:

router rip

version 2

redistribute static

network 80.0.0.0

network 172.31.0.0

no auto-summary

and i have tried the no passive-interface tunnel1 with the passive-interface default set, but that makes no differance - on the LAN however, as you can see, its fine.

Richard Burts · ‎09-23-2004

It is not clear which router you did these show commands. Which router was it?

Also you did not answer the question I asked about verifying that the tunnels are working correctly.

HTH

Rick

HTH

Rick

mwickings · ‎09-23-2004

Sorry,

Its all on the SOHO97, the 800 and 2600 are working fine the tunnels are working and also encrypted with IPSec

i have attached a daig

dbellazetin · ‎09-23-2004

If the problem is sending from the Soho, but you are receiving ok then try adding in the following commands to the Soho's RIP configuration.

neighbor 1.1.1.1

neighbor 1.1.1.2

This will send the updates in unicast format. See if that makes a difference.

Daniel

mwickings · ‎09-24-2004

I did not think of the neighbor thing, but i have added the statements and it still does not work. I also discovered some new interface commands

int tu1

ip rip send ver 2

ip rip receive ver 2

But still the router sees nothing from them, check the debug ip rip in my other reply. This was after these changes.

Richard Burts · ‎09-23-2004

The output of show ip protocol that you posted indicates that there are 6 active neighbors. Did that come from the SOHO router?

If you could post the output of debug ip rip on the SOHO router it might provide some answers.

Are you sure that the SOHO configuration of RIP includes a network statement that includes the network of the Tunnel interface?

I still do not see an answer to my question about if you trace from the 2600 or 800 to addresses on the SOHO does the traceroute indicate success in going through the tunnel.

HTH

Rick

HTH

Rick

mwickings · ‎09-24-2004

The output of show ip protocol that you posted indicates that there are 6 active neighbors. Did that come from the SOHO router?

Yes, but it was from the LAN, not the tunnels

debug ip rip:

Sep 24 12:14:52.869 UTC: RIP: Update sent via Ethernet0

Sep 24 12:14:57.597 UTC: RIP: received v2 update from 172.31.33.141 on Ethernet0

Sep 24 12:14:57.597 UTC: 172.28.3.0/24 via 172.31.33.141 in 1 hops

Sep 24 12:14:57.597 UTC: 193.128.169.0/24 via 172.31.33.141 in 1 hops

Sep 24 12:14:57.597 UTC: 193.133.123.0/24 via 172.31.33.141 in 1 hops

Sep 24 12:14:57.597 UTC: RIP: Update contains 3 routes

Sep 24 12:14:57.709 UTC: RIP: received v2 update from 172.31.33.132 on Ethernet0

Sep 24 12:14:57.709 UTC: 172.31.34.0/26 via 172.31.33.132 in 1 hops

Sep 24 12:14:57.709 UTC: RIP: Update contains 1 routes

Sep 24 12:14:58.413 UTC: RIP: received v2 update from 172.31.33.139 on Ethernet0

Sep 24 12:14:58.413 UTC: 82.70.50.246/32 via 172.31.33.139 in 1 hops

Sep 24 12:14:58.413 UTC: 193.195.40.8/29 via 172.31.33.139 in 1 hops

Sep 24 12:14:58.413 UTC: 193.195.40.11/32 via 172.31.33.139 in 1 hops

Sep 24 12:14:58.413 UTC: 194.217.150.0/24 via 172.31.33.139 in 1 hops

Sep 24 12:14:58.421 UTC: 194.217.242.0/24 via 172.31.33.139 in 1 hops

Sep 24 12:14:58.421 UTC: 195.10.240.60/32 via 172.31.33.139 in 1 hops

Sep 24 12:14:58.421 UTC: 217.155.219.8/32 via 172.31.33.139 in 1 hops

Sep 24 12:14:58.421 UTC: RIP: Update contains 7 routes

Sep 24 12:14:58.581 UTC: RIP: received v2 update from 172.31.33.131 on Ethernet0

Sep 24 12:14:58.581 UTC: 172.31.33.112/28 via 172.31.33.131 in 1 hops

Sep 24 12:14:58.585 UTC: 172.31.33.224/27 via 172.31.33.131 in 1 hops

Sep 24 12:14:58.585 UTC: RIP: Update contains 2 routes

Sep 24 12:14:59.221 UTC: RIP: received v2 update from 172.31.33.133 on Ethernet0

Sep 24 12:14:59.221 UTC: 172.31.33.0/26 via 172.31.33.133 in 1 hops

Sep 24 12:14:59.221 UTC: 172.31.33.192/27 via 172.31.33.133 in 1 hops

Sep 24 12:14:59.221 UTC: RIP: Update contains 2 routes

Sep 24 12:15:08.037 UTC: RIP: received v2 update from 172.31.33.130 on Ethernet0

Sep 24 12:15:08.037 UTC: 172.31.33.64/28 via 0.0.0.0 in 1 hops

Sep 24 12:15:08.037 UTC: RIP: Update contains 1 routes

Sep 24 12:15:22.654 UTC: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (172.31.33.134)

Sep 24 12:15:22.654 UTC: RIP: build update entries

Sep 24 12:15:22.654 UTC: 0.0.0.0/0 via 0.0.0.0, metric 1, tag 0

Sep 24 12:15:22.654 UTC: 82.133.92.0/27 via 0.0.0.0, metric 1, tag 0

Sep 24 12:15:22.654 UTC: 82.133.92.32/27 via 0.0.0.0, metric 1, tag 0

Sep 24 12:15:22.654 UTC: 82.133.92.64/27 via 0.0.0.0, metric 1, tag 0

Sep 24 12:15:22.658 UTC: 82.133.92.225/32 via 0.0.0.0, metric 1, tag 0

Sep 24 12:15:22.658 UTC: 82.133.92.226/32 via 0.0.0.0, metric 1, tag 0

Sep 24 12:15:22.658 UTC: 82.133.122.192/32 via 0.0.0.0, metric 1, tag 0

Sep 24 12:15:22.658 UTC: RIP: Update contains 7 routes

Sep 24 12:15:22.658 UTC: RIP: Update queued

Sep 24 12:15:22.658 UTC: RIP: rip_sendupdate_vk() no source specified. Set source.

Sep 24 12:15:22.662 UTC: RIP: source 0.0.0.0, mask 0.0.0.0

Sep 24 12:15:22.662 UTC: -Traceback= 801E4750 801E4D1C 801E4E2C 8034CEAC 801E983C 801E9E08 8015D980 8016186C

Sep 24 12:15:22.662 UTC: RIP: rip_sendupdate_vk() no source specified. Set source.

Sep 24 12:15:22.662 UTC: RIP: source 0.0.0.0, mask 0.0.0.0

Sep 24 12:15:22.662 UTC: -Traceback= 801E4750 801E4D1C 801E4E2C 8034CEAC 801E983C 801E9E08 8015D980 8016186C

Are you sure that the SOHO configuration of RIP includes a network statement that includes the network of the Tunnel interface?

-Yes

I still do not see an answer to my question about if you trace from the 2600 or 800 to addresses on the SOHO does the traceroute indicate success in going through the tunnel.

As i said before, the tunnels work fine, i can trace, ping, remote desktop through them with statics fine.

mwickings · ‎09-24-2004

I Put this through the cisco out interpreter and it said:-

STACK DECODE NOTIFICATIONS (if any)

The failure was caused by a software defect.

The stack trace decoded symbols are:

rip_sendupdate_vk

rip_sendupdate_subr

rip_sendupdate

pdb_majorupdate

rip_process_mgd_timers

rip_router

ppc_process_dispatch

process_execute

Possible bug matches are listed below. Bugs with a score of .90 or more

are the most likely candidates:

Score Bugid Status Fixed In Duplicate Title

0.93 CSCdy77097 R 12.3(7)XI 12.2(21.10)SV 12.2(21.10)S1 12.2(21.10)S 12.3(4.4)B 12.3(3.3)T 12.3(3.3) 12.3(3.1)T CSCdy77097 RIP Jumbo fix for VPN and Performance

0.65 CSCea56883 R 12.3(7)XI1 12.2(23.9)S 12.3(7.4)T 12.3(7.4) CSCdy77097 Router hangs due to bus error at network_check

0.65 CSCec53123 R 12.3(5d) 12.3(7)XI 12.3(3g) 12.3(5.12)T 12.3(5.12) CSCea22843 spurious access found in rip routing test

0.58 CSCed24784 D 12.3(5d) 12.3(7)XI 12.3(3g) 12.3(5.12)T 12.3(5.12) CSCea22843 RIP process generates Tracebacks periodically

0.58 CSCec86261 D 12.3(7)XI 12.2(21.10)SV 12.2(21.10)S1 12.2(21.10)S 12.3(4.4)B 12.3(3.3)T 12.3(3.3) 12.3(3.1)T CSCea56883 Router crashes with bus error sig=10 in network_check

0.58 CSCeb16868 D 12.3(5d) 12.3(7)XI 12.3(3g) 12.3(5.12)T 12.3(5.12) CSCdy77097 RIP tracebacks when dial backup not in use

0.58 CSCea54137 D CSCea22843 traceback in rip_sendupdate_vk

0.58 CSCds77692 C 12.3(5d) 12.3(7)XI 12.3(3g) 12.3(5.12)T 12.3(5.12) CSCdz47082 RIP update problem after reload

So it looks like its a bug, but the problem is, if i upgrade the IOS then NAT stops working as it activates CNBAR, or NBAR by defualt and when it boots you just get a CNBAR nat error and i can not figure out what to do to get it to work....

Richard Burts · ‎09-24-2004

Perhaps the most interesting and potentially informative parts of this post is the traceback indication. The debug shows successful sending and receiving of updates on the Ethernet interface. So I am assuming that the traceback when RIP attempts to transmit is probably when it attempts to send over the tunnel.

A traceback is a sign of a software problem. I have been in situations where we were getting tracebacks similar to this and found that removing the routing protocol configuration and putting it back resolved the issue. So I would suggest that you do a no router rip which will remove the protocol and then put the RIP configuration back into the router.

Another suggestion is to be sure that RIP is included as traffic to be protected over the tunnel.

It might be helpful if you posted details of the tunnel interface configuration and the RIP configuration. I would also like to see the output of show ip interface on the SOHO router.

HTH

Rick

HTH

Rick

mwickings · ‎09-24-2004

yeah i ran it through the cisco interpretor, see my other post. Looks like a bug

I did a no router rip and then re-applied it, but still no avail. the tunnel permits ip any any, so i doubt it that, i have also tried running it in just GRE tunnel mode, so no ipsec was involved and it had the same prob

heres the config u wanted;

JISL-RTR1-CHEL#sh run | be router rip

router rip

version 2

redistribute static

network 80.0.0.0

network 172.31.0.0

neighbor 82.133.92.205

neighbor 82.133.92.209

no auto-summary

interface Tunnel1

description ### Tunnel to BB Maccelsfield ###

ip address 82.133.92.210 255.255.255.252

ip rip send version 2

ip rip receive version 2

tunnel source Dialer1

tunnel destination 195.38.68.219

tunnel path-mtu-discovery

tunnel protection ipsec profile BB

end

JISL-RTR1-CHEL#sh run int tu2

Building configuration...

Current configuration : 288 bytes

!

interface Tunnel2

description ### Tunnel to BB Chestfield ###

ip address 82.133.92.206 255.255.255.252

ip rip send version 2

ip rip receive version 2

tunnel source Dialer1

tunnel destination 82.133.122.192

tunnel path-mtu-discovery

tunnel protection ipsec profile BB

end

sh ip int brie

Interface IP-Address OK? Method Status Protocol

ATM0 unassigned YES NVRAM up up

ATM0.1 unassigned YES unset up up

Dialer1 82.133.99.207 YES IPCP up up

Ethernet0 172.31.33.134 YES NVRAM up up

Tunnel1 82.133.92.210 YES NVRAM up up

Tunnel2 82.133.92.206 YES NVRAM up up

Virtual-Access1 unassigned YES unset up up

Virtual-Access2 unassigned YES unset up up

A show int would not fit in here

Richard Burts · ‎09-24-2004

Thanks for posting this. The first thing that jumps out at me is that under router rip the network statement is for network 80.0.0.0. But the tunnel addresses are in 82.133.92.x. So RIP is not seeing the tunnels as interfaces it should process. What happens if you put a network 82.0.0.0 under router rip?

HTH

Rick

HTH

Rick

mwickings · ‎09-27-2004

Yup that was it, ha i did not see that i had put the 80.x.x.x network in there, in my brain it was reading 82.x.x.x - thanks for pointing that out, it all seems to work now!! at last

Thanks very much!

Mark