Re: multicast mac-address Nexus 7k

dinoantonucci · ‎07-12-2009

Hi,

i'm going to use Nexus 7000 in Data Center.

During analysis configuration, I need define mac-address-static configuration for multicast mac address for Firewall Checkpoint cluster.

In "Layer 2 Switching Configuration Guide, Release 4.1.pdf" documentation speak about

"Configuring a Static MAC Address

[..]You cannot configure broadcast or multicast addresses as static MAC addresses[..]"

Have you a suggestion to manage this problem and why is it not possible configure mac address static multicast?

Regards

Dino

ltd · ‎07-12-2009

Hi Dino,

its a standards violation and therefore not allowed.

specifically, RFC 1812 "Router Requirements" says in section 3.3.2:

A router MUST not believe any ARP reply that claims that the Link

Layer address of another host or router is a broadcast or multicast

address.

having said that, we know that some vendors (Checkpoint firewall One, Nokia firewalls) DO have such a requirement and as such, we are going to be allowing this in the Ankara (4.2) NX-OS release.

this is due to be released in the next 2-6 weeks, so if you can hang in that long, that is my suggestion.

if you're not in a production network environment, it may be possible for you to participate in the NX-OS 4.2 beta programme if you wish to test this functionality sooner.

feel free to contact me (ltd@cisco.com) off forum if this is something you wish to persue.

cheers,

lincoln.

dinoantonucci · ‎07-12-2009

Hi Lincon,

thank you so much for careful answer.

unfortunately we cannot hang for that period and i will speak with customer to evaluate a second way: partecipate nx-os 4.2 beta programs.

But i have another question: in network infrastracture network/VLAN does not have a

router that can take on the multicast router role and firewalls routes these network. Could it be a workaround implement igmp querier only on nexus platform during temporary period?

cheers.

dino

tstevens · ‎08-01-2009

Lincoln, Dino -

Actually, what is introduced in 4.2 is static *ARP* entries, which will now allow mapping unicast IP to multicast MAC (eg, ip arp 1.1.1.1 0100.5e00.0011). It does *not* introduce static multicast mac entries (eg, mac-address 0100.5e00.0011 int e1/1-2).

The former will result in the routed packets hitting such an ARP entry being flooded in the output VLAN, so it makes sense only when the FWs are in an L3-bordered VLAN by themselves.

The latter will also be supported longer term, but that would not be before mid CY10 most likely.

Hope that helps.

Tim

e.hoehn · ‎08-12-2009

Hello,

one of our Customers updates to the 4.2(1) to use the static ARP entry.

They recognized that every packet is beeing dupplicated.

Is this already a knowen problem ?

Is there a fix / workarround available ?

THX in advance for a response.

Emanuel

tstevens · ‎08-12-2009

Hi Emanuel -

Do you mean 2+ copies of each packet *on a single port*? Or do you mean, a single given packet is seen on all ports in the vlan (ie, flooding)?

The latter is expected, the former is not. Please let me know. Thanks,

Tim

e.hoehn · ‎08-12-2009

Hello Tim,

unfortunately every pkt get reproducecd on a single port.

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

64 bytes from 192.168.0.1: icmp_seq=1 ttl=252 time=0.500 ms

64 bytes from 192.168.0.1: icmp_seq=1 ttl=252 time=1.96 ms (DUP!)

64 bytes from 192.168.0.1: icmp_seq=2 ttl=252 time=0.375 ms

64 bytes from 192.168.0.1: icmp_seq=2 ttl=252 time=1.57 ms (DUP!)

tstevens · ‎08-12-2009

Hi,

Please describe the exact topology here. How are things connected, and where are you pinging from/to?

Based on the delay, it looks like packets are looping back around somewhere in the network. Clearly with flooding, if there is a loop, this would occur.

Thanks,

Tim

e.hoehn · ‎08-13-2009

Hello,

We disabled all other ports, so here the setup:

--------------------------------------------------------------------------------

Port Name Status Vlan Duplex Speed Type

--------------------------------------------------------------------------------

mgmt0 -- up routed full 100 --

Eth1/1 -- down trunk full auto 10g

Eth1/2 -- down trunk full auto 10g

Eth1/3 -- down 55 full auto 10g

Eth1/4 -- down 1 full auto 10g

Eth1/5 -- down 165 full auto 10g

Eth1/6 -- down trunk full auto 10g

Eth1/7 -- down 55 full auto 10g

Eth1/8 -- down 55 full auto 10g

Eth1/9 -- down 55 full auto 10g

Eth1/10 -- down 167 full auto 10g

Eth1/11 -- down 55 full auto 10g

Eth1/12 -- down 55 full auto 10g

Eth1/13 -- down 60 full auto 10g

Eth1/14 -- down 55 full auto 10g

