• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 525
  • Last Modified:

Routing with RIP failing on Cisco 3620


I have a couple of routers setup and Rip is enabled.    However,  when a PC on one segment tries to communitate with the other,  PING for example,  it does not work.   We get ''Reply for 70.97.76.249: Destination net unreachable"

Basic setup is  :                              
                                 Cisco 3620                                                Siemens se5940
                         (e1/1 - 70.97.76.249/30)------<ethernet>-----(e0 - 70.97.76.250/30)
                                          |                                                                 |
                                          |                                                                 |
                           (f0/0 - 70.97.76.1/26)                                (e1 - 208.186.111.1/24)


                                 
The routers can ping each other on the   70.97.76.248/30 Network,  but cannot ping beyond that..
The Cisco appears to be the one sending out 'Destination net unreachable' replies.                                

We are using RIP for the routes,  and I can see the route on the IP route list as RIP.      If I watch the interface
I can see the ping packets enter the Cisco 3620,  and then reply packets leave the router.    However the router
is sending back 'Destination net unreachable' replies.. :-(  

Cisco 3620 Routes
--------------------
sh ip route :

  Gateway of last resort is 209.210.45.177 to network 0.0.0.0
 
       209.210.45.0/30 is subnetted, 1 subnets
  C       209.210.45.176 is directly connected, Serial0/0
       209.210.44.0/30 is subnetted, 1 subnets
  C       209.210.44.160 is directly connected, Serial1/0
       67.0.0.0/30 is subnetted, 1 subnets
  C       67.137.53.8 is directly connected, Serial0/1
       70.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
  C       70.97.76.0/26 is directly connected, FastEthernet0/0
  C       70.97.76.248/30 is directly connected, Ethernet1/1
  C       70.97.76.252/30 is directly connected, Ethernet1/0
  R    208.186.111.0/24 [120/1] via 70.97.76.250, 00:00:20, Ethernet1/1
  S*   0.0.0.0/0 [1/0] via 209.210.45.177
                       [1/0] via 67.137.53.9
                       [1/0] via 209.210.44.161


Thanks for any help.



0
networkfrontier
Asked:
networkfrontier
  • 3
  • 2
  • 2
  • +2
1 Solution
 
grsteedCommented:
So your saying that a ping from the 3620 doesn't reach a PC on the 208.186.111.0 network?

I think we need a more detailed explaination of your testing. Could you provide the following?

Goto Start > Run > CMD and enter TRACERT w.x.y.z

Traceroute from a PC on the 70.97.76.x network to 208.186.111.x  
Traceroute from a PC on the 208.186.111.x network to 70.97.76..x  

Also the IP routing table from the Siemens se5940

On the Routers are both using the same RIP version? (1 or 2)   What does the config look like on both for RIP?

Gary

0
 
mattacukCommented:
Can we see a running-config of the cisco router please? do you have any ACL's on the E 1/1 Interface?
As your know the router knows about network 208.186.111.0 and so I would suggest maybe something is blocking the ICMP echo request.

R    208.186.111.0/24 [120/1] via 70.97.76.250, 00:00:20, Ethernet1/1
0
 
mattacukCommented:
However having said that, Cisco describes the "Destination Network Unreachable" message as a router having no match in its routing table for the packets destination. This  might suggest the Siemens se5940 router does not have a route entry for the f0/0 - 70.97.76.1/26 on the Cisco router (it doesent know where to send the packet back). You may have a mismatch of RIP versions.
0
Granular recovery for Microsoft Exchange

With Veeam Explorer for Microsoft Exchange you can choose the Exchange Servers and restore points you’re interested in, and Veeam Explorer will present the contents of those mailbox stores for browsing, searching and exporting.

 
networkfrontierAuthor Commented:
Hi,   Here are some addtional details:

1.   The are both running RIP2,   I have also tried v1 as well.

2.   Tracert 1  (Se5940 connected PC   to   Cisco route)
          Tracing route to 70.97.76.1 over a maximum of 30 hops
               1  <1 ms  <1 ms <1 ms  208.186.111.1
               2  70.97.76.249  reports: Destination net unreachable.


3.   Tracert 2  (Cisco connected PC to Se5940 router )
          Tracing route to 208.186.111.1 over a maximum of 30 hops
               1     2 ms     3 ms     3 ms  70.97.76.1
               2     *        *        *     Request timed out.
               3     *        *        *     Request timed out.

4.  No access-lists on the Cisco

5.  No access lists on the Se5940

6.  Routing table on Se5940 :

    IP route   /  Mask   --> Gateway         Interface    Hops Flags

0.0.0.0        /00000000 --> 70.97.76.249    ETHERNET/0   1 NW FW PRM RP1 RP2
70.97.76.0     /ffffffc0 --> 70.97.76.249    ETHERNET/0   2 NW FW RP2
70.97.76.248   /fffffffc --> 0.0.0.0         ETHERNET/0   1 NW FW DIR PRM RP2
208.186.111.0  /ffffff00 --> 0.0.0.0         ETHERNET/0:1 1 NW FW DIR PRM RP1 RP2
208.186.111.1  /ffffffff --> 0.0.0.0         ETHERNET/0:1 0 ME

7.   Cisco config :

Using 13630 out of 30712 bytes
!
! Last configuration change at 17:14:21 MST Sun Mar 26 2006
! NVRAM config last updated at 17:14:22 MST Sun Mar 26 2006
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname SPR01-R1
!
boot-start-marker
boot-end-marker
!
logging buffered 16384 debugging
logging rate-limit all 10000
!
clock timezone MST -7
clock summer-time MDT recurring
no aaa new-model
ip subnet-zero
no ip source-route
!
!
ip cef
ip domain name networkfrontier.net
ip name-server 70.97.76.3
!
!
interface FastEthernet0/0
 description PublicIPs
 ip address 70.97.76.1 255.255.255.192
 ip helper-address 70.97.76.3
 no ip proxy-arp
 speed auto
 full-duplex
 no cdp enable
!
interface Serial0/0
 bandwidth 1544
 ip address 209.210.45.178 255.255.255.252
 ip helper-address 70.97.76.3
 ip load-sharing per-packet
 no cdp enable
!
interface FastEthernet0/1
 description PrivateIPs
 ip address 17.28.4.1 255.255.254.0
 no ip proxy-arp
 shutdown
 duplex auto
 speed auto
 no cdp enable
!
interface Serial0/1
 bandwidth 1544
 ip address 67.137.53.10 255.255.255.252
 ip helper-address 70.97.76.3
 ip load-sharing per-packet
 no cdp enable
!
interface Ethernet1/0
 description ISA
 ip address 70.97.76.253 255.255.255.252
 ip helper-address 70.97.76.3
 no ip proxy-arp
 no cdp enable
!
interface Serial1/0
 bandwidth 1544
 ip address 209.210.44.162 255.255.255.252
 ip helper-address 70.97.76.3
 ip load-sharing per-packet
 no cdp enable
!
interface Ethernet1/1
 description R1-Link
 ip address 70.97.76.249 255.255.255.252
 ip helper-address 70.97.76.3
 no ip proxy-arp
 ip rip send version 2
 ip rip receive version 2
 no cdp enable
!
router rip
 version 2
 redistribute static
 network 70.0.0.0
!
ip http server
no ip http secure-server
ip classless
ip route 0.0.0.0 0.0.0.0 209.210.45.177
ip route 0.0.0.0 0.0.0.0 67.137.53.9
ip route 0.0.0.0 0.0.0.0 209.210.44.161
!        
logging history debugging
logging trap debugging
logging 70.97.76.254
no cdp run
!
line con 0
line aux 0
line vty 0 4
 password *************
 login
!
ntp clock-period 17179776
ntp server 198.123.30.132
!
end  




0
 
networkfrontierAuthor Commented:

I think that the Se5940 is not a problem here,   as the packets from it's connected PC get all the way to
the Cisco before being stopped,  and a 'net unreachable' message is issued by the cisco on 70.97.76.249..

When the cisco connected PC  tries to ping the Se5940 (208.186.111.1)  it simply gets a timeout...

 
0
 
zyclonixCommented:
You're putting the wrong network into RIP. 70.0.0.0 means 70.0.0.0-70.0.0.255, not the whole class A. Try adding the network statement "network 70.97.76.0" to rip.

Routing protocols will not send advertisements for a subnet unless there is a valid subnet that matches the network statement on the router.
0
 
networkfrontierAuthor Commented:
We did enter 'network 70.97.76.0',   however when you save the config and then lookback it
it the router shows ' network 70.0.0.0'   it worked that out all by itself..    To check then i just
did it again,  here are the commands I type (first to remove the bad entry and then to put what
you suggest in) :

SPR01-R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SPR01-R1(config)#router rip
SPR01-R1(config-router)#no network 70.0.0.0
SPR01-R1(config-router)#network 70.97.76.0
SPR01-R1(config-router)#exit
SPR01-R1(config)#exit
SPR01-R1#wr
Building configuration...
[OK]
SPR01-R1#sh conf

!
router rip
 version 2
 redistribute static
 network 70.0.0.0


It keeps on entering the line as 70.0.0.0,  no matter what I type.

regards
Mark

0
 
grsteedCommented:
One other thing to try is  the "debug ip icmp" on the router.

You can read about it here.

http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017d00c.html#wp1017595

I should give some info on how the router is handling icmp packets.  It sure looks like something is not reponding correctly, although I don't see anything in the router config that would be blocking it.

Gary
0
 
calvinetterCommented:
From your previously posted routing tables for both routers, it looks like your problem is the Se5940 doesn't have a route for the 70.97.76.0/26 network.  (But your 3620 does have a route for the 208.186.111.0/24 network via RIP).

Disable auto-summarization on your 3620 & re-test:
   router rip
   no auto-summary
Hopefully the Se5940 will receive the correct routes, since "no auto-summary" in conjunction w/ using RIPv2 will cause the 3620 to send routing updates w/ subnet masks included.  Don't know if the Siemens box supports the equivalent of "no auto-summary", if so, enable it as well on the Se5940.

Glad to see you have the following on the 3620's e1/1 interface:
   ip rip send version 2
   ip rip receive version 2
Are there equivalent commands supported (or even needed) on the Se5940, I wonder?

cheers
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 3
  • 2
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now