Re: Port SPAN on 6509 and ARP Problem

josephqiu · ‎09-09-2004

A port SPAN is created recently to monitor the traffic on another port on the same 6509 switch. This is the configuration:

set span 8/28 8/19 both inpkts enable multicast disable create

8/28 is the source port, and 8/19 is the destination port. Port 8/28 is on VLAN 6 and Port 8/19 is on VLAN 4.

After entering the configuration, port SPAN is working well. However, other PCs on VLAN 4 can not communicate with the PC connected to port 8/19 (let's call it PC1). "arp -a" on those PCs is showing that they do not know the MAC of PC1. They use ARP to acquire the MAC, because they think it's on the same subnet, and it's not necessary to talk to the router. But the sniffer running on PC1 didn't show any captured ARP packets from VLAN 4, while sniffer running on other VLAN 4 PCs can see that ARP packet! In other words, the ARP is not received by PC1.

Other information:

- When the port SPAN configuration is removed, PC1 can talk to any VLAN 4 PCs correctly.

- With the port SPAN configured, all non-VLAN 4 IP nodes can successfully PING PC1. The problem only happens to those PCs on the same VLAN as PC1.

- With the port SPAN configured, PC1 can PING other VLAN 4 PCs. After that first PING from PC1, those PING'd PCs can talk to PC1. However, when the MAC of PC1 timed out, the communication is lost again, unless I PING from PC1 again.

So, I'm just wondering, with port SPAN enabled on 6509, are all incoming ARP broadcasts blocked on the destination port? To my understanding, ARP uses all "F" layer 2 broadcast address. It should flood all switch ports configured for the same VLAN 4. But why it's not received by port 8/19, which is only assigned to VLAN 4 in this case (not trunking)?

Many thanks!

Kevin Dorrell · ‎09-10-2004

I wonder whether the "multicast disable" is the problem, broadcast being a subset of multicast. I would like to think that it only applied to the spanned traffic, and not to the native VLAN traffic, but it is not clear from the documentation.

Kevin Dorrell

Luxembourg

josephqiu · ‎09-10-2004

Thanks for the reply, Kevin.

I was thinking in the same way. But I found enabling multicast doesn't solve the problem. I guess ARP is layer 2 broadcast. The "multicast" argument in the SPAN command might be for layer 3 multicasts.

rjackson · ‎09-10-2004

The way you descibe this it sounds like the only way this works is with proxy-arp. ARPs are not forwarded between vlans. The router runs proxy arp which means that when it sees arps for hosts that it knows are not on that network it answers them. When it then receives data for that host it forwards it. When the data reaches the destination network the router on that network (in your case the same router) performs the arp to send the data. I cannot find anything documented but it sounds like proxy arp is being disabled on the vlan of the destination port in the span. Try making a new vlan and putting the sniffer monitor port in it.

Kevin Dorrell · ‎09-10-2004

But I thought that in this case it was the same-VLAN ARPs (within VLAN 4) that are getting lost, not the inter-vlan proxy ARPs. Or have I misunderstood? Joseph?

Kevin Dorrell

Luxembourg

smif101 · ‎09-10-2004

You have to remember that you can't treat a SPAN port like its just another PC connected to the switch. I don't even recommend adding the both inpkts for this because you disable Spanning tree on that port. Is there a specific reason you want this sniffer to belong to a different vlan that you are sniffing plus letting it be accessed by other devices in the network. I would recommend that you let it sniff the traffic you want for a specified time, delete the span session and then have access to the PC like normal.

rjackson · ‎09-10-2004

Yeah, I guess I never considered he was trying to talk to the sniffing pc. I have done this before for a websense hosts that was monitoring internet traffic and needed to be accessed remotely through the same interface. Seems like the key was inpkts enable.

josephqiu · ‎09-10-2004

You're right. It's a Websense server connected to the SPAN destination port. That's why I have to enable inpkts, and the server is on a different VLAN.

The lost ARPs are the same-VLAN ARPs. Inter-VLAN ARPs work well. I have no problem for non-VLAN 4 PCs to communicate with the Websense server.

I was thinking it's a proxy-ARP problem. But proxy-ARP is enabled on all VLAN ports on 6509. And proxy-ARP is normally used for MAC resolution for remote IP nodes. In my case, the workaround I'm currently using is to enable local-proxy-arp on interface VLAN 4. Then, the MSFC router replies the same-VLAN ARPs on behalf of the websense server.

Actually the same SPAN configuration has been there for a few months, and I never had an ARP problem for VLAN 4 until a few days ago. I can't find any solutions or headsup in Cisco documentation regarding the SPAN and ARP. In other words, I guess Cisco believes SPAN shouldn't block same-VLAN ARPs. However, my reality is ......

Again, many thanks to all of you who replied to this topic. If you have new ideas, please let me know.