Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Hall of Fame Super Gold

rspan breaks connectivity

For the first time I have been trying remote span by the manual, but cannot use it.

As soon I enter °monitor session 1 destination remote vlan XX", connectivity for the monitored vlan ceases.

When I negate the command, connecitivity resumes immediately.

If I monitor a source port instead or a vlan, the same happens, no more connectivity throught that port.

Vlan XX is configured as remote span and this information is propagated by VTP to all switches-

The same happens if I do the command on the VTP server switch.

The monitored port or vlan only have some hundreds PPS  traffic.

I have tried with various 2960 and 3750 with up to date IOS.

Local span works just fine.

Why that may be happening ?

19 REPLIES
Cisco Employee

Re: rspan breaks connectivity

Paolo,

I do not feel competent at all to give any guidance to a veteran like you but at least I can try to replicate the problem in my lab and tell you if I arrived at the same issue. I have a couple of 2960 and 3560 switches here. Can you tell me the precise IOS version you were using, and also, can you post relevant parts of the configuration that ultimately cause the monitored object (port or source VLAN) to lose connectivity, including the RSPAN session configuration itself?

Best regards,

Peter

New Member

Re: rspan breaks connectivity

Hi Paolo,

Can you post the following when its active, where x is your remote vlan and y is your spanned vlan :

- show vlan-id

- show monitor

- show vtp status

- show vtp pruning

- show int trunk

- show spanning-tree vlan

- show spanning-tree vlan

RSPAN is pretty straight forward, there shouldnt be a reason for the source traffic to stop unless the RSPAN traffic is passing on the same port and affecting the flow somehow.

/ijay

Hall of Fame Super Gold

Re: rspan breaks connectivity

Thank you all for your replies.

Please see the session below. 10.3.1.72 is a remote host reached via Vlan 253, but not directly within vlan 253.

Vlan 253 and vlan 7 are both active in the same port Gi1/0/19 going to the root of STP.

This is a 3750 wtih 12.2(53)SE2

FG-SW-ACDC#ping 10.3.1.72 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.3.1.72, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 126/126/126 ms
FG-SW-ACDC#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

FG-SW-ACDC(config)#monitor session 1 source vlan 253 rx
FG-SW-ACDC(config)#monitor session 1 destination remote vlan 7
FG-SW-ACDC(config)#do ping 10.3.1.72 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.3.1.72, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)
FG-SW-ACDC(config)#do sh vlan id 7

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
7    RSPAN                            active    Gi1/0/1, Gi1/0/19, Gi1/0/21
                                                Gi1/0/23

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
7    enet  100007     1500  -      -      -        -    -        0      0

Remote SPAN VLAN
----------------
Enabled

Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------

FG-SW-ACDC(config)#do sh monitor
Session 1
---------
Type                   : Remote Source Session
Source VLANs           :
    RX Only            : 253
Dest RSPAN VLAN        : 7


FG-SW-ACDC(config)#do show vtp status
VTP Version capable             : 1 to 3
VTP version running             : 2
VTP Domain Name                 : FAIRBANKS
VTP Pruning Mode                : Enabled
VTP Traps Generation            : Disabled
Device ID                       : 001c.b0ad.3c80
Configuration last modified by 10.60.2.1 at 10-14-10 15:40:31

Feature VLAN:
--------------
VTP Operating Mode                : Client
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 26
Configuration Revision            : 105
MD5 digest                        : 0x37 0x25 0x36 0xAD 0xDA 0x1A 0xF6 0x27
                                    0x47 0x97 0xC1 0xC5 0x2D 0x5F 0x44 0x56
FG-SW-ACDC(config)#do sh int trunk

Port        Mode             Encapsulation  Status        Native vlan
Gi1/0/1     on               802.1q         trunking      1
Gi1/0/19    on               802.1q         trunking      1
Gi1/0/21    on               802.1q         trunking      1
Gi1/0/23    on               802.1q         trunking      1

Port        Vlans allowed on trunk
Gi1/0/1     1-4094
Gi1/0/19    1-4094
Gi1/0/21    1-4094
Gi1/0/23    1-4094

Port        Vlans allowed and active in management domain
Gi1/0/1     1-7,9-10,14-15,17,19,23-24,50,99-101,201,253-254
Gi1/0/19    1-7,9-10,14-15,17,19,23-24,50,99-101,201,253-254
Gi1/0/21    1-7,9-10,14-15,17,19,23-24,50,99-101,201,253-254
Gi1/0/23    1-7,9-10,14-15,17,19,23-24,50,99-101,201,253-254

Port        Vlans in spanning tree forwarding state and not pruned
Gi1/0/1     1-7,9-10,14-15,17,19,23-24,50,99-101,201,253-254
Gi1/0/19    1-7,9-10,14-15,17,19,23-24,50,99-101,201,253-254
Gi1/0/21    1,4,19,50
Gi1/0/23    1-7,9-10,14-15,17,19,23-24,50,99-101,201,253-254
FG-SW-ACDC(config)#do sh spanning-tree vlan 7