Eth1/15 -- down 55 full auto 10g

Eth1/16 -- down 55 full auto 10g

Eth2/1 -- down 55 full auto 10g

Eth2/2 -- down trunk full auto 10g

Eth2/3 sniffer up 60 full 10G 10g

Eth2/4 -- down 55 full auto 10g

Eth2/5 -- down 55 full auto 10g

Eth2/6 -- down 55 full auto 10g

Eth2/7 -- down 55 full auto 10g

Eth2/8 -- down 55 full auto 10g

Eth2/9 -- down 55 full auto 10g

Eth2/10 testclient up 167 full 10G 10g

Eth2/11 -- down 55 full auto 10g

Eth2/12 -- down 55 full auto 10g

Eth2/13 -- down 55 full auto 10g

Eth2/14 -- down 55 full auto 10g

Eth2/15 -- down 55 full auto 10g

Eth2/16 -- down 55 full auto 10g

Po1 -- down trunk full auto --

Po2 -- down trunk full auto --

Lo0 -- down routed auto auto --

Vlan1 -- down routed auto auto --

Vlan60 testsniffer up routed auto auto --

Vlan131 -- down routed auto auto --

Vlan165 -- down routed auto auto --

Vlan167 testclient up routed auto auto --

interface Vlan60

no shutdown

description testsniffer

ip address 137.226.78.57/29

ip arp 137.226.78.60 5142.4242.4242

interface Vlan167

no shutdown

description testclients

ip address 137.226.185.5/24

There is one test-Client connected to Eth2/10 which is pinging the "Multicast IP" 137.226.78.60

This IP addr. is not present, but on the Sniffer we see the ICMP requests (2 pkts per ICMP request).

When a client with the IP 137.226.78.60 is present it gets the requests (every packet twice) and sends and answer for every packet. but the reply is not beeing duplicated again, so the testclint gets for every request 2 replies, not 4.

tstevens · ‎08-13-2009

Hi,

We are checking into it, thanks for the heads up.

Tim

e.hoehn · ‎08-18-2009

Hi Tim,

have you guys been able to follow up on this ? Any idea for when a fix will be available ? Or do I have to open a Service Request to get a fix ?

tstevens · ‎08-18-2009

Hello everyone -

Unfortunately, this is a bug, I reproduced it & filed CSCtb39810.

Basically what's happening here is hardware is incorrectly setting the so-called "CAP1" bit in these packets. The routed packet gets hardware switched, but the CAP1 bit causes the packet to also get copied to the inband interface (ie, sent to the sup CPU), where it ends up getting software routed.

That's why the 2nd copy has higher latency & you'll also see that the TTL has been decremented twice (once by hw & then again by sw).

Note that there's a hardware rate limiter in place that throttles the copied packets to 30Kpps toward the sup. However, other packets require use of the CAP1 bit (new multicast sources for example) so it is potentially dangerous to lower this rate limiter too drastically.

Anyway, engineering has a candidate fix, I have a test image I need to load up today to confirm it's working in my testbed.

Assuming it does, and there is no collatoral damage/issues with the fix, we would need to release a new image w/the fix.

Hope that helps - apologize for the inconvenience this issue may cause you...

Tim

ahojmark · ‎05-11-2010

Tim,

Is the possibility of doing static MAC still roadmapped for "mid CY10"?

What release should I be looking out for? 5.0?

TIA,

-A

tstevens · ‎05-11-2010

This feature is now tracking for more like end of the CY, possibly later.

Tim

joseph weber · ‎12-10-2010

We are about to setup our datacenter soon with Nexus 7Ks and checkpoint firewalls

runnning HA. Has anyone found an answer on to how to setup the static arp

entry correctly? We are running NX-OS 5.1(1a). One thing that we need is the ability to have a static arp entry for a vlan that does not have a SVI on the Nexus 7k. In IOS 12(2)SXI, this was easy, all you had to do was put in a static entry like so in global configuration mode:

arp 10.70.60.10 0100.5e11.1111 ARPA

The switch would automatically answer up when an arp request was sent to 10.79.60.10.

We have tested static arp entries on SVIs for the Nexus 7Ks and they don't work at all in 5.1(1a). Is there any way around this?

Here is our setup:

interface Vlan10

no shutdown

ip address 192.168.100.1/24

ip arp 192.168.100.10 0100.5e11.1111

I am using a workstation plugged directly into the 7k on Vlan 10:

interface Ethernet1/2

description test_arp

switchport access vlan 10

no shutdown

I am testing by pinging 192.168.100.10 and then looking in the arp cache of

my workstation. No arp entry ever shows up. It briefly has an "invalid"

(all 0s) but that goes away after the arp request times out.

Any help would be greatly appreciated. I have contacted Cisco TAC but haven't recieved a workaround or fix. Thanks!