cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
643
Views
0
Helpful
5
Replies

Calling The Nexus 7K Experts Who Like A Challenge ...

Ryan Curry
Level 1
Level 1

Last Wednesday we migrated from 6509s over to a pair of Nexus 7010's and everything, for the most part, went smooth but I've run into a strange issue that I wanted to run by the community before I open a TAC case.

As an FYI on our configuration we have the 7k's connected together via a 20Gbps peer link with a 1 Gbps keep-alive and a 1Gbps "non-vpc" layer 2/ layer 3 link.  So here's the issue: I'm experiencing an issue with two of our VLANs where only certain devices are not obtaining an IP address.  The odd thing is that I can see the DHCP discovery come through and the DHCP offer be sent from the DHCP server, but it never makes it to the client.

I found it strange that it's only happening on these VLANs, but as I look deeper is see that VLAN SVIs have an inbound ACLs applied to them.  Here's the kicker - if I pull off the ACL (inbound keep in mind) DHCP works for these client.  We don't have any outbound ACL applied to these VLANs so everything should be allowed, but it's almost like something's dropping the offer before it can be sent out.  Also, the switch stack that these devices attach to are connected to the core via a VPC.

The only other thing I thought about is possibly enabling the "peer gateway" command under the VPC domain, but my thought is that if it works when the ACL is removed then this most likely won't buy me anything.

Thanks in advance!

5 Replies 5

Reza Sharifi
Hall of Fame
Hall of Fame

If you have an inbound ACL, there is an implicit deny at the end of it and since the DHCP source address is 0.0.0.0 and the destination is 255.255.255.255 it is possibly blacking the PCs from getting IPs.  If you want to keep the ACL, then you need another one to allow port 68 (source) to communicate to port 67 (destination).

HTH

Ryan Curry
Level 1
Level 1

So after about 3 hours with TAC, we found that the ACL applied to the SVI (inbound) was blocking traffic coming across the peer-link.  To rectify the issue we added an ACE to the top of the ACL allowing all traffic to hit the SVI physical interface, thus allowing the peer devices to hand off packets to the SVI.  I guess we could have only allowed the peer SVI to connect but it's working now.

Thanks Reza for the reply!

Do you have an example of this ACE that you put to the top of the ACL?  I think I am having this same issue.

Will, I added an ACE at the top of the ACL to permit any traffic to that interface.  In my setup, we have .251 (Core1) and .252 (Core 2) as HSRP members.  On Core1 I added a "permit ip any x.x.x.251" and on Core2 I added a "permit ip any x.x.x.252".  x.x.x would be the addressing for the SVI.

Hopefully that helps, let me know if I need to explain better.

Thanks!

It does, but my issue is with an outbound ACL.  For some reason even with a "permit ip any any" statement at the beginning of the ACL we have a strange problem where only one of the 7k's can communicate with some hosts depending on the path selection.  The ARP tables populate correctly but IP connectivity fails.  I will work with TAC to see if I can find a resolution.  I was hoping seeing your ACE would shed some light on my issue

Review Cisco Networking products for a $25 gift card