Routing problem with 2501

brianb68 · ‎01-24-2003

I'm having routing problems. I am trying to route from my WAN segments to 161.125.3.100 and 161.125.198.5 which is on one segment of my WAN. Each segment has a 2501 with the static route pointing to the main 2501(the config will follow) i can ping 161.125.3.100 and 161.125.198.5 from the main 2501. When i try to traceroute from the other segments it is stopping at the main 2501.

Configuation file:

SW2501#show run

Building configuration...

Current configuration:

!

version 11.3

no service password-encryption

service udp-small-servers

service tcp-small-servers

!

hostname SW2501

!

enable secret 5 --moderator edit--

enable password

!

ip subnet-zero

ip nat pool lawrnc 172.21.25.17 172.21.25.46 prefix-length 14

ip nat pool newc 172.21.25.81 172.21.25.94 prefix-length 14

ip nat pool butler 172.21.25.1 172.21.25.14 prefix-length 14

ip nat pool washng 172.21.25.49 172.21.25.62 prefix-length 14

ip nat pool westmr 172.21.25.65 172.21.25.78 prefix-length 14

ip nat pool brooml 172.21.25.97 172.21.25.110 prefix-length 14

ip nat pool ftp 172.21.25.127 172.21.25.127 prefix-length 14

ip nat pool newcdial 172.21.25.95 172.21.25.96 prefix-length 14

ip nat pool westmail 172.21.25.46 172.21.25.46 prefix-length 14

ip nat inside source list 10 pool butler

ip nat inside source list 20 pool butler

ip nat inside source list 32 pool lawrnc

ip nat inside source list 33 pool lawrnc

ip nat inside source list 34 pool lawrnc

ip nat inside source list 35 pool lawrnc

ip nat inside source list 36 pool lawrnc

ip nat inside source list 50 pool ftp

ip nat inside source list 51 pool westmail

ip nat inside source list 63 pool lawrnc

ip nat inside source list 65 pool westmr

ip nat inside source list 96 pool newcdial

ip nat inside source list 98 pool brooml

ip nat inside source list 99 pool newc

ip nat inside source static 176.16.0.5 172.21.25.127

ip host BR 193.0.0.102

ip host FC 161.125.2.130

ip host WS 128.1.0.227

ip host LA 10.2.2.1

ip host WM 192.168.255.1

ip host utec 164.156.51.231

ip host Indy 192.168.222.1

ip name-server 206.101.113.2

!

interface Ethernet0

ip address 176.16.0.254 255.255.0.0

ip nat inside

no ip route-cache

no ip mroute-cache

!

interface Serial0

no ip address

encapsulation frame-relay

no ip route-cache

no ip mroute-cache

bandwidth 768

no fair-queue

frame-relay lmi-type ansi

!

interface Serial0.1 point-to-point

description To Broomall, PA dlci 32

ip address 180.23.14.1 255.255.255.252

ip nat inside

no ip route-cache

no ip mroute-cache

frame-relay interface-dlci 38

!

interface Serial0.2 point-to-point

description To Butler Co., PA dlci 32

ip address 189.23.14.2 255.255.255.252

ip nat inside

no ip route-cache

no ip mroute-cache

frame-relay interface-dlci 37

!

interface Serial0.3 point-to-point

description To Falls Church, VA dlci 30

ip address 161.125.2.129 255.255.255.252

no ip route-cache

no ip mroute-cache

frame-relay interface-dlci 34

!

interface Serial0.5 point-to-point

description To Lawrence Co., PA dlci 37

ip address 183.23.14.2 255.255.255.252

ip nat inside

no ip route-cache

no ip mroute-cache

frame-relay interface-dlci 33

!

interface Serial0.6 point-to-point

description To Washington Co., PA dlci 30

ip address 184.23.14.2 255.255.255.252

ip nat inside

no ip route-cache

no ip mroute-cache

frame-relay interface-dlci 36

