Multiple Ethernet addresses

[hereigns]

I've got a Cisco 1601 and have added a secondary ip address - (192.168.6.1/24). From a host in the newly added subnet I can ping the router and the router can ping the host via ethernet. The problem is I can not ping any host in the 192.168.6/24 subnet from the routers SERIAL interface. I'm stumped on why that is...? If serial0 can not pass the 192.168.6.0 subnet then no other WAN traffic can pass through.

Both Serial0 and Ethernet0 are up and up. I added the new subnet as a "secondary" ip address. Running RIP and added the 192.168.6.0 network. I can ping 192.168.6.1 from the serial interface of the router. If I do a "sh ip route" it shows the 192.168.6.0/24 is directly connected to ethernet0.
From a directly connected router I can ping 192.168.6.1 but not any host past the "problem" router. IOS version is 12.0(14).

Thanks!

 

[marsd]

This could be a problem with split horizon.
Sometimes when you define secondary interfaces they are treated differently
by distance vector based routing, RIP,IGRP, etc..
The way to deal with it is to disable split horizon.
no ip split horizon
The solution can be a pain as well, so it
needs to be tested.

HTH

 

[hereigns]

MTH,
Thanks for the quick reply...I configured the router with no split-horizon but am still having an issue with this...still banging my head on the keyboard.

 

[svermill]

Can you ping from a new host past the ethernet interface?

 

[ShaunG]

Does the 'host' you are trying to reach know how to get to the serial interface? (i.e. is the default gateway on the host correct)

 

[hereigns]

I LOVE THIS SITE...you guys/gals ROCK!

svermill,
Not surprisingly I can ping from the 192.168.6.0/24 subnet anywhere on the WAN. I tried it from a host who's ip address was 192.168.6.63 and it's default gw is set to 192.168.6.1 (router).

ShaunG,
Ummmm - Let's do this...SUBNET A = 192.168.6.0 w/ ROUTER A and SUBNET B = 192.168.8.0 w/ ROUTER B .... subnet 192.168.7.0 links the two subnets together.

So from ROUTER A I can ping anywhere using either subnet from the Ethernet interface. BUT I can not ping the 192.168.6.0 subnet via SERIAL interface (extended ping).

ROUTER B has a router table for 192.168.6.0 but it has ROUTERS A serial interface via RIP. I added a static route = 192.168.6.0/24 192.168.6.1 but it didn't work either.

 

[svermill]

Are you able to run any kind of debug to see where the echo request or reply is getting killed?

 

[hereigns]

svermill,
I already know where the packets are getting killed. It's the serial interface of ROUTER A - per extended ping command. ROUTER A can pass 192.168.6.0 okay but serial 0 can not.

 

[svermill]

I realize that you can't successfully do an extended ping from serial 0. But you apparently don't know why (nor do I). How can you be certain, without having done any debug or packet capture, whether or not the echo request from serial 0 is getting anywhere. Is it the request or the reply that's the problem?

And I'm not clear that you've tried pinging your new subnet from beyond the serial interface. Just becuase you can't do an extended ping from serial 0 doesn't *necessarily* mean that it won't work from beyond it. This could just be a silly little IOS bug or "feature." I've read more than once now that Cisco is going to discontinue support for secondary addresses (although I've not heard this from Cisco directly).

The bottom line is that it should work but doesn't. To figure out why will require that you do some digging or open a TAC case.

 

[hereigns]

svermill,
I understand your point of view and you are correct, at this point I don't know if it is the icmp request or reply that is being squashed. I'll try capturing the icmp packets and see what I get.

I thought I had answered the "pinging" question....but just in-case. From a host in subnet A I can ping beyond the router. But - from subnet B I can not ping past router A. Thanks for all of your helpful information.

 

[hereigns]

TaDahhhh....

Strangely or not so strangely enough when I came in this morning all subnets can now communicate. I did not adjust what I had previously configured so...my guess here is...the routing tables were not updated correctly when I initially tried testing the network. After all of the tables converged - all is well.

That's the only reasonable explanation I can come up with. I really do appreciate everyone's input/suggestions. Glad it all worked out...as it always magically seems to...

 

[svermill]

Yeah, sometimes I've seen situations where shuting and no shuting an interface "magically" fixed a slew of weird problems. You never know for sure, you just accept it an move on. Glad it all worked out in the end. That was an interesting one...