I'm going crazy trying to figure this out. Please refer to the pdf in the attachment below (it is small 55Kb).
Basically we have two networks subnet x and subnet y which are internally running OSPF each. We are not exchanging OSPF routes across the subnets for fear it might overwhelm the L3 switch in subnet Y and and have instead opted to configure a static route in the routers in subnet X going into subnet Y and default routes in subnet Y going into subnet X.
The below setup works, however, without going into specifics, there is a requirement in our setup to have the static ip routes going into subnet y configured on the L3 switch in subnet X in such a way that they are "removed" from the routing table if the next hop is unreachable.
Since this is not a straight up L3 P2P or a traditional P2P over serial, when the next hop goes down (in this case IPs 192.168.1.10 and .14), the L3 switch in subnet X is oblivious to the next hop going down since the vlan interface is kept alive due to active member ports in the L2 switch in the middle. Thus the route is never removed from the routing table.
I've tried using object interface tracking with the IP route reachability option but that again works off IP prefixes and as we have established, the route is never removed from the routing table, so the tracked object is always up.
So I guess, my question here is (deep breath), short of extending a direct L3 connetion between the two L3 devices in subnets X and Y thereby circumventing the L2 switch in between, is it possible to make stateful static routes in the given scenario ??
Appreciate any help with the above...
there is a feature called
reliable static routing with object tracking that allows to track ip reachability of the next-hop
However, I don't know if it is supported on your platforms.
if the only reason for not extending OSPF between the networks is the fear of loading you may use different OSPF areas and route summarization to achieve dynamic routing with low overhead
if the two networks are under different administrations the usage of static routes or of a BGP session can be considered.
Hope to help
Giuseppe beat me to the link!
The command syntax is very IOS specific, so if you need help setting it up, just post us your IOS, and as Giuseppe mentioned, its not supported at all on some platforms.
Otherwise the GRE tunnel would also be a good solution.
I might have misunderstood him Giuseppe, but even if he created 2 areas, his router would still be an ABR for both area's, and would still have all of the LSA types 1 and 2 in it's database for both areas. Summarized routes only get passed to non-ABR routers, and I'm not implying that an ABR will never recieve a summary route :)
Hi thanks for the reply.
Funny thing is I was using object interface tracking to track the ip prefix of either subnet y or the /30 P2P link subnets ... which as i mentioned will never really be taken out of the routing table.
I read through the stuff. Looks solid. Can't wait to try it at work tomorrow!
And the thing about OSPF is:
1) They are in fact under different administrations and we frankly don't know or perhaps don't want to know what they are configuring in their network.
2) If I create a seperate OSPF area, I would have to use virtual links to achieve backbone connectivity to area 0. Since this is kinda like a permanent setup I wanna try and avoid using virtual links as much as possible ... unless absolutely necessary ...
I always prefer dynamic routing over static routes, but that is my preference. Static routes are more succeptable to routing loops and errors, and administrative overhead. But that is my preference / experience with them, just like cars, not everyone likes a ford...
I couldn't agree with you more. However there are plenty of scenarios in which you can't help but use static routes. For instance lots of companies manage firewalls and prefer not to run dynamic routing protocols on these devices, choosing instead to have people use static routes into their F/W interfaces.
Another instance would be where having a dynamic routing protocol would be overkill or perhaps running it could potentially overwhelm the router in the smaller network.
I just realized my diagram mentioned that subnet X was 10.30.0.0/16. It is actually a 10.0.0.0/8 subnet with 10.20.0.0/16 allocated for use by subnet Y. The number of subnets we have are in the thousands and the number of areas are a few dozen.
I guess we could define their subnet as a Totally Stubby Area thereby all but virtually eliminating anything non LSA 1 and 2 ... i'm keeping this as my final option ... if nothing else works ...
Thanks for your invaluable input. Pls dont hesitate to post if anything else should come to mind.
Another approach would be to run OSPF between the three L3 switches, but using a different OSFP process then currently used for the internal OSPF domains. This then would allow you to control what the other side "sees" without having to pass/mix the two OSPF domains, and provide reachability availability via OSPF neighbor hellos. (Such an approach can, of course, be done using a different routing protocol, but if you're comfortable with OSPF and/or want to avoid routing redistribution conversion issues between routing protocols, and avoid using special OSPF areas, this might work well for you.)
Try setting up a GRE tunnel, and monitor the tunnel. If any segment along the way goes down, the tunnel drops and you can alarm on it.
You don't have to pass anything in the tunnel, it can simply be used as an indicator.
If you have a monitoring / management solution, you can watch for traps. The GRE tunnel is treated like any other interface. The advantage to it's use it that it spans across all segments, regardless of the type or speed. If any chunk of the span drops, the tunnel drops (the router thinks an interface has dropped).
All you need for the GRE is for both ends to be able to see each other.
Sorry no NMS here. We are in the finalization stages of selecting one.
I had an idea. I can enable keepalives for the GRE tunnel and as soon as one of the ends fail, the return GRE packets won't be received and the interface will be brought down.
I can configure object interface tracking to install the static routes ONLY if the Tunnel interface is UP. So when the Tunnel goes down, it stands to reason that the static route will be removed and we will use the next available route to subnet y (whether it is a floating static or a summarized route entry for the major subnet)...
Can't wait to try it tomorrow. I'll keep this thread updated.
I imagine it would look something like this:
int tunnel 1
ip address 126.96.36.199 255.255.255.0
tunnel source 192.168.1.9
tunnel destination 192.168.1.10
int tunnel 2
ip address 188.8.131.52 255.255.255.0
tunnel source 192.168.1.13
tunnel destination 192.168.1.14
track 1 interface tunnel 1 line-protocol
ip route 0.0.0.0 0.0.0.0 192.168.1.9 track 1
track 2 interface tunnel 2 line-protocol
ip route 0.0.0.0 0.0.0.0 192.168.1.9 track 2
int tunnel 1
ip address 184.108.40.206 255.255.255.0
tunnel source 192.168.1.10
tunnel destination 192.168.1.9
int tunnel 1
ip address 220.127.116.11 255.255.255.0
tunnel source 192.168.1.14
tunnel destination 192.168.1.13
This would remove the static route if the line protocol of the tunnel dropped.
ip sla monitor 1
type echo protocol ip ipicmpecho 192.168.1.10
ip sla monito schedule 1 start now life forever age 5
track 1 rtr 1 reachability
ip route 0.0.0.0 0.0.0.0 192.168.1.10
ip sla monitor 2
tyep echo protocol ip ipicmp 192.168.1.14
ip sla mon sched 2 start not life forev age 5
track 2 rtr 2 reach
ip route 0.0.0.0 0.0.0.0 192.168.1.14