David,
Another thing that I wonder about is the remote end; what do those routers
look like?
If you have something like this:
+-Hub1---Hub3-+
| \ / |
RemoteX-+ X +-RemoteY
| / \ |
+-Hub2---Hub4-+
You'll probably want to restrict what routes the remote routers can
advertise.
Given the size of your network, it would seem to me that something similar
to the following would be more appropriate (disclaimer here, I know nothing
of your business requirements nor am I looking at $$ as a limiting factor -
which I'm certain it is). I'm making these basic assessments off the fact
that your network doesn't seem to follow the standard Cisco
Core-Distribution-Access model (yes, I've probably consumed too much of the
Cisco Kool-Aid).
+-Distr1---Hub1---Hub3---Distr3-+
| | \ / \ / \ / | |
RegionA-+ | X X X | +-RegionZ
| | / \ / \ / \ | |
+-Distr2---Hub2---Hub4---Distr4-+
Within each region you'd have a contiguous block of addresses (both WAN and
LAN segments) you then summarize from the distribution-layer routers to the
hubs. The hub forward these summary routes to the other hub routers and so
on until they reach the remote routers in the other regions.
Again, I don't know the requirements of your network but if I were starting
with a clean sheet of paper and we wanted to use RFC1918 addresses, I'd
probably consider using the 172.x.x.x space. Each region could be a
separate /16. If we define the core as the including all of the hub routers
as well as the networks connecting them to the various distribution routers
and make that the network 172.16.0.0/16 (obviously, there are multiple
subnets needed, but they'd all be summarizable in this "major" net). Then
assign a /16 to each region - so RegionA would be 172.17.0.0/16, RegionB
would be 172.18.0.0/16, etc.
Assuming that you have a data center or two, the server farms in these
locations would also connect to the hub routers (ideally behind their own
distribution-layer routers which summarize the address space for the server
farms into the core).
Generally speaking, a design like this will scale into the thousands of
sites - obviously YMMV depending on your requirements.
The key rule to follow here is that the core of the network is optimized to
route packets. This is not the place to enforce network policy (ACLs, QOS,
manual summarization, etc.).
We all love the network 10.0.0.0/8; it gives us great freedom and allows
networks to be built without concern for addressing efficiency. There are
some downsides to this though and you've found one. You've been dealt a
slightly worse hand though because you sandwich 172.x.x.x networks between
10.x.x.x. I'm going to go out on a limb (kidding) and suggest that your
EIGRP configurations have "no auto-summary" configured, right? In the
configuration above, you could allow EIGRP to auto-summarize - you'd
actually prefer it because it would mean that you didn't need to manually
summarize at all.
There are some things you can do to probably make your existing hardware
investment work with the current number of sites but it will require that
you re-address your network to follow something similar to the design I
outlined above just without the separate distribution routers. If you're
growing like mad you'll want to ensure that you can get funding for the
distribution layer because at some point (if not already) you'll have too
many neighbors on each core router which will spark a whole new set of
problems.
Quickly, on the remote routers, I don't care how big or small the network
is, in a (highly) redundant network I try to make sure that each router only
advertises networks it's responsible for (e.g. directly connected or
down-stream subnets). With EIGRP one of the easiest ways to do this is with
the distribute-list command. I try to select a standard ACL number (for
example # 5) across the enterprise and then on each router permit only the
networks we want - in this case, the remote routers would advertise their
directly-connected Ethernet network(s) and maybe a loopback. This will keep
EIGRP from thinking that the remote router is a possible transit path to all
other networks (especially a problem if you use sub-interfaces on the remote
side).
Well, I could go on and on but I've got to get back to studying. These are
just some suggestions that have worked for me in the past, I'd be interested
in what others on the list have experienced.
Hope this helps,
Ben
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 15, 2002 5:51 AM
To: [EMAIL PROTECTED]
Subject: RE:Summarization (to Ben Kessler) [7:31975]
Ben, I'm afraid that when I answered your post it was already buried under
tons of other post. I'm sorry, these are the consequences of living in
Europe...:->
Anyway, thanks for your detailed answer, I hope to get more detailed
specifications (CPU, memory,...) asap, but by now I have only said the
following:
I'm afraid I have no idea what happened but I'm think that it wasn't a
problem with CPU unless summarization is a very intensive cpu process(I
don't know if it is).
We have a hub-and-spoke topology. Four 7500 (2 7513 and 2 7507) for
full-meshed backbone (ATM)and over 230 sites (2500 an 2600 mainly), and we
have implemented redundancy using dialers and ISDN connections (and yes, we
have conected each router to two different hub routers). In one of the 7513
we have over 100 dialers and 90 serial WANs connections, I have tried the
summarization again with only two routers and by now, I haven't experimented
any problem.
As you can guess, our network is growing more and more and I'm worried about
routing tables with a lot of entries (we're using network 172.x.x.x for
serial interfaces and 10.x.x.x for ethernet interfaces)
I tried to summarize on networks 10.x.x.x and 172.x.x.x using the following
commands
ip summary-address eigrp 1 10.0.0.0 255.0.0.0
ip summary-address eigrp 1 172.0.0.0 255.0.0.0
Today, I have talked with my boss and we've decided to try the summarization
again but we're going to use the 0.0.0.0 network instead the other two (I'll
try to check my RSP in-depth this time)
Anyway, we're not experts in Cisco so I thought that we could reduce routing
tables using summary address and make easier the administration and
troubleshooting (perhaps it isn't a good idea). Unfortunatly, we work in a
helth-care enviroment, and we have to make sure before doing anything in
backbone routers.
I hope you read this post, I live in Europe and every time I have to reply a
post I have hundreds before me. Anyway, I'll keep you and this wonderful
group informed.
David
I've done it with about 100 interfaces on 7513's and didn't see this
problem. It may be a limitation of the code on the box, memory (as you
indicated), or something else. Have you been able to rule-out as many
"something elses" as possible?
What does the network topology look like? Do you have redundancy in place -
e.g. spoke routers connected to two different hub routers? Are you getting
a lot of SIAs? Routes flapping, etc.? How's the CPU on your RSP's looking?
Free memory? Buffer misses?
There's a common view that EIGRP works fine and can scale infinitely big
without going through all of the steps that you'd have to go through for a
large-scale OSPF installation.
Obviously, this thought is very wrong.
I'm guessing that you need to do manual summarization on 200 interfaces per
box is because you don't have clearly-defined summarization points in the
network - that's the situation I was in when I had to do it on ~100
interfaces. For good or ill, EIGRP will work with a bad network design (I'm
speaking from an ideal perspective - please don't be offended, we all have
to things at one time or another that are considered "bad") up until a
point. Beyond that point, it gets really ugly - quickly.
In the network I was working on we had 140 sites connected without problems.
We started adding more offices and by the time we hit 170 the network was
totally unstable. After several weeks of P1/CAP cases we met with the guys
who write the code and found out what we were doing wrong - they have since
published several CiscoPress books on EIGRP; none existed four years ago :)
You can "band-aid" a broken network by using a lot of the EIGRP features
(manual summarization, distribute-lists, etc.). In my case that's exactly
what we did, unfortunately, I was not given the opportunity to correct the
mistakes that required the band-aids. I have since moved on to new
challenges but that network is still in the same state - four years later.
Anyhow, if you can offer more specifics, I'm sure those of us on the list
would be happy to comment and offer suggestions. I think that if we can
solve the reason you need to manually summarize on 200 interfaces you'll be
better off down the road.
Ben
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 13, 2002 5:02 AM
To: [EMAIL PROTECTED]
Subject: Summarization [7:31766]
Hello folks,
I'm working in a EIGRP enviroment, and I have some questions for you:
Has anyone tried to do a manual route sumarization per interface with more
or less 200 interfaces in a 7500?
I've tried but I'm having a few problems, the summary routes aren't
advertised sufficiently fast to the routers in branch offices.
The summary routes are sometimes marked as "possibly down" in the routers of
branch offices, sometimes are up and sometimes are down.
Do you know any relationship between memory or cpu (or whatever) of the 7500
and number of interfaces in which you can perform manual summarization?
David
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=32035&t=32035
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
