OSPF & secondary IP

[gmail2]

Hi all

We're curently splitting up our flat network into multiple subnets. We created some VLAN's on our layer 3 switches (3750's) which distribute routes to other 3750's at another site over the WAN. Our routing protocol for this is OSPF

Once we created our VLAN's, and the interfaces came up, and all but one of the routes were distributed. The route that was not re-distributed was for our management network. The VLAN interface for this network has a secondary IP, but both IP's are on the same subnet:

IP Address 192.160.50.1
Secondary 192.168.50.51

The reason is .1 is intended to be for routing and .51 is intended to be for management of the switch from the management network. Although we could just use .1 for the management, we want to use .51 for historical reasons to keep our management standard.

We removed the secondary IP address on the VLAN interface, and the routes got distributed just fine. Then we re-added the secondary IP, and to our surprise the route was still distributed !

Next, we brought down the interface, confirmed the route was not distributed, brought the VLAN interface up again ... and once again to our surprise, the route was re-distributed !!

Everything I've searched for so far referring to OSPF and secondary IP's just refers to having a secondary IP within a different subnet. And the guidelines on the Cisco website for using secondary IP's and OSPF just says to ensure that the subnet of the secondary IP's is included in the network list to be re-distributed ... which obviously it is.

The firmware version on all of the switches is 12.2. Does anybody have any ideas if this is just a bug/known issue, of why it is that the route never got distributed initially until the secondary IP was removed ?

thanks in advance !

Irish Poetry - Karen O'Connor
Irish Poetry and Short Stories - Doghouse Books
Garten und Landschaftsbau

 

[burtsbees]

I had a similar situation once, but more complex, but had secondary IP addresses etc. The customer could not telnet over the WAN using certain IP addresses, but could in the LAN. This was all a subnetted 10 dot network, using OSPF area 0.0.0.4

The fix was no ip classless, I think, or some similar default command...

Since the routes were already distributed, to truly test what was going on, you'd have to clear all the 3750 route tables and then bring the vlan interfaces down/up.

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[PeterHurst]

Interesting - one of my vlans has the same sort of programming but wasn't aware it cause a problem when I added it, network seemed to advertise fine, could be the way I did it or could be firmware levels.

burtsbees - not sure on the no ip classeless but that's probably more to do with having a 10.x.x.x address, I'd have guessed the command you use was ip classless which makes the routel use the masks you set and not "natual masks" 10.x.x.x would have a natural class A 255.0.0.0

 

[burtsbees]

Peter---no---it made absolutely no sense to me. I posted it a while back...the fix was actually adding "ip classless", which would make sense if you could not ping or route correctly in that situation---however, routing was taking place the way it was supposed to, and pings to and from the certain address would succeed, but not telnet!

http://www.tek-tips.com/viewthread.cfm?qid=1572124&page=1

a star and a quarter if you figure it out! Pings and routing all were good, but no telnet, until ip classless was put in. It's a good read and a great challenge, I think. I never gave it any more thought shortly after I posted, but now that work is slow, I may lab this up and experiment and try and figure something out. Another thing that's in that config is the use of OSPF area 0.0.0.4---never saw that one...

Have fun with this one! I did!

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[PeterHurst]

burtsbees - thanks (!)

I had a quick browse and the only think that strikes me is that if the IP is classfull then the router will assume 10.x.x.x is /8 by definition - therefore perhaps the telnet service only attaches to one of the interfaces in the 10 and ignores the rest. Now I can't test that easily and have never seen it but it's a thought (why bind telnet to all the interfaces as it wastes resources??). That theory doesn't explain telnet on the other 10.x interfaces which I assume did work fine.

I think (I'm an OSPF newbie) that the routes would appear the same because of summarization - if there were devices multiple hops away then the classfull/classless may have caused routing issues. If all the 10.x.x.x addresses wer on that router the ad would be the same and as the router had direct routes to all the networks it may well have worked.

The other comment would be that with the config as I read it IP classless should be there anyway as you are using variable subnets so we're looking at a slightly errored config causing an issue.

 

[burtsbees]

I agree "ip classless" should have been there from jump street---I put it there for that reason! That's when telnet started to work, after I tried everything else! Routing was never an issue, obviously, with pings tracing the same paths, before and after routing tables were cleared before and after changes were made. Believe me---when a customer has a problem like this in an edge router, they don't want it turned off! Since the customer had a work-around (telnet into an inside device, then telnet to the edge switch), they justified not having the router cycled too many times. This was a very grueling task because of all these factors. Now how can telnet services route THROUGH the router to a destination, then back to a certain point, but not to that certain point to begin with? Especially when all packets were still being routed correctly, and that did NOT change with the addition of "ip classless"?

The customer has several config items that baffled me---they use a TACACS+ server, but allow telnet? They use access-class 23 for http and vty, but no access-list 23? Actually, SDM does this with "one step lock-down"---it does this but fails to create the acl! Also, the customer has access to http on an edge router...not good...as well as CDP and telnet on the edge...b-a-a-a-a-d. Also, notice all of the secondary addresses on the interfaces, as well as a non-existent MLPPP config, on a single interface. They did not want us to clean the config up, just solve the telnet problem. That was difficult WITHOUT cleaning the config up!

Anyway, a good challenge none-the-less...

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[PeterHurst]

Indeed - if I can I'll try it sometime... I understand about the customer issues, been there got the tee-shirt.