Jumpering ports..

[marcsellgren]

Hello,

I've been searching quite extensively on Google, but haven't found anything that I've got working.

For testing purposes I want traffic transmitted into the switch  to pass through all the physical ports. To achieve this I will patch the  ports in pairs and then make a logical connection between each pair. Is  this possible? So far the traffic has just skipped all the jumpered ports. Also, I'm quite new to this in case that wasn't obvious

Thanks in advance.

/Marc

[Collin Clark]

I don't think that is possible. What are you ultimately trying to accomplish?

[marcsellgren]

I'm checking ports for errors. Transmitting a large file through the switch then CRC-checking it, two ports at a time, is time-consuming. I wanted to check all the ports at once by jumpering them all, with the exception of two ports at each end for traffic I/O.

Thanks for answering though!

Best regards, Marc

[Collin Clark]

Why check every port? Are you thinking that you may have some bad ones? Typically CRC/input errors are cause by one side negotiating full duplex and the other side half.

[marcsellgren]

I've been tasked with testing switches at the moment. I have no reason to believe they are defect, but I have to check them thoroughly.

[Steve Fuller · Accepted solution]

So what you're trying to do is called a snake test.

This is where traffic will ingress port 1, be switched across the switch backplane to egress port 2, which being externally connected via some form of cross-over cable to port 3, will see the traffic ingress on port 3, through the backplane to port 4, and so on for as many ports as you wish to test.

The ASCII art setup for an imaginary 8-port switch would be as follows:

|-<- gi1/1 (Vlan2) -<- traffic generator tx
|
|->- gi1/2 (Vlan2) ->-|
                      | x-over cable
|-<- gi1/3 (Vlan3) -<-|
|
|->- gi1/4 (Vlan3) ->-|
                      | x-over cable
|-<- gi1/5 (Vlan4) -<-|
|
|->- gi1/6 (Vlan4) ->-|
                      | x-over cable
|-<- gi1/7 (Vlan5) -<-|
|
|->- gi1/8 (Vlan5) ->- traffic generator tx

The key to the configuration is a deliberate mismatch of VLANs on the ports connected via the cross-over cables. So for the above we would have a configuration as follows:

!

interface gi1/1

switchport mode access

switchport access vlan 2

!

interface gi1/2

switchport mode access

switchport access vlan 2

!

interface gi1/3

switchport mode access

switchport access vlan 3

!

interface gi1/4

switchport mode access

switchport access vlan 3

!

interface gi1/5

switchport mode access

switchport access vlan 4

!

interface gi1/6

switchport mode access

switchport access vlan 4

!

interface gi1/7

switchport mode access

switchport access vlan 5

!

interface gi1/8

switchport mode access

switchport access vlan 5

!

There's no routing here, so although we have switchports configured in different VLANs, as far as the traffic generator is concerned the IP address of both the transmit and receive interfaces are in the same subnet.

I suspect where you're going wrong at the moment is that you have the traffic generator Tx and Rx ports in the same VLAN. This would mean that traffic ingress gi1/1 is sent directly via the switch backplane to gi1/8. The important point is that the traffic generator Tx and Rx ports must be in different VLANs such that the only path between them is via the ports you wish to test.

Regards

Message was edited by: Steve Fuller Added HTML tags to format ASCII art correctly

[Peter Paluch · Accepted solution]

Hello Steve,

Looks nice I would also suggest deactivating CDP to stop complaining about native VLAN mismatch, and assuming there is no physical loop, also deactivating the STP as it also may not like being tricked into this kind of topology, i.e.:

no cdp run

no spanning-tree vlan 1-4094

Best regards,

Peter

[marcsellgren]

I see now what I did wrong, I assumed one _had_ to set ip addresses for the VLANs and since it's not possible to put two different VLANs in the same subnet when assigning them IP addresses, they wouldn't communicate. So I thought maybe there was a way to achieve this by trunking and creating etherchannels, but I never got that to work either.

Well, anyhow, that is exactly what I was looking for! Hats off to you my good sir!

Best regards, Marc