My problem: Too many routes on the routing tables in all routers. They are adding one route for each tunnel for each branch office that I have OSPF in. I saw some articles about summarization of routes here and that by adding more areas.
My doubt is if I would have problems in summarization, once my destination network will be always the same, no matter the path.
I have the following scenario and I would like to know another opinion for the best setup.
2 RB’s 1100AH at my HQ. One for PPTP tunnels and another for the EoIP tunnels. They talk through vlan11.
The EoIP tunnel is made through my MPLs topology, delivered by my ISP. Without it, i couldn’t make adjacencies with OSPF.
The PPTP tunnel is made throught internet link, delivered by another ISP, for redundancy.
RB 2011 at the branch office, with both tunnels running.
I have the following OSPF setup. This example is for one of the branch offices.
So is this just a typical setup? As in are other branch offices just like the one mentioned here? The only way you can summarize things is if its a stub are or via some kind of choke point (area to area). So to do this it takes some IP address planning. Things like keeping all IP address ranges at each branch office setup in ranges that can be summarized. Unfortunately point to point links will always show up as individual links inside the same area. If you had a larger network where you could break it into two areas and your PtP links could be summarized where the two areas join then you could complete this.
You have duplicate router IDs on Router 2 and Router 3.
Curiosity question about your EoIP link via the MPLS. Is this MPLS service provided by a carrier/service provider? Is it a point to point type circuit or a L3 VPN service between your hub site and remote offices? If its a point to point VPLS style circuit there is no need to run EoIP on top to get OSPF to work.
Yes, there is another 4 branch offices running like that. And besides that, we are changing our topology to be this way on other ~50 branch offices.
I’ve been looking on the internet about some guys saying that, about having 2 areas, for example. My though is one area for my PPTP tunnels and another for my EoIP tunnels. So that I could summarize at least the middle networks, like 172.20.0.0 and 10.1.0.0.
I think if I would not have problems with the destination network (in the example, 10.25.35.0). I don’t know where I would put the announce for that network. In both routers?
The ideal world would be the branch router with the default route (that my HQ router already gives) and a 10.25.0.0/16 route, that is the summarized network for all my branch offices plus HQ. We are a HQ with 10.25.0.0/23 and other offices with 10.25.x.0/24.
I could do that with a filter, but I think that is not the better form, because the routers would keep announcing the routes.
Yes, typing mistake.
My MPLS link is provided by a carrier/service provider. They call it a VPN, but it is not actually a PtP connection. In some branch offices, I pass over 3 hopes before reaching my router. Besides that, I wouldn’t like to ask them for a OSPF instance through their router, because we would be depending on them for each change on topology.
It sounds like you have an MPLS L3VPN from the carrier
What routing protocol is the carrier using to hand off the MPLS connection? If it is BGP, you might consider using BGP end to end for 50 sites and simplify your routing.
From a design standpoint, you don’t want all OSPF routers in the same area for two reasons:
1 You need an area border router to summarize
2. The SPF algorithm runs within an area but not across - you don’t want flaps at the edge to cause multiple SPF recalculations in Area 0 at the core.
What I know, by peaking some configs during one maitenance, is that they are using only static routes on the branch offices. Just default route to the HQ router, that problably must have one static route for each branch office. Perhaps they have a dynamic routing protocol, but just for their use. And I don’t believe that they’d give us a routing instance throug their routers.
Your tip is to use one area for each tunnel router? R1 and PPTP tunnels on area0 and R2+EoIp tunnels in area 1?
Is the primary concern that there are too many routes on the branch RB2011s? I would have thought that the RB1100s can easily cope with the number of routes they would be seeing.
Stub areas may help to reduce the number of routes on the branch routers, but the scale of the reduction will depend on the IP numbering scheme and opportunities to summarize. To get the number of routes on the branch offices down you most likely want to not flood summary LSAs to the branch routers (totally stubby in Cisco parlance). Whether you use stub or NSSA depends on the routing arrangement at the branch offices.
Creating an area for every branch could become burdensome. If the branches have a simple network layout you could possibly consider running RIP2 at the branches and simply redistributing RIP into OSPF at the branch router. That would maintain the fast convergence of OSPF on the WAN links (in Area 0) while simplifying the workload on the branch routers.
Unfortunately EIGRP isn’t an option - it would work well with fast convergence in this situation.
My primary concern is the best way to mantain an available infrastructure without the need of a manual intervention. That was our primary though when changing to a dynamic routing protocol, not changing static routes at any link down event.
For an example, we have today 6 branch offices in this new topology. Following is the routing table of one of the 2011 branch routers.
Can you imagine it with 50 branch offices? Will the 2011 handle it well?
Creating an area for every branch could become burdensome. If the branches have a > simple > network layout you could possibly consider running RIP2 at the branches and simply redistributing RIP into OSPF at the branch router. That would maintain the fast convergence of OSPF on the WAN links (in Area 0) while simplifying the workload on the branch routers.
I was thinking in make an area for R1 and its PPTP tunnels and another area for R2 and its EoIP tunnels. Could I make the branchs just see the summarized route to 10.25.0.0/16? They would see 1 throug R1 and in case of problem, for example, thry would switch to R2.
The 1100AHx2 routers have been used to take two full BGP feeds, so you aren’t going to come close to exhausting the routing table in them. We have used the 2011 routers as MPLS PE routers in large wireline carrier networks and put several hundred routes in them with no performance issues. In fact they could probably handle over a thousand with no problem.
I would probably segment this network into 3 areas and use OSPF as the routing protocol if you aren’t familiar with BGP
Area 0 - Network Core - both of your 1100 routers
Area 1 - PPTP Tunnels
Area 2 - EOIP Tunnels
This will cut your routing tables significantly if you decide that you need it, and you can also enable stub areas to really reduce the workload. If there is only one path out of a network, then a default is really all you need.
The other benefit is that you will protect the core from SPF flaps a little better by segmenting into several areas.
There are many different ways you can go with this, but always try to keep the network as simple as you can and still accomplish the objective. we work in extremely large environments and simplicity really does contribute to stability.
Hmm, i fi read right and understood correctly I would break up
any wan link as area 0, so ptp and eoip.
a new area for each office.
this is how I have mine setup, 1 office and 2 dc. but I have a broadcast domain shared by all sites.
I also use summarisable addressing
so say for office 1 I might allocate
10.1.0.0/16 and then break that down into /24’s. bit of an over kill but, you know any 10.1 address belongs to office 1 and 10.2/16 to office 2 etc etc.
so office 1 would have
address from 10.1.0.0/16
10.1.0.0/24
10.1.1.0/24
it would have OSPF areaid 10.1.0.0, and a summary range of 10.1.0.0/16
so all you should outside of office 1 is 10.1.0.0/16
Are the branches given local internet access or does that traffic also flow via head office?
The 2011s could handle the routing rules but it looks as if there is no need to have all that routing traffic and potential route flapping - there are better alternative configs.
The 2011s seem to be the devices which would benefit most from a reduction in routes/routing load. Creating separate areas for the EoIP links and PPTP links is all very well as regards summarisation being possible between the 1100s - but what about the 2011s? Are they going to now be in both areas? … and acting as ASBRs into both too? I see no config or workload reduction there!
The config used by AlexS certainly allows full summarisation to the 2011s or even replacement of summary routes by defaults on the 2011s.
The primary concern is the workload and organization. As you guys said, the 2011 is strong, and I don’t need to have preoccupations about that.
What I understood from IPArchitect is if I do that setup, I wil receive in the 2011’s just the summarized route to areas 1 and 2. It would be done problably by an area range configuration, right?
And the 2011 would stay in both areas, right?
About the tip from AlexS, I got concerned about the number of areas created. Won’t it make the things more complicated?
I’ll try both setups and return here for feedback.
Incorrect. An OSPF router is also an ASBR when it (for example) redistributes connected routes. The config shown earlier has both 2011s set to redistribute connected routes thus my comment. Of course the 2011 configs could be altered to include the connected networks directly via network statements in which case they would not be ASBRs, but in the config above they are acting as ASBRs.
Fair point..I missed the redistribution, but that would be routing that’s not OPSF
Better to advertise than redistribute Type 1 external LSAs as those routes will cross area boundaries and defeat the purpose of summarizing at the ABR. True stub areas would help with this, but it wouldn’t be a great idea to stub a network with multiple paths
The bigger question is whether or not OSPF is the right choice for a dual wan topology across 50 remote sites in the long term…my thoughts are that it isn’t
The more I look at this, the I think BGP would solve most of the design challenges this network has more simply and with a greater flexibility down the road. Since you will be converting 50 something offices into this design, you really should consider something more flexible than OSPF - especially if the WAN link speeds are not equal. I didn’t recommend that at first because I thought you had 50 sites already deployed with OSPF similar to the diagram you posted and the reconfig would be massive
My revised recommendations are:
Take a test site and connect it via BGP instead of OSPF (you shouldn’t need an EOIP tunnel for BGP
It is very common in larger private networks now to use an autonomous system number per site so pick an AS for the 1100s and then use a new AS for each remote site.
At this point, you can summarize, filter and move traffic onto either WAN link much more easily without worrying about the quirks of OSPF hierarchy/areas and if you like the way this routing setup works, then you can make it cookie cutter across the board. If not, then you can still make some improvements to OSPF.
People often assume that ASBRs imply another routing protocol as you originally said whereas it only implies another routing process/source such as connected, statics etc. Anyway I had a chuckle …
I asked some questions earlier (which I don’t think have been answered) regarding the nature of the branch office networks and internet access. It is quite possible that what the OP is trying to achieve could be achieved using weighted static routes and gateway checks!
I use BGP, OSPF, EIGRP and some other routing protocols on a daily basis. I have no favorites. You could carry out the OPs requirements with either OSPF or BGP - and maybe you could even carry out with static routes. My view is simply that the requirements can be met with less effort, less of a learning curve and less load on those branch routers by using OSPF which the OP has already started to work with.
In case there is any confusion… OSPF does not need multicast to form adjacencies - that is simply a config issue.
In case there is any confusion… OSPF does not need multicast to form adjacencies - that is simply a config issue.
No confusion, just didn’t see the benefit of using OSPF as it won’t be much simpler in this network than BGP since OSPF either needs static neighbor definitions or EOIP. Then add the prospect of jockeying cost and/or policy routing if some routes need to be prioritized on different WAN links.
These days in most greenfield designs, we tend to use OSPF to provide loopback and transit subnet connectivity and BGP for all subnets that will carry traffic - it is simple and scalable from a handful of routers to thousands.
If you haven’t listened to this podcast, it may shed some light on what is happening in OSPF design in large environments these days:
I don’t think that anybody with experience has paid any attention to the old Cisco OSPF design “constraints” for quite a long time.
However, when considering the number of areas or routers per area the actual OSPF implementation and router processing performance are still relevant considerations. I rarely see a modern Cisco or Juniper router tie itself up in knots running SPF but it can certainly happen on lower end hardware.
Point taken. We’re doing the tests. I’m not familiar to BGP yetm, so I’m studying. For example, I didn’t know that with BGP it wouldn’ be necessary an adjacency like OSPF.
We’re deploying OSPF, so it makes more easier to change the modus operandi now.
We have in each branch office one MPLS(EoIP) and one Internet(PPTP) link. In the past we used to use scripts to check the gateways and change the priority of routes. But with the enlargement of our network, it began to seem a little bit dumb to suffer with 50 scritps on HQ than make a dynamic topology.
In any case, i’m listenning all ideas.
