7206, Bay Networks router not speaking to each other

[pixboy]

This is just driving me nuts trying to figure this out. Hopefully, someone here has an idea of where to look.

We have a Cisco 7206 router with two FastEthernet interfaces, and a 4-port T1 card. (It also has a T3 interface, but that's down and no longer used.) Our two T1s used to be on a 2600 router, but we moved them to the 7200 to speed things up and make management easier.

FastEthernet0/0 goes into our Pix 520. FastEthernet2/0 goes into the general network. We have four Class C blocks.

Here's the problem ... There is a Bay Networks router on the network which belongs to another provider. (It provides VPN connectivity to a client of ours.) For some very strange reason, the 7206 cannot ping or otherwise communicate with the Bay router. The 7206 has addresses in all four IP blocks, so it should be local to the Bay router no matter what. Workstations in the same IP block as the Bay router can ping it no problem. The 2600 router is able to talk to the Bay router no problem. (The 2600 has addresses in two of the four IP blocks, including the one where the Bay router lives. This is really only because we need to keep the Bay router accessible. Once we figure this problem out, the 2600 goes back offline.)

Doing a sh arp on the 7206 shows the proper MAC address for the Bay router, so there's obiously some communication somewhere. And we've cleared the arp tables on the 7206 several times, and the Bay's MAC keeps coming back. Yet the 7206 can't talk to the Bay.

I've tried a number of things to solve this, but nothing seems to work. Any ideas????

 

[marsd]

Besides posting your routing table, and telling us any dynamic routing protos you are using: since the problem is pretty obviously a routing problem. No.

 

[pixboy]

Here's the routing table from the 7206 (with the middle octets changed to protect the innocent):

sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR, P - periodic downloaded static route
T - traffic engineered route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

208.aaa.bbb.0/24 is variably subnetted, 5 subnets, 2 masks
S 208.aaa.bbb.161/32 is directly connected, FastEthernet0/0
S 208.aaa.bbb.197/32 is directly connected, FastEthernet0/0
S 208.aaa.bbb.17/32 is directly connected, FastEthernet0/0
C 208.aaa.bbb.0/24 is directly connected, FastEthernet2/0
S 208.aaa.bbb.101/32 is directly connected, FastEthernet0/0
157.mmm.0.0/30 is subnetted, 2 subnets
C 157.mmm.nnn.184 is directly connected, Serial3/1:0.1
C 157.mmm.nnn.188 is directly connected, Serial3/0:0.1
S 220.iii.jjj.0/24 [1/0] via 204.ggg.hhh.1
10.0.0.0/24 is subnetted, 3 subnets
S 10.27.24.0 [1/0] via 204.ggg.hhh.1
C 10.1.1.0 is directly connected, FastEthernet2/0
S 10.25.2.0 [1/0] via 204.ggg.hhh.1
63.0.0.0/24 is subnetted, 1 subnets
C 63.ccc.ddd.0 is directly connected, FastEthernet2/0
S 192.kkk.lll.0/24 [1/0] via 204.ggg.hhh.1
208.eee.fff.0/25 is subnetted, 2 subnets
C 208.eee.fff.0 is directly connected, FastEthernet0/0
C 208.eee.fff.128 is directly connected, FastEthernet0/0
204.ggg.hhh.0/24 is variably subnetted, 2 subnets, 2 masks
C 204.ggg.hhh.0/24 is directly connected, FastEthernet2/0
S 204.ggg.hhh.2/32 [1/0] via 204.ggg.hhh.1
S* 0.0.0.0/0 is directly connected, Serial3/1:0.1
is directly connected, Serial3/0:0.1


The routing that goes to 204.ggg.hhh.1 is simply to get it to the 2600 router. That's performing Ethernet-only routing now for the 204.ggg.hhh.0/24 and 208.aaa.bbb.0/24 blocks. That's only so some of those machines in those blocks can get to the 204.ggg.hhh.2 router, which is the Bay router in question.

 

[marsd]

Ah, static routes,arrgh.
Nothing jumps at me after a quick look.

Maybe one of the other guys can pick something out.

It may be an acl problem. Try a traceroute to the bay
from various 7206 connected subnets and extended pings from other interface addresses if you haven't already tried this. Then start debugging your traffic.
That's all I can think of right now, sorry.

 

[pixboy]

I tried a few things, including extended pings and traceroutes. If you try and trace from the 7206 to the Bay router, you at least get to the 2600 router. If you're coming from the 204.ggg.hhh.3 interface or the 208.aaa.bbb.2 interface of the 7206, you get to the Bay router (which is 204.ggg.hhh.2). If you try and do it from the 208.eee.fff.1 or 63.ccc.ddd.1 interface of the 7206, you get nowhere.

I checked the ACLs on both the 7206 and the 2600, but nothing stands out. Right now, there are access-lists on the 2600, but none is bound to the Ethernet interface, which is the only one up.

Very strange!

 

[pixboy]

I've also tried to debug the problem by setting up a syslog host for both the 7206 and 2600 routers.

From the 2600:

sh logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 60 messages logged
Monitor logging: level debugging, 0 messages logged
Trap logging: level debugging, 58 message lines logged
Logging to 208.aaa.bbb.xxx, 1 message lines logged
Buffer logging: disabled

From the 7206:

sh logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 40 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 40 messages logged
Trap logging: level debugging, 44 message lines logged
Logging to 208.aaa.bbb.xxx, 1 message lines logged

Log Buffer (8192 bytes):

(...)

Neither one has done much in the way of logging, other than that the router was configured by a particular connection.

I changed the access-list 10 on the 2600 to log things, too, but nothing so far.

Anything obvious I'm doing wrong here?

Thanks!!

 

[scraig84]

Just out of curiosity, why do you keep focusing on the routing of the 7206? If it can get there from some interfaces, it can get there from all interfaces (unless source based routing is implemented which changes the whole story). However, if your pings aren't working from certain interfaces (or certain networks), then one of the devices in the path can't make it back. Therefore, do the 2600 and the Bay have routes for the 208.eee.fff.0 and 63.ccc.ddd.0 networks?

Also, sort of aside from the issue - why do you route through the 2600 to get to the Bay if they are on the same IP subnet?

 

[pixboy]

How can I check to see if source-based routing is in use?

The overall idea was to remove the 2600 completely from service. (It only has a 10Mb/s Ethernet interface in addition to its two T-1 interfaces, so the 7206 and its Fast Ethernet interfaces is a huge improvement on our network.) However, when we did this, the hosts that needed to reach the Bay router couldn't get there. That's when we discovered the problem with the 7206 communicating with it. The routing through the 2600 was an attempt to get it work.

It seems that the 2600 can ping (extended, too) any interface that the 7206 has, which is all the more frustrating.

 

[scraig84]

Sounds like the Bay is pointing to the 2600's IP address for those particular networks rather than to the 7206's. Have you checked the route table on the Bay to ensure it is correct? It should be pointing to the 7206's Ip address on f2/0 for the networks that are in trouble.

Source based routing is fairly rare. It's also referred to as policy-based routing. Any route-map commands with match and set commands beneath it? If so, then you are doing some type of policy based routing. Like I said though, its rare.

 

[pixboy]

Of course, after I posted, I looked up policy based routing. We don't use it. (That's one variable out of the loop ...)

We don't own the Bay router, and don't have any access to it, so I don't know what its routing table looks like. I suspect it would be looking at 204.ggg.hhh.1. When we first shut down the 2600, we added that address to the 7206's FE2/0 interface. That didn't seem to work, so we reverted.

 

[scraig84]

It may be that when you pulled the 2600 and added the address to the 7206 (secondary address I assume) that the Bay needed to have its arp cache cleared. You may want to try again if you can get the owner to wipe the arp cache (or tell them to reboot it if that's a possibility).

 

[pixboy]

I know we've rebooted the Bay router (by unplugging it) since this all started. The more we talk about this, the more it seems that the Bay router probably has an access list in it that's preventing this from working. I'll push them to either give us access to it or at least send us the configuration so we can figure it out.

 

[chadstanphill]

Make sure on the Bay side that the MTU (1506) and the MRU (1600) are default. Cisco should be at (1500) Make sure the BOFL is disabled. Getting Bay to talk to Cisco can really be a pain in the a$$. Tell them to ditch the Bay..jk

 

[chadstanphill]

One more thing shut the Keepalive off on the Cisco side.