[c-nsp] OSPF design question

E.T.Metz at telecom.tno.nl E.T.Metz at telecom.tno.nl
Thu Jun 30 05:36:38 EDT 2005


I think this problem could be solved with the proper settings of
metrics, admistrative distances etc. But this requires possibly a bit
more detail on the exact situation.

An alternative, and variant to the solutions you described below would
be to interconnect the OSPF domains through a separate OSPF process on
the interconnects only, e.g. 111, instead of extending one of the
current domains across the links. Over the inter-connects you could then
advertise a single, special loopback (instead of all routes from the
areas), and on both ends point a static to that loopback. Of course you
could also do redistribution on both sides of the interconnect.

Hope this helps.

cheers,
	Eduard

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of 
> Justin M. Streiner
> Sent: dinsdag 28 juni 2005 22:11
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] OSPF design question
> 
> I have a pair of interconnections between two networks running OSPF, 
> though I'm only running on one at the moment.  The rough 
> layout looks like 
> this:
> 
> backbone_router_A <---network backbone---> backbone_router_B
>  	|					|
> layer 2 firewall			layer 2 firewall
>  	|					|
> backend_router_A <---separate backbone---> backend_router_B
> 
> The backbone uses OSPF process ID 100 and the back-end 
> network uses OSPF 
> process ID 101, each with their own backbone area.  The 
> back-end routers 
> handle the redistribution of routes between the two OSPF 
> processes.  The 
> interconnect networks are their own appropriately numbered 
> areas connected 
> to area 0 on the backbone network.  All of the routers are Ciscos.
> 
> The links need to operate in an active-passive mode because of the 
> firewalls that sit between the networks.  Traffic that exits 
> the back-end 
> network via one interconnect and tries to return via the 
> other will break 
> because the second firewall has no session cache entry built 
> for it and 
> drops the packets.
> 
> Under many circumstances, this could be accomplished by 
> making the OSPF 
> link cost on both sides of one of the interconnects higher 
> than the other.
> When I tried that, the costs were not being honored correctly, so I 
> couldn't guarantee route symmetry in both directions at the 
> interconnect 
> points.  I'm trying to remember my OSPF preference flowchart 
> from several 
> years ago, but I seem to recall metrics/costs not being preserved in 
> certain cisrumstances, and maybe I'm getting bitten by this.
> 
> I can't use weighted static routes to accomplish this because 
> of the layer 
> 2 firewalls sitting 'in the middle' of each interconnecting 
> link.  If one 
> side of those interconnecting links (a segment between one of the 
> routers and the layer 2 firewall) drops, the router on the 
> other side of 
> that interconnect would happily continue to route packets 
> down a half-dead 
> segment, since its layer 3 interface would still be up.  This 
> requires a 
> protocol with keepalive or timer-expiration capabilities.
> 
> The way I see it, my options are:
> 1) isolate the two OSPF instances from each other, using BGP
> 2) fold all of the back-end network into a non-backbone area in OSPF
>  	process 100, getting rid of 101 entirely
> 3) possibly use OSPF virtual-links
> 4) do static routes over a keepalive-based transport such as 
> a GRE tunnel.
>  	This would necessitate rule changes on the firewall and 
> MTU issues
>  	would need to be taken into account
> 
> Am I missing anything?  To people who have done designs like 
> this before, 
> what approach did you use?
> 
> jms
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 



More information about the cisco-nsp mailing list