Advertising Loopbacks via EIGRP on 3650 Stack with LACP VPC Etherchannel to 2 Nexus 7Ks with HSRP SVIs

[tom.neteng]

I'm looking for a workaround using EIGRP passive interfaces in an HSRP configuration on routers or L3 core switches in order to be able to have a downstream switch with only one management SVI receive a default route and be able to advertise any loopbacks dynamically and without the need for static routes on both the cores and the access switches.

I recently migrated the SVIs that were on a couple of switches doing L3 at the access layer to our new 7K core and swapped out the EoL access switches for a couple of 3650s in a stack.  I have the stack connected to the two 7K cores via a single port channel Ten1/1/4 on each switch.  The Nexus side has a VPC port channel with one ten gig link on each core.

HSRP runs on both 7Ks for the SVIs that are trunked to the 3650 stack.  EIGRP is the dynamic routing protocol being used at the interface level.

In order to stop the cores forming an adjacency with each other, each SVI on the 7K is an EIGRP passive interface.  Herein lies the problem.  I can neither receive nor advertise any loopback IPs or default (or any other) routes.

While I can put an SVI directly on the 3650 stack on one of the VLANs that is also on the core to use as a management address, I have no way of setting any loopbacks and having their addresses advertised to the rest of the network.  Nor am I able to learn even a default route from EIGRP because the SVIs on the Nexus cores are passive interfaces.

I was able to kludge together a not very elegant solution by enabling routing on the 3650, adding an SVI to one of the VLANs and putting direct routes to the loopbacks via the IP of the SVI on the 3650.  It works, but I really don't want to have static routes.  Is there any other way to achieve dynamic advertisement and receipt of routes to a single SVI on a switch while in such a topology where the uplink is a pair of HSRP cores or routers?

TR

[paul driver]

Hello

Not sure I understand  you only want no no passive interface in the eigrp peer anyway and then summarise a default on that interface towards the peers that require a default  

[tom.neteng]

This is how the other interfaces were configured:

interface Vlan327
ip address 10.3.27.2/24
ip router eigrp 1
ip passive-interface eigrp 1
hsrp 0
preempt
priority 255

ip 10.3.27.1

interface Vlan327
ip address 10.3.27.3/24
ip router eigrp 1
ip passive-interface eigrp 1
hsrp 0
preempt
priority 255

ip 10.3.27.1

Are you telling me that in such a configuration, with two L3 cores or routers that share a link between the two, the passive interface is not necessary on both?  On only one?  I was under the impression that both had to be passive, so that an adjacency would not form between the two cores for that SVI.

What I would like is to be able to have the HSRP config on the linked L3 cores, while at the same time have a single interface on the access layer L3 switch (serving primarily as L2 with only the one SVI for management) to be able to learn the default route and advertise out any loopbacks on that switch to the core(s).

TR

[paul driver]

Hello

---

@tom.neteng wrote:

Are you telling me that in such a configuration, with two L3 cores or routers that share a link between the two, the passive interface is not necessary on both?  On only one?  I was under the impression that both had to be passive, so that an adjacency would not form between the two cores for that SVI.

What I would like is to be able to have the HSRP config on the linked L3 cores, while at the same time have a single interface on the access layer L3 switch (serving primarily as L2 with only the one SVI for management) to be able to learn the default route and advertise out any loopbacks on that switch to the core(s).

---

What i am saying is you can still select what eigrp peering establishes between the cores and switches and for that naturally you cannot enable no passive interface xx  which you only want to use to filter eigrp updates on interface you don't want eigrp peering.

You can do this by disabling eigrp multicast peering and use unicast peering.

Example:

core 1
router eigrp x
passive-interface default
no passive-interface x/x
no passive-interface x/x
network 10.1.10.1 0.0.0.0 (mgt core )
network 10.1.30.1 0.0.0.0 (switch mgt )
neighbor 10.1.10.2 FastEthernet0/1.10
neighbor 10.1.30.2 FastEthernet0/1.30

interface FastEthernet0/1.30
encapsulation dot1Q 30
ip address 10.1.30.1 255.255.255.0
ip summary-address eigrp 100 0.0.0.0 0.0.0.0 1
standby 30 ip 10.1.30.254
standby 30 priority 150
standby 30 preempt

core 2
router eigrp x
passive-interface default
no passive-interface x/x
no passive-interface x/x
network 10.1.10.2 0.0.0.0 (mgt core )
network 10.1.30.3 0.0.0.0 (switch mgt )
neighbor 10.1.10.1 FastEthernet0/1.10

neighbor 10.1.30.3 FastEthernet0/1.30

interface FastEthernet0/1.30
encapsulation dot1Q 30
ip address 10.1.30.2 255.255.255.0
ip summary-address eigrp 100 0.0.0.0 0.0.0.0 1
standby 30 ip 10.1.30.254
standby 30 preempt

sw
int lo0
ip addrress 3.3.3.3 255.255.255.255

int lo1
ip addrress 33.33.33.3 255.255.255.255

router eigrp x
passive-interface default
no passive-interface x/x

neighbor 10.1.30.1 FastEthernet0/1
neighbor 10.1.30.2 FastEthernet0/1
network 10.1.30.3 0.0.0.0
network 3.3.3.3 0.0.0.0
network 33.33.33.3 0.0.0.0
distance 91 10.1.30.2 0.0.0.0 1

access-list 1 permit 0.0.0.0

[vb10]

Hello,

Unfortunately, N7K vPC introduces some limitations regarding possible routing peering design.

It's not recommended to have peering with 2 N7K in the same VLAN, which is vPC VLAN. Otherwise you may face issues due to vPC loop prevention mechanism in some scenarios.

In regards to your situation. If you would like to have routing between N7K vPC switches and access switches, the possible option is to have EIGRP peering in separate dedicated VLANs. These VLAN numbers should be different towards each N7K switch, and they should be NON-vPC VLANs. Nexuses of course, should also have peering between themselves, but over NON-vPC peer-link.

You can check supported/unsupported  L3 designs in this doc, starting from page 74 "Best Practices for Layer 3 and vPC "

https://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/sw/design/vpc_design/vpc_best_practices_design_guide.pdf