!

interface Serial0.7 point-to-point

description To Westmoreland Co., PA dlci 30

ip address 187.23.14.2 255.255.255.252

ip nat inside

no ip route-cache

no ip mroute-cache

frame-relay interface-dlci 32

!

interface Serial0.8 point-to-point

description To Arm/Ind Co. dlci 30

ip address 187.23.14.5 255.255.255.252

ip nat inside

no ip route-cache

no ip mroute-cache

frame-relay interface-dlci 40

!

interface Serial1

ip address 172.17.152.26 255.255.255.128

ip nat outside

encapsulation frame-relay IETF

no ip route-cache

no ip mroute-cache

frame-relay lmi-type ansi

!

router rip

redistribute connected

network 176.16.0.0

network 180.23.0.0

network 183.23.0.0

network 184.23.0.0

network 187.23.0.0

network 189.23.0.0

distribute-list 11 in

!

ip classless

ip route 10.1.2.0 255.255.255.0 Serial0.5

ip route 10.2.2.0 255.255.255.0 Serial0.5

ip route 10.2.3.0 255.255.255.0 Serial0.5

ip route 10.9.2.0 255.255.255.0 187.23.14.1

ip route 10.250.69.0 255.255.255.0 Serial0.8

ip route 128.1.0.0 255.255.0.0 184.23.14.1

ip route 128.1.5.0 255.255.255.0 184.23.14.1

ip route 161.125.0.0 255.255.0.0 161.125.2.130

ip route 161.125.3.100 255.255.255.255 161.125.2.130

ip route 161.125.198.5 255.255.255.255 161.125.2.130

ip route 164.156.7.97 255.255.255.255 176.16.0.5

ip route 164.156.51.231 255.255.255.255 172.17.152.1

ip route 164.156.51.232 255.255.255.255 172.17.152.1

ip route 164.156.51.233 255.255.255.255 172.17.152.1

ip route 164.156.51.234 255.255.255.255 172.17.152.1

ip route 192.168.0.0 255.255.255.0 Serial0.8

ip route 192.168.1.211 255.255.255.255 192.168.255.1

ip route 192.168.50.0 255.255.255.0 187.23.14.1

ip route 192.168.222.0 255.255.255.0 Serial0.8

ip route 199.79.0.0 255.255.0.0 172.17.152.1

ip route 199.234.86.0 255.255.255.0 172.17.152.1

ip route 199.234.87.0 255.255.255.0 172.17.152.1

!

map-class frame-relay word

access-list 10 permit 192.168.82.0 0.0.0.255

access-list 11 deny 208.0.54.0 0.0.0.255

access-list 11 permit any

access-list 32 permit 10.2.2.0 0.0.0.255

access-list 33 permit 192.168.1.0 0.0.0.255

access-list 34 permit 10.9.2.0 0.0.0.255

access-list 35 permit 192.168.0.0 0.0.0.255

access-list 36 permit 192.168.50.0 0.0.0.255

access-list 50 permit 176.16.0.5

access-list 51 permit 192.168.255.250

access-list 63 permit 128.1.0.0 0.0.255.255

access-list 65 permit any

access-list 95 permit any

access-list 96 permit 176.16.1.0 0.0.0.255

access-list 98 permit 193.0.0.0 0.0.0.255

access-list 99 permit 176.16.0.0 0.0.0.255

snmp-server community public

snmp-server enable traps isdn call-information

snmp-server host 176.16.0.215

michael-faust · ‎01-24-2003

You didn't give us your configuration on the other routers, so I can't give you all the details that you may need to fix it, but I can tell you about some problems that I see.

Your software is pretty old. It may be bug free and functioning for your needs, but it may be worthwhile updating. That will not fix your problem, but consider it for a future project.

