I'm working with a network I inherited. They have two WAN providers; one has one eigrp assigned internally, the second has two assigned internally. The Data center cores are configured with five different instances (#) of eigrp, and an ospf (#). Each of their 5 branches is served by a different ospf (#), along with each of the eigrp (#) assigned to the WAN providers.
I have never worked with a setup like this, and I'm wondering if this is overkill? I think they could distill this down to fewer.
OSFP or EIGRP (#) for the entire enterprise, since they essentially own the enterprise. Can someone comment on this? I have the go ahead to simplify this if I can, but I've never had to deconstruct something like this. Thank you.
Hmm, yes that would seem to be a bit unconventional.
Possible reasons that may have been done was, for security purposes, limit topology information to other parts of the overall topology. Or, perhaps, this was done rather than using an EIGRP design with address summarization or OSPF using multiple areas (also, perhaps, using address summarization and/or stub areas).
Likely, the core routers' CPU loading and/or memory usage is increased by such an implementation, but assuming each of these routing instances are much smaller than a larger (or one) instance would be, perhaps it is not a major resource increase.
The biggest possible issue might be supporting this because it's unusual. (I.e. first reaction to seeing this setup might be, WTF.)
Likely you could "simplify" such a configuration, but before you do so, it would be nice if you could track down the former designer(s) and ask "why" this was done.
Sorry I let this thread go so long. For their internal network (not partners) there are 10 different OSPF AS #, and 7 different EIGRP AS # for nine sites. Two sites have the same OSPF #, and two sites have two different OSPF #. All of these sites are considered owned enterprise networks. They have two WAN providers. each provider has one circuit to each site from the two data centers, not MPLS. They have two partners that manage their own internal networks which connect at each of their data centers.
I don't understand why they would configure so many? I could see one Backbone OSPF or EIGRP with point-to-points to each 'owned' site, perhaps using VRRP with metric. Then separate OSPF or EIGRP for the partners. I'm sure there's many ways to configure this, but their current setup seems like overkill to me. Thanks for the kind input.
Hello @StevenPhipps35347 ,
OSPF process-ids are locally significant and they don't need to match to form a neighborship. Actually the OSPF process-id is not sent in OSPF hellos or other OSPF packet types (OSPFv2 for IPv4)
So the fact that they used different OSPF process-ids in different sites does not meain they are totally separated.
You can check this with show ip ospf neighbors .
I agree on the rest of your considerations.
Hope to help
Hello @StevenPhipps35347 ,
OSPF process-id is locally significant so having different OSPF process -ids do not automatically means they are in a different OSPF routing domain.
Because you also noted that:
>> The Data center cores are configured with five different instances (#) of eigrp, and an ospf (#).
Then you say:
>> Each of their 5 branches is served by a different ospf (#), along with each of the eigrp (#) assigned to the WAN providers.
In EIGRP the AS number must match to be in the same domain.
if EIGRP processes are used on the WAN links one provider needs one and the other provider is using two, at least three EIGRP instances may be justified.
You need to understand why OSPF is needed in each branch site ( presence of multi vendor equipement ?) and how in each branch the EIGRP processes relate to the OSPF process ( there is redistributtion of EIGRP routes into local OSPF ? and of local OSPF routes into EIGRP processes ?)
How the two WAN providers are used ? there is a primary path always provided by the same ISP ?
Note: in the past there was a wrong belief that using multiple EIGRP AS could block the Query scope when a route goes Active. This is not true. Only summary routes, route filters or the use of EIGRP stub feature on branch are effective to limit Query scope.
Hope to help