Monitor session to a destination vlan for passing across a trunk to Vmware

Unanswered Question
Aug 1st, 2010

Hey Netpros;

Have a little bit of an odd scenario I haven't enountered before and I'm trying to bend the rules a little.  I'm loading a call recording app as guest in our ESX cluster, but for it to work, it needs to see the voice traffic via a monitor/span session.  The ESX hosts are uplinked with multiple gig port channels setup to connect to multiple vswitches by using dot1q vlan tagging on the trunks.

The trick is getting the monitor / span session traffic from the voice gateway into the vmware environment using the existing interfaces / vswitch infrastructure.  The switching environment is a 3750 stack.  Now, obviously, I can't specify a regular vlan as the destination.  In the past, when I've needed to span to multiple destinations ports (before it was supported), I would place a seperate physical switch on the destination port, then hook up all the monitoring devices to that.  It would work, because the switch would flood the traffic to all ports.

My understanding about the switch forwarding table within these switches, is that it keeps the tables seperate per vlan.  So, here's what I did.

Created a new vlan, 255.  Assigned port 2/0/23 to vlan 255 as an access port.  Created the monitor session as you normally would, with port 2/0/24 as the destination, no ingress.  The source port is in vlan 254.  I then connected port 23 to 24 with a cat5 cable.  So, in essence, I'm taking the traffic from the source SPAN port on vlan 254 and piping it into vlan 255.

At this point, I simply added another port to vlan 255 to see if I was getting the desired switchport flooding.  I do see broadcast and multicast traffic from vlan 254, but I don't see any unicast traffic.

Is it failing to flood because it is learning the mac on the source port (gi2/0/23) or because it knows of the mac addresses via their true source ports in the other vlan, or some other reason?

I know this attempt at a workaround is a little unorthodox and is risky if not done carefully.  However, at this point, I'm just using it as a learning exercise to see if it can be done.


Following are the relevant portions of the configs:

ANM-3750G#sho monitor 
Session 1
---------
Type                   : Local Session
Source Ports           :
    Both               : Gi1/0/22
Destination Ports      : Gi2/0/24
    Encapsulation      : Native
          Ingress      : Disabled


interface GigabitEthernet2/0/23
description -=Voice Monitor Port - Input Vlan 255=-
switchport access vlan 255
switchport mode access
spanning-tree portfast
end
!
interface GigabitEthernet2/0/24
description -=Voice Monitor Port - Output Vlan 254=-
switchport access vlan 254
switchport mode access
spanning-tree portfast
end

interface GigabitEthernet1/0/23
description -=Voice Monitor - Test Port=-
switchport access vlan 255
spanning-tree portfast
end

Any assistance greatly appreciated.

Vance

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Nagaraja Thanthry Mon, 08/02/2010 - 08:54

Hello,

You are correct. Since the switch learns the MAC address of the device you have connected on VLAN 255 and also since it knows the destinations ports for the traffic you are pumping into VLAN 255, it will not flood the traffic to other ports. As you might be aware, you can specify multple destination ports for a SPAN session:

monitor session 1 source interface gi 1/0/1

monitor session 1 destination interface gi 1/0/2 , gi 1/0/4 , gi 1/0.5

This way, you can send the same information to multiple devices simultaneously.

Hope this helps.

Regards,

NT

Vance Krier Wed, 08/04/2010 - 08:14

Hey NT;

Thanks for the response.  I realize we can use multiple destination ports these days, but this means I need to dedicate a physical port per ESX host to support VMotion, HA, etc.  In a small environment like mine (3 hosts), not that big of a deal.  However, I have a customer that is looking for a similar solution and they have 10 or 12 hosts in their ESX cluster where this guest is supposed to go.

Anyway, doesn't sound like there is really a reasonable solution.  This probably means we'll just dedicate a physical box and call it day as that is more practical than dedicating a NIC on every host in the cluster, just to support this one application.

Thanks!

Vance

Actions

This Discussion

Related Content