VLAN0007
  Spanning tree enabled protocol rstp
  Root ID    Priority    24583
             Address     0026.99fc.f380
             Cost        19
             Port        19 (GigabitEthernet1/0/19)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32775  (priority 32768 sys-id-ext 7)
             Address     001c.b0ad.3c80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1             Desg FWD 19        128.1    P2p
Gi1/0/19            Root FWD 19        128.19   P2p
Gi1/0/21            Desg FWD 19        128.21   P2p
Gi1/0/23            Desg FWD 4         128.23   P2p


FG-SW-ACDC(config)#do sh spanning-tree vlan 253

VLAN0253
  Spanning tree enabled protocol rstp
  Root ID    Priority    33021
             Address     0011.92aa.1780
             Cost        27
             Port        19 (GigabitEthernet1/0/19)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    33021  (priority 32768 sys-id-ext 253)
             Address     001c.b0ad.3c80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1             Desg FWD 19        128.1    P2p
Gi1/0/19            Root FWD 19        128.19   P2p
Gi1/0/21            Desg FWD 19        128.21   P2p
Gi1/0/23            Desg FWD 4         128.23   P2p


FG-SW-ACDC(config)#no monitor session 1
FG-SW-ACDC(config)#do ping 10.3.1.72 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.3.1.72, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 118/118/118 ms





Hall of Fame Super Blue

Re: rspan breaks connectivity

Paolo

Config looks fine at first look. Which switch have you configured the destination session on and how is that connected to this switch.

Also when you do a ping have you tried with more than one packet.

Finally is the 3750 you have seutp the source session on doing the inter-vlan routing. If so can you post -

"sh ip int br"

and

"sh ip ro" from this switch.

Jon

Hall of Fame Super Gold

Re: rspan breaks connectivity

Thank you for your reply John.

jon.marshall wrote:

Paolo

Config looks fine at first look. Which switch have you configured the destination session on and how is that connected to this switch.

Well, that it irrelevant. One is supposed to be able to configure the monitored switch independently from the destination one, and have no negative consequence if no switch have monitor sopurce to the rspan vlan.

Also when you do a ping have you tried with more than one packet.

One ping or many makes no difference, also the users report connectivity failure.

Finally is the 3750 you have seutp the source session do the inter-vlan routing. If so can you post -

"sh ip int br"

and

"sh ip ro" from this switch

No, it is a pure layer 2 switch, and nothing unsual is observed with the above commands.

Nothing appears in loggin either.

Hall of Fame Super Blue

Re: rspan breaks connectivity

p.bevilacqua wrote:

Thank you for your reply John.

jon.marshall wrote:

Paolo

Config looks fine at first look. Which switch have you configured the destination session on and how is that connected to this switch.

Well, that it irrelevant. One is supposed to be able to configure the monitored switch independently from the destination one, and have no negative consequence if no switch have monitor sopurce to the rspan vlan.

Also when you do a ping have you tried with more than one packet.

One ping or many makes no difference, also the users report connectivity failure.

Finally is the 3750 you have seutp the source session do the inter-vlan routing. If so can you post -

"sh ip int br"

and

"sh ip ro" from this switch

No, it is a pure layer 2 switch, and nothing unsual is observed with the above commands.

Nothing appears in loggin either.

You are right in what you say about being to create them independently but what if in between this switch and the destination switch there was a misconfiguration that could potentially lead to an STP issue. With RSPAN you need to be aware of the entire path. Remember that once you have configured the source session that traffic will be flooded within vlan 7. It may not have anywhere to go in terms of a destination port but it still gets sent to all switches configured with vlan 7 on it.

Jon

Hall of Fame Super Gold

Re: rspan breaks connectivity


You are right in what you say about being to create them independently but what if in between this switch and the destination switch there was a misconfiguration that could potentially lead to an STP issue. With RSPAN you need to be aware of the entire path. Remember that once you have configured the source session that traffic will be flooded within vlan 7. It may not have anywhere to go in terms of a destination port but it still gets sent to all switches configured with vlan 7 on it.

Jon

If there is a misconfiguration I am not sure what it could be. There are no redundant links in this network, and STP settings are left at the default. Only the monitored vlan or port is affected, all the rest continue working. But, I will check again based on the possiblity that STP breaks.

New Member

Re: rspan breaks connectivity

I've also tried this quickly in the lab. I'm not running the same version, or RSTP, but RSPAN on 3750 works. The fact that only the spanned VLAN is affected points to STP breaking somewhere.

Hall of Fame Super Gold

Re: rspan breaks connectivity

Thank Ian for your testing.