You are using a combination of RIP and static routes. There are better routing protocols available than RIP. RIP is a classful routing protocol, which limits the use of dis-contiguous subnets and variable length subnet masks. Yet, when I look at your config, I see that int s0.3 is using 161.125.2.129/32 and you say that 161.125.3.100 and 161.125.198.5 exist "on one segment of my WAN". You don't tell me the masks on those subnets but the /32 only allows two hosts - one at each end of the frame relay link. RIP will have trouble with this. Also, you are not redistributing the static routes into RIP, so the other locations are not learning of them.

I would suggest a complete change of plans. I would update the software to something more recent. I don't know your topology, so I don't know if static routes are the best choice, but given the number of locations, I would use a routing protocol and let it do it's job. I would enable OSPF, EIGRP or RIPv2. My personal choice in an all Cisco network would be EIGRP. In a mixed network I would use OSPF. I would then use private addressing on all WAN ports with a /32 mask. I would enable routing on all subnets and disable auto summary. Then I would sit back and watch it all work.

brianb68 · ‎01-24-2003

First, I would like thank you for your expert input on the problems I am having. I work for a Non-profit and this is a legacy WAN. So, any input you may have will be greatly appreciated.

Let me try to explain the WAN to you. The reason for the NAT is that the Serial1 connection only allows a certain range of ip address to access their location.

Each of the different locations have their own private LANs.

A question I have is if I change the protocol on the main 2501 will I have to change the protocols on all the other 2501s?

The configuration that follows is from one of the other 2501 and the others have the same configuration except for ip addresses.

WestMoreland#show run

Building configuration...

Current configuration:

!

version 11.3

no service password-encryption

service udp-small-servers

service tcp-small-servers

!

hostname WestMoreland

!

boot system flash 1:80240503.bin

enable secret

enable password LINE

!

ip name-server 206.101.113.2

!

interface Ethernet0

ip address 192.168.255.1 255.255.255.0

bandwidth 10000

!

interface Serial0

no ip address

encapsulation frame-relay

no fair-queue

frame-relay lmi-type ansi

!

interface Serial0.1 point-to-point

description TO BROOMALL

ip address 186.23.14.1 255.255.255.252

frame-relay interface-dlci 36

!

interface Serial0.2 point-to-point

description TO NEW CASTLE

ip address 187.23.14.1 255.255.255.252

frame-relay interface-dlci 30

!

interface Serial1

no ip address

shutdown

!

router rip

redistribute connected

network 186.23.0.0

network 187.23.0.0

network 192.168.255.0

!

ip classless

ip route 0.0.0.0 0.0.0.0 187.23.14.2

ip route 10.9.2.0 255.255.255.0 192.168.255.250

ip route 161.125.0.0 255.255.0.0 161.125.2.129

ip route 192.168.1.0 255.255.255.0 192.168.255.250

ip route 192.168.1.211 255.255.255.255 10.9.2.71

ip route 192.168.50.0 255.255.255.0 192.168.255.250

ip route 199.79.10.100 255.255.255.255 176.16.0.254

no logging console

!

line con 0

exec-timeout 0 0

password

line aux 0

password

transport input all

line vty 0 4

password

login

!

end

michael-faust · ‎01-27-2003

In a hub and spoke network there are two different ways to attack the routing. Either one will work. If the spokes only need to talk to the host, I would put a static route in each of the remotes that points to the host, and a static route in the host for each spoke. It is simple and doesn't use any bandwidth. Also, you don't have to concern yourself with things like access lists to keep traffic where it belongs.

If the spokes need to talk to eachother, and you want to use static routes, you can use a default route at each spoke site that points to the hub, and a static route for each spoke at the hub. There will be one static route at the host fro each spoke so it depends on how much control and ongoing support you want.

If you decide to make it work and not have to maintain it, use a routing protocol. See my first response for that solution. And, to answer your question: Yes - your routing protocol must be the same at all locations unless you want to get into redistribution and other ugly stuff.

I would suggest that you take some time to look at the network as it is today, consider what you want it to do, then implement a long term solution.