Local connected IP vs. OSPF

[jogreco]

We ran into a problem the other day where we added an IP Address to an ethernet interface on a 2620, brought the interface up, but could not ping that address space. we did not add a network statement under ospf so the segment would stay local to the site. IP Address used was 192.168.0.0/19.

Portions of this address space are being used elsewhere on our network. But since we didn't add the network under OSPF on the 2620 shouldn't we be able to get to that segment locally?

When we do a show ip route 192.168.0.0 the only entry shown in over the WAN link to where the IP address is used elsewhere on our network.

[Georg Pauwen]

Hello,

even if the address space were advertised by OSPF, you should still be able to ping the address locally, since it would show up as a connected route, which always has a lower administrative than any routing protocol. Was the Ethernet interface up/up ? And were you pinging from the local router, that is, the router where the Ethernet interface was configure ?

Regards,

GP

[jogreco]

The interface was in an up/up state, but we were not able to ping from the address from local router.

The only way we could see this connected route is by doing a show ip route connected, or sho ip route 192.168.0.0 longer-prefix. either command did show the address with lower admin cost.

If we did clear ip route we did see the segment locally connected, breifly, with just show ip route, but when the route table rebuilt it showed the segment on the wan link again.

[Richard Burts]

I believe it would be helpful to have some more specifics, particularly how the local interface is configured. With the interface configured with some address in 192.168.0.0/19 we are dealing with supernet routes. It becomes important to understand whether the router is configured with ip classless (important to have this if you want the interface to work) or configured with no ip classless.

The original post also indicated that some parts of this supernet are in use in the network other places, so there will be a situation where the local routing table knows about the supernet route and also knows about more specific routes from other parts of the network. If the interface address should happen to fall within the range of one of those other routes then when the router picks the more specific reference it would not route to the local interface.

Essentially what they have created is overlapping address spaces. And that can be tricky to deal with.

So can we get more specifics about how this router is configured?

HTH

Rick

[jogreco]

We do have IP Classless turned on. The users behind this router do not need to get to the OSPF 192.168 address space, so there would be an issue there.

Here is a copy of the config:

!

version 12.3

service timestamps debug datetime msec

service timestamps log datetime localtime

service password-encryption

!

hostname WanDE1

!

boot-start-marker

boot-end-marker

!

enable password 7 xxxxxxxxxxx

!

clock timezone Central -6

clock summer-time CDT recurring

aaa new-model

!

!

ip subnet-zero

!

!

!

ip audit notify log

ip audit po max-events 100

appletalk routing

ipx routing 0000.0c38.850b

no ftp-server write-enable

!

!

!

!

!

!

!

!

!

no voice hpi capture buffer

no voice hpi capture destination

!

!

!

!

!

!

interface Loopback0

ip address 10.176.254.70 255.255.255.252

!

interface FastEthernet0/0

description Decorah

ip address 10.176.229.1 255.255.255.192 secondary

ip address 172.21.209.1 255.255.255.0

ip helper-address 10.176.171.232

ip helper-address 10.176.171.233

no ip unreachables

speed 100

half-duplex

appletalk cable-range 2230-2232 2230.67

appletalk zone Decorah

!

interface Serial0/0

description Decorah

ip address 10.176.180.58 255.255.255.252

ip accounting output-packets

appletalk cable-range 10031-10031 10031.154

appletalk zone Wan

no fair-queue

!

interface FastEthernet0/1

ip address 192.168.1.99 255.255.224.0

duplex auto

speed auto

!

interface Serial0/1

description 2nd.T1 to Rochester (1/4)

bandwidth 384

ip address 10.176.180.202 255.255.255.252

!

router ospf 1

log-adjacency-changes

network 10.176.0.0 0.0.255.255 area 0.0.0.200

network 172.21.209.0 0.0.0.255 area 0.0.0.200

!

no ip http server

ip classless

!

!

!

!

!

!

!

!

!

!

!

!

line con 0

password 7 xxxxxxxxxxxx

line aux 0

password 7 xxxxxxxxxxxx

transport input all

line vty 0 4

password 7 xxxxxxxxxxxx

!

!

!

end

[Richard Burts]

Having the router config is helpful. Could you also post the output of show ip route on this router?

HTH

Rick

[jogreco]

Here's the show ip route command from the router:

WanDE1#sh ip route 192.168.0.0

Routing entry for 192.168.0.0/24

Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 131

Last update from 129.176.180.57 on Serial0/0, 00:00:43 ago

Routing Descriptor Blocks:

* 129.176.180.57, from 129.176.254.186, 00:00:43 ago, via Serial0/0

Route metric is 20, traffic share count is 1

As you can see, there is no reference for the direct connect segment.

[Richard Burts]

Thanks for posting this, but it is not enough. As you notice when you do show ip route 192.168.0.0 it will assume that you mean the classful network and will display only the /24.

It is interesting to note that the 192.168.0.0/24 does exist somewhere else in the OSPF network. As I suggested in my previous post if 192.168.1.0/24 also exists somewhere in the network, it would explain why you are not seeing or accessing the local network, because there is a more specific reference to that address space. (If the router sees 192.168.0.0/19 and sees 192.168.1.0/24 it will route to the /24 not to the local interface.)

So the suggestion by Kevin to post the output of show ip route | include 192.168 is an excellent suggestion which should show us what we need.

HTH

Rick

[Kevin Dorrell]

Could you post all the relevant lines from a show ip route?

I suspect that what is happening is this: you have 192.168.0.0/19 on your Ethernet as a connected route. However, OSPF is learning more specific networks or subnets, maybe even the 192.168.0.0/24 network. Since the first choice is the more specific route, a route to 192.168.0.0/24 would take precedence even over a locally connected route, at least as far as the 192.168.0.0/24 network was concerned.

Not too sure what happens when you have 192.168.0.0/19 directly connected and 192.168.0.0/24 learned from OSPF. Definitely the OSPF would take priority for 192.168.0.0/24, but I'm not sure what would happen to 192.168.1.0/24, 192.168.2.0/24 etc. up to 192.168.31.0/24.

So, could you post your show ip route | include 192.168 please?

Kevin Dorrell

Luxembourg