I have reviewed the STP topology. In fact, due to an oversight, root for VLAN 253 was not the same as for VLAN 7, as can be seen in the trace.

So, I have corrected that, and repeated the test, with no changes.

Observed STP on the root bridge (that is also the routing core), there are no changes whatsoever with monitoring enabled or not.

The monitored switch is adjacent to the root bridge.

I think I will handle this to the TAC and update the thread if they can find a resolution.

New Member

Re: rspan breaks connectivity

I had something very similar. But using 3750's and 2 6513s at the core. Remote span a Port in VLAN 2... destination

vlan 60... vlan 60 was a remote span vlan... it killed all traffic to vlan2. Turned the SPAN off and

connectivity returned instantally. Was never able to go back and test. Nothing fancy just odd.

Re: rspan breaks connectivity

I am way new to this so slap me if I am wrong.... :-)

On the source switch you have

FG-SW-ACDC(config)#monitor session 1 source vlan 253 rx

FG-SW-ACDC(config)#monitor session 1 destination remote vlan 7

On the destination switch wouldn't you need this?

monitor session 1 source remote vlan 7

monitor session 1 destination interface interface_id

Mike

Hall of Fame Super Gold

Re: rspan breaks connectivity

burleyman wrote:

I am way new to this so slap me if I am wrong.... :-)

On the source switch you have

FG-SW-ACDC(config)#monitor session 1 source vlan 253 rx

FG-SW-ACDC(config)#monitor session 1 destination remote vlan 7

On the destination switch wouldn't you need this?

monitor session 1 source remote vlan 7

monitor session 1 destination interface interface_id

Mike

As mentioned above, it is not necessary to configure the second set of commands to manatain normal operation of the monitored VLAN or interface..

In other words, connectivity must not be afftected by destination switch presence.

In other words again, the monitored or source switch is not aware of the presence of zero, one or more destination switches, and must continue working indipendently.

That is what the documentation indicates, and my logical understanding of how things should be.

Re: rspan breaks connectivity

I was getting it out of the CCNP Switch book...maybe I misread it.

Here is what I read....

On Cisco IOS-based Catalyst switches, use the following commands in configuration mode to configure RSPAN.

On the source switch:

monitor session session source {interface interface-id | vlan vlan-id} [,][-] {rx | tx | both}

monitor session session destination remote vlan vlan-id

On the destination switch:

monitor session session source remote vlan vlan-id

monitor session session destination interface interface-id [encapsulation {dot1q | isl}] [ingress vlan vlan-id]

Mike

Hall of Fame Super Blue

Re: rspan breaks connectivity

Mike

What Paolo is saying is that the 2 are independant of each other ie. you can configure the source session without actually configuring the destination session. All that happens then is that the traffic is flooded throughout the RSPAN vlan but obviously doesn't end up at the destination port because you haven't configured that. But it shouldn't stop the source session working as such.

Obviously it wouldn't make much sense to do this but the logic is that by only configuring the source session it shouldn't have the effect Paolo is seeing ie. stopping traffic in the monitored vlan.

Jon

Re: rspan breaks connectivity

Gotch ya.....now I got it.

Could it be flooding so much traffic that it cause the loss of connectivity?

Mike

Hall of Fame Super Blue

Re: rspan breaks connectivity

burleyman wrote:

Gotch ya.....now I got it.

Could it be flooding so much traffic that it cause the loss of connectivity?

Mike


That's always a possibility with RSPAN but Paolo has said there is minimal traffic in vlan 253 so it is unlikely. There seems to be littel wrong with what config we have been supplied so it's not obvious what is happening exactly.

Jon

New Member

Re: rspan breaks connectivity

Hi Paolo,

I saw this issue with 2960C 12.2(35)SE5. Reachability to the server connected to the source port is lost rigth after I enabled mirroring.

Did you open a TAC case and get any feedback? I'd appreciate if you can share the results.

Cheers,

Hakan

Cisco Employee

Re: rspan breaks connectivity

Jon,

Good point. Also, Paolo: with regard to the article described a few days ago here:

https://supportforums.cisco.com/message/3198475#3198475

can you see any RSTP-related messages appearing on the upstream switch after you start the RSPAN session? What is the show span output on the upstream switch in the moment the RSPAN session is activated?

Best regards,

Peter

New Member

Re: rspan breaks connectivity

Peter's note is a good one. The only issue I can see is Gi1/0/21 being pruned by VTP. If this is not involved in the path there have been issues with switches inspecting BPDUs from RSPAN sessions previously. If the upstream box is blocking due to receiving VLAN253 BPDUs, this could be the source of the loss. Since the routing is done elsewhere, we need to follow the path to the VLAN gateway and review the STP state when RSPAN is enabled.

Inspecting the full STP topology and reviewing for changes when RSPAN is enabled will help here.

1290
Views
0
Helpful
19
Replies
CreatePlease to create content