cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
848
Views
0
Helpful
3
Replies

SPAN Session Issue

ahmad82pkn
Level 3
Level 3

Hi All,

i connected my main core switch to a Tail switch as regular trunk ( All ok, no issues )

Then i connected my main core switch(10.80.0.1) with same tail switch (10.80.0.63) and made Port on Core switch as SPAN Destination.

Idea is to forward SPAN Source traffic from CORE Switch 10.80.0.1 to 10.80.0.63 and then connect actual Recording server on 10.80.0.63 and send traffic to it.

Now on 10.80.0.63 i am seeing below error messages

 

ERROR on 10.80.0.63

Jul 22 08:58:54: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/1 (1), with HAMP6509CORE.trgworld.com GigabitEthernet8/3 (817).

any idea how to safely fix it?

Attached is diagram and error for explanation of scenario. and also port configuration on Core and Tail side.

3 Replies 3

Peter Paluch
Cisco Employee
Cisco Employee

Hi Ahmad,

When using a local SPAN, it is assumed that your monitoring or recording device will be directly attached to the destination SPAN port. Your setup is very unusual because you have attached a whole another switch to a destination SPAN port. This, in general, won't work because of several resons:

  1. The destination SPAN port is usually operating only as a egress-only port, and does not process any incoming frames. The entire "tail" switch will be cut off the network including all attached stations.
  2. The "tail" switch may not propagate all monitored frames to the recording station because it does not know that the incoming traffic is a monitored traffic. Rather, it will try to switch it using its MAC address table and normal switching rules. If it learns that both the source and the destination are reachable over its Gi0/1 interface, it will not forward the frames. The recording station will never receive them.

There are two ways of solving this: Either you connect the monitoring station to a standalone dedicated destination SPAN port on the Core switch, or you set up a Remote SPAN session that uses a special dedicated VLAN to carry all monitored traffic.

The remote SPAN session would be configured as follows:

  1. On all switches in your network, a dedicated RSPAN VLAN must be created and it must be specifically configured as an RSPAN VLAN. For example:

    vlan 999
     name Remote-SPAN
     remote-span
     exit

     
  2. On the Core switch, you need to set up a source RSPAN session capturing frames and having them fed into the RSPAN VLAN:

    monitor session 1 source interface ...
    monitor session 1 destination remote vlan 999

     
  3. On the "tail" switch, you need to set up a destination RSPAN session picking out frames from the RSPAN VLAN and feeding them to the port where the recording station is connected:

    monitor session 1 source remote vlan 999
    monitor session 1 destination interface ...

Trying to resolve the native VLAN mismatch alone is not helpful because your setup is generally invalid.

Do you believe any of this would work for you?

Best regards,
Peter

Hi Peter due to some constraints i cannot build RSPAN, as i also have to send traffic to a local machine as well that is directly connected  and i am not allowed to move it.

Also i have already tested that my Sniffer is able to capture all packet of the Vlans 817 ( that is Vlan for Avaya ) and all calls are getting recorded on NR server connected to tail switch.

so this design at least worked for me, but i do agree its kind of awkward design.

For  now i have used this command so that error message dont generate but i know behind the scene its generating.

no cdp advertise-v2


Another funny thing is when i do show CDP neighbor on my Access switch. i see port 8/3 in CDP neighbor whereas 8/3 is Host i am sniffing and actual port that should be in CDP is 8/14.

Looks like Cisco build a virtual Path within switch when doing SPAN and that is why i am seeing that port in CDP ? not sure exactly.

 

sh cdp ne on Access switch 10.80.0.63
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
6509CORE                 Gig 0/1           143             R S I  WS-C6509- Gig 8/3
6509CORE                 Gig 0/49          143             R S I  WS-C6509- Gig 4/25 (Trunk connection)
 

 

Hi Ahmad,

I understand. Well, you're in a very awkward position.

I suggest creating an entirely standalone VLAN on the "tail" switch that will contain only two access ports: the connection to the SPAN destination port at the core, and the recording station. Then deactivate MAC address learning on that VLAN on the "tail" switch using the no mac address-table learning vlan vlan-id - this will make sure that the "tail" switch will always flood all traffic received in this separate VLAN and your recording station receives it. You are currently relying on "unknown unicast flooding" by the "tail" switch that is an extremely volatile state.

Regarding the no cdp advertise-v2, this command does not do what you expect it to do: This one causes the device to revert to CDPv1 instead of running CDPv2. That is not what you intended to do. Please revert it by entering cdp advertise-v2 command, and then, on ports that interconnect the core switch and the "tail" switch, enter the following command:

no cdp enable

This will stop the CDP operation on the port and the messages about native VLAN mismatch will cease.

Best regards,
Peter

Review Cisco Networking for a $25 gift card