EIGRP design question

[vd123_cisco]

Hi All,

I was wondering if anybody can help me with the following design question.

our service provider is changing the routing protocol of our WAN routers and they want us to configure EIGRP on our Core switches so that all subnets get advertised to the remote sites. I am comfortable with eigrp configuration but I would like to know if we introduce EIGRP between the Core switches would it cause any issues.

Please see the attached diagram for more details.

Thanks in advance.

Jay

[Peter Paluch]

Hello Jay,

Introducing EIGRP between your Core switches should not cause any issues. I wonder - how were they configured before? Did they use a different routing protocol, or did they use static routes?

I am somewhat surprised, though, that your ISP is asking you to configure EIGRP. Most providers go with open protocols - BGP, OSPF, IS-IS. What if you didn't have Cisco gear?

Best regards,

Peter

[vd123_cisco]

Thank you the reply Peter.

They were using RIP before and we had static routes configured on our core switches pointing to the primary and secondary WAN routers and Since we are using cisco devices they recomended EIGRP.

I have got another question with this design.

Do i need to make SVIs the passive interfaces? i guess when i configure EIGRP

router eigrp 1

network 172.19.0.0 0.0.255.255

no auto-summary

on core switches, the switches will form neighbor relationship on all SVIs. Is that correct?

Thanks again.

[Peter Paluch · Accepted solution]

Hello Jay,

Okay, I see. Thank you for the update. I wonder - how many IP prefixes do you expect the Core switches to learn via EIGRP? Orders of tens is fine, orders of hundreds and more may call for summarization, as the TCAM space in switches is a precious resource and should be used efficiently.

Do i need to make SVIs the passive interfaces? i guess when i configure EIGRP
router eigrp 1
 network 172.19.0.0 0.0.255.255
 no auto-summary
on core switches, the switches will form neighbor relationship on all SVIs. Is that correct?

That is correct. Setting the SVIs as passive interfaces is absolutely a good idea. However, I recommend having the Core switches peered in EIGRP. In your topology, I see a routed link between your Core switches - the 172.19.111.0/30. I suggest using this link as a non-passive interface between the Core switches and peering them in EIGRP over this link.

Best regards,

Peter

[vd123_cisco]

Thank you Peter.

We are expecting around 2 prefixes per site so around 15 prefixes.

I was thinking of creating a new SVI on both the switches and form an EIGRP relationship on to the SVI instead of a physical link as we have four redundant trunk links running between core switches

What do you think?

[Peter Paluch · Accepted solution]

Hi Jay,

You are welcome. 15 prefixes is absolutely fine.

I was thinking of creating a new SVI on both the switches and form an  EIGRP relationship on to the SVI instead of a physical link as we have  four redundant trunk links running between core switches

This approach would also work nicely. You can do it this way.

However, currently, it is being recommended that the interconnection between the Core switches, even if done as an EtherChannel, is configured as an L3 link. Assuming that the access switches are redundantly connected to both Core switches, STP will always block at least one link if all interconnections are L2 including the inter-Core link. In case of a link failure or restoration, STP may be required to reconverge. However, if the Core switches are interconnected only by L3 links or EtherChannels, there is no possible L2 loop between the Core and access switches, and the reconvergence in STP is simpler, without a blocked link being present in the topology.

As a possible future enhancement, you may consider reconfiguring the EtherChannel between your Core switches for L3 operation.

Best regards,

Peter

[vd123_cisco]

Hi Peter,

Thank you again.

I will look into reconfiguring the L2 etherchannel as L3.

Thank you,

Jay