03-11-2009 11:25 AM - edited 03-04-2019 03:53 AM
Although I have dozens of routers running over a Sprint MPLS network, I am focused on two of them.
We use OSPF to propagate routes throughout our routers and this is working fine.
We also use Demand Dial routing (BRI lines) with floating static routes to bring a remote site up on backups should their T1 go down. This is also working fine.
My problem is, we have one particular remote location that needs more bandwidth than BRI offers.
We brought an Internet T1 into this remote location and setup a Tunnel to our main router (tunnel runs over IPSec). The Tunnel interface is up and routes traffic just fine.
The idea is MPLS would be the first choice for routing traffic, if that T1 goes down and the routes drop out of the routing table then have the routes using the GRE Tunnel float into the routing table. If that Internet T1 goes down too, then those routes drop out and the static DDR route floats into the routing table and brings up the BRI.
This is where I am stuck. I created a second OSPF process on each router to exchange routing information over the Tunnel, but the routes are not propagating. Debug IP OSPF Events shows OSPF is talking over the Tunnel but I don't see any routes.
As a test, I removed the LAN subnets from the first OSPF process (no network x.x.x.x 0.0.0.255 area 0) and then they started working through the second OSPF process.
So it appears I cannot have the same network specified in two OSPF processes.
How can I make this work?
Solved! Go to Solution.
03-11-2009 11:34 AM
Hello Denny,
it is true you cannot have the same set of network ... area commands on both OSPF processes.
This because the OSPF v2 hello doesn't contain the process-id so using same network .. area commands make the router unable to understand if a link belongs to OSPF 1 or to OSPF2
you need to configure redistribution between the two processes.
I would suggest to make the second process your edge protocol and to redistribute from OSPF 2 into OSPF1.
Towards the remote you can advertise only a default route using
router ospf 2
default-information originate always
this is to avoid to have mutual redistribution.
consider that O E1 are preferred over O E2 routes and that both are less preferred then O or O IA routes by a single OSPF process.
I wonder if it is possible in your case to deploy a single OSPF process by using artificial high OSPF costs on the GRE tunnel
and even higher costs on the ISDN DDR link.
I may be wrong but this looks like possible.
Hope to help
Giuseppe
03-11-2009 11:34 AM
Hello Denny,
it is true you cannot have the same set of network ... area commands on both OSPF processes.
This because the OSPF v2 hello doesn't contain the process-id so using same network .. area commands make the router unable to understand if a link belongs to OSPF 1 or to OSPF2
you need to configure redistribution between the two processes.
I would suggest to make the second process your edge protocol and to redistribute from OSPF 2 into OSPF1.
Towards the remote you can advertise only a default route using
router ospf 2
default-information originate always
this is to avoid to have mutual redistribution.
consider that O E1 are preferred over O E2 routes and that both are less preferred then O or O IA routes by a single OSPF process.
I wonder if it is possible in your case to deploy a single OSPF process by using artificial high OSPF costs on the GRE tunnel
and even higher costs on the ISDN DDR link.
I may be wrong but this looks like possible.
Hope to help
Giuseppe
03-11-2009 01:33 PM
I tried redistributing but that didn't seem to work. Perhaps I didn't use the correct syntax.
Your other suggestion did work. It seems there was a reason I didn't want to do this but now I can't think of what it was. I'm probably confusing this with a problem I ran into trying something similar with RIP.
Anyhow, all is well.
Thank you,
03-11-2009 11:36 AM
How about redistribution between the two OSPF processes?
PS:
Why run two OSPF processes? Couldn't you cost the tunnel so that it would only be used if the better cost (MPLS) path fails?
03-11-2009 01:18 PM
Denny,
Can you elaborate on how Sprint is provisioning this MPLS service? In other words, are you peering with their PE hence redistributing OSPF into BGP or are you neighboring via OSPF directly with the remote routers and MPLS is simply a Layer2 WAN service?
If that's the case, you can do as my colleagues recommended and increase the cost on the tunnel and use the same OSPF process that you have now.
If that's not the case, the OSPF routes coming from the MPLS won't be chosen if you have intra-area routes coming via the tunnel vs inter-area routes coming via the MPLS connection.
__
Edison.
03-11-2009 01:42 PM
My terminology isn't all that up to snuff, so I hope I am answering this correctly. I believe I am neighboring with Sprint.
I run OSPF between my routers and them. I do know they are redistributing the OSPF into BGP to run across their backbone, then BGP back into OSPF.
I hope that makes sense.
Denny
03-11-2009 01:46 PM
Be aware the intra-area vs inter-area OSPF routing decision.
All routes coming from the MPLS network will be inter-area or external routes (the nature of the MPLS redistribution process) while routes coming via the tunnel may be in the form of intra-area route.
Without a full network assessment, I find it hard to determine if you are going to be affected by this or not..
__
Edison.
03-11-2009 01:54 PM
Hi Edison,
Thank you for your input on this.
When I responded to the individual higher up, it did work in my lab environment, but my lab isn't mimicing the MPLS part. So, redistribution isn't happening.
I just checked the routing table of the production router and you are correct, these show as inter-area routes. So perhaps my problem isn't solved.
Denny
03-11-2009 02:07 PM
Hi Denny,
Far from being solved :)
You can do the following:
1) Configure the T1 links under another area within the same OSPF process
2) Perform summarization between areas.
With this approach, the MPLS routes will be more specific than the T1 routes regardless of the interface cost or the O | IA status.
HTH,
__
Edison.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: