Posted: 9/7/2016 8:39:34 PM EDT
|
Company I work for wants to test EMI on a Cisco switch.
<--- Machinist for Company with ccna experience a few years ago and very rusty. 
Is it possible to connect ports on the switch to itself and direct traffic down the line across the physical cables to simulate heavy traffic on the switch without physically connecting to other hosts? Or would there be a better way to do this? Switch is a catalyst 4948e. Any help is much appreciated. Garrett |
|
havent messed with that particular model but should be able to do something like this
create an interface vlan100 or something create an interface vlan101 give them both an address assign outgoing port switchport access vlan 100 on a return port switchport access vlan101 ping [address101] source [address100] size 9000 repeat 100000 show ints and watch for errors. |
|
Quoted:
Not quite sure what they are looking for? Quoted:
Quoted:
EMI from the switch on the environment? Or the effect of EMI from other devices on the switch? Not quite sure what they are looking for? he wants to test building structural cabling to see if equipment will induce errors on the spans. its probably a foot away from a cnc machine or something. |
|
Quoted:
havent messed with that particular model but should be able to do something like this create an interface vlan100 or something create an interface vlan101 give them both an address assign outgoing port switchport access vlan 100 on a return port switchport access vlan101 ping [address101] source [address100] size 9000 repeat 100000 show ints and watch for errors. Wouldn't this only work for two ports at one time? |
|
Quoted:
Wouldn't this only work for two ports at one time? Quoted:
Quoted:
havent messed with that particular model but should be able to do something like this create an interface vlan100 or something create an interface vlan101 give them both an address assign outgoing port switchport access vlan 100 on a return port switchport access vlan101 ping [address101] source [address100] size 9000 repeat 100000 show ints and watch for errors. Wouldn't this only work for two ports at one time? yep, you would have to test a pair of cables and verify then move on to the next pair. you would have to physically loop the cable back to itself at the far end now that I think about it, it wont work because the switch probably wont let you assign two addresses out of the subnet to different interface vlans. let me think about it for a second. |
| Just thinking out loud here... EMI affects UTP cable as it's unshielded... cisco devices don't have any shielding(that I know of ) so if the source was close enough to the rack, it would affect the equipment too. You could test it by setting up wireshark on a port and monitor dropped or resent packets with the EMI source equipment on and off. |
|
my lab equipment let me do it, but its not a switch....
try it. dont know if the commands are the same... not familiar with those switches vlan 100 name test 1 vlan 101 name test 2 int vlan100 ip address 192.168.1.1 255.255.255.0 no shut int vlan101 ip address 192.168.1.2 255.255.255.0 no shut on your physical ints, switchport mode access switchport access vlan [100 or 101] no shut |
|
Best case senario if your switch is configured as a layer 2 device and has a form of Spanning Tree Protocol (PVST or likely MSTP) running, it will block one of the ports if you try to plug in a cable from one switch port to another. Worst cas senario if STP is disabled, you'll loop your network and bring it to its knees.
Now since your switch can also do layer 3 (I.e routing). You could set up routed ports using SVIs or "no switch port" command. This would allow you to do some kind of kludgey inter switch connection without causing a loop, but probably not your best use of time. If you just want something to generate test traffic, I'd reccomed googling and downloading a free program called tfgen. I've been using it for years to generate test traffic. Fire it up on a Windows laptop and plug that into one of your switch ports. Just be careful if you're doing this on a live production environment. You can cause denial of service by generating too much test traffic. Back to the root of of your question though, EMI. Cisco TAC should be able to get you specs on what that particular device is rated for environmental wise. If it's cabling EMI you're worried about, find a good electrical contractor that does data and have them run baselines with a Fluke. HTH! |
|
Quoted:
Best case senario if your switch is configured as a layer 2 device and has a form of Spanning Tree Protocol (PVST or likely MSTP) running, it will block one of the ports if you try to plug in a cable from one switch port to another. Worst cas senario if STP is disabled, you'll loop your network and bring it to its knees. HTH! yeah thats a good point, I was assuming it was a new out of the box switch with nothing plugged in yet. if it has other traffic on it, dont do anything I said, lol. |
|
Quoted:
Wouldn't this only work for two ports at one time? Quoted:
Quoted:
havent messed with that particular model but should be able to do something like this create an interface vlan100 or something create an interface vlan101 give them both an address assign outgoing port switchport access vlan 100 on a return port switchport access vlan101 ping [address101] source [address100] size 9000 repeat 100000 show ints and watch for errors. Wouldn't this only work for two ports at one time? EMI is as difficult to define as it is to measure. You have an isolation room? Calibrated RF source/antenna? If all they are concerned about is if EMI will cause loss of data, then at a minimum you need way to measue data loss. Bit error analyzer or signal integrity meter I have done a lot of EMI testing on Telecomm equipment. What are CISCO's specs? These are just the basic questions you need to answer p.s. I will send a txt to my Brother. He worked for CISCO R&D for many years He may have some insight |
|
Quoted:
yep, you would have to test a pair of cables and verify then move on to the next pair. you would have to physically loop the cable back to itself at the far end now that I think about it, it wont work because the switch probably wont let you assign two addresses out of the subnet to different interface vlans. let me think about it for a second. Quoted:
Quoted:
Quoted:
havent messed with that particular model but should be able to do something like this create an interface vlan100 or something create an interface vlan101 give them both an address assign outgoing port switchport access vlan 100 on a return port switchport access vlan101 ping [address101] source [address100] size 9000 repeat 100000 show ints and watch for errors. Wouldn't this only work for two ports at one time? yep, you would have to test a pair of cables and verify then move on to the next pair. you would have to physically loop the cable back to itself at the far end now that I think about it, it wont work because the switch probably wont let you assign two addresses out of the subnet to different interface vlans. let me think about it for a second. config t Int vlan 100 ip address 10.10.100.1 /24 exit int vlan 101 ip address 10.10.101.1 /24 exit int te 1/0/1 switchport mode access switchport access vlan 100 exit int te 1/0/2 switchport mode access switchport access vlan 101 end Connect a workstation with ip address 10.10.100.2 /24 gateway 10.10.100.1 to int te 1/0/1. Connect a workstation with ip address 10.10.101.2 /24 gateway 10.10.101.1 to int te 1/0/2. Do continuous pings in both directions between the workstations. |
|
Quoted:
Just thinking out loud here... EMI affects UTP cable as it's unshielded... cisco devices don't have any shielding(that I know of ) so if the source was close enough to the rack, it would affect the equipment too. You could test it by setting up wireshark on a port and monitor dropped or resent packets with the EMI source equipment on and off. ^^^This |
|
Quoted:
my lab equipment let me do it, but its not a switch.... try it. dont know if the commands are the same... not familiar with those switches vlan 100 name test 1 vlan 101 name test 2 int vlan100 ip address 192.168.1.1 255.255.255.0 no shut int vlan101 ip address 192.168.1.2 255.255.255.0 no shut on your physical ints, switchport mode access switchport access vlan [100 or 101] no shut Those addresses are in the same subnet. You will need to use IPs from different subnets on different VLANs and allow the switch to route between the subnets. Other then that, it should work just fine. |
|
Quoted:
There are a lot of Test Labs. Many good ones in Cali Is sending it to one of them an option? Quoted:
Quoted:
Unit is not on a live network, just testing purposes only. There are a lot of Test Labs. Many good ones in Cali Is sending it to one of them an option? I will find out tomorrow, but I believe it is going to a test lab. |
|
Quoted:
Those addresses are in the same subnet. You will need to use IPs from different subnets on different VLANs and allow the switch to route between the subnets. Other then that, it should work just fine. Quoted:
Quoted:
my lab equipment let me do it, but its not a switch.... try it. dont know if the commands are the same... not familiar with those switches vlan 100 name test 1 vlan 101 name test 2 int vlan100 ip address 192.168.1.1 255.255.255.0 no shut int vlan101 ip address 192.168.1.2 255.255.255.0 no shut on your physical ints, switchport mode access switchport access vlan [100 or 101] no shut Those addresses are in the same subnet. You will need to use IPs from different subnets on different VLANs and allow the switch to route between the subnets. Other then that, it should work just fine. Wouldn't that just route across the backplane though and not across the physical cables? Tried a similar setup earlier today. |
|
Quoted:
I will find out tomorrow, but I believe it is going to a test lab. Quoted:
Quoted:
Quoted:
Unit is not on a live network, just testing purposes only. There are a lot of Test Labs. Many good ones in Cali Is sending it to one of them an option? I will find out tomorrow, but I believe it is going to a test lab. I use NTS in Plano, Texas They have Cali labs. Knowledgable and helpful |
|
Quoted:
Wouldn't that just route across the backplane though and not across the physical cables? Tried a similar setup earlier today. Quoted:
Quoted:
Quoted:
my lab equipment let me do it, but its not a switch.... try it. dont know if the commands are the same... not familiar with those switches vlan 100 name test 1 vlan 101 name test 2 int vlan100 ip address 192.168.1.1 255.255.255.0 no shut int vlan101 ip address 192.168.1.2 255.255.255.0 no shut on your physical ints, switchport mode access switchport access vlan [100 or 101] no shut Those addresses are in the same subnet. You will need to use IPs from different subnets on different VLANs and allow the switch to route between the subnets. Other then that, it should work just fine. Wouldn't that just route across the backplane though and not across the physical cables? Tried a similar setup earlier today. Layer 1 has no concern with what is happening at the higher layers. Once the layer 1 link is up, layer 2 MAC addresses will be sent from the workstations to the switch and stored in the switch's MAC address table. The switch will then perform the layer 3 routing functions between the different IP subnets and associate specific IPs to their specific MACs in the switches ARP table. The pings will most certainly go through the cables that connect the workstations to the switch as long as you are not blocking ICMP with an ACL. |
|
Quoted:
Company I work for wants to test EMI on a Cisco switch. <--- Machinist for Company with ccna experience a few years ago and very rusty.
Is it possible to connect ports on the switch to itself and direct traffic down the line across the physical cables to simulate heavy traffic on the switch without physically connecting to other hosts? Or would there be a better way to do this? Switch is a catalyst 4948e. Any help is much appreciated. Garrett EMI has in Cisco's EMI software version versus SMI? In that case, EMI is layer 3 routing. -or- Electro-magnetic interference? If it's traffic you want, and cannot afford a traffic simulator, then just get some servers connected and use flood ping. Are they planning on testing the EMI of the switch, the cables, or both. They will need a screen room to produce any thing close to accurate measurements. The copper cables fully connected are going to skew results of the switch as well. |
|
Quoted:
Layer 1 has no concern with what is happening at the higher layers. Once the layer 1 link is up, layer 2 MAC addresses will be sent from the workstations to the switch and stored in the switch's MAC address table. The switch will then perform the layer 3 routing functions between the different IP subnets and associate specific IPs to their specific MACs in the switches ARP table. The pings will most certainly go through the cables that connect the workstations to the switch as long as you are not blocking ICMP with an ACL. Quoted:
Quoted:
Quoted:
Quoted:
my lab equipment let me do it, but its not a switch.... try it. dont know if the commands are the same... not familiar with those switches vlan 100 name test 1 vlan 101 name test 2 int vlan100 ip address 192.168.1.1 255.255.255.0 no shut int vlan101 ip address 192.168.1.2 255.255.255.0 no shut on your physical ints, switchport mode access switchport access vlan [100 or 101] no shut Those addresses are in the same subnet. You will need to use IPs from different subnets on different VLANs and allow the switch to route between the subnets. Other then that, it should work just fine. Wouldn't that just route across the backplane though and not across the physical cables? Tried a similar setup earlier today. Layer 1 has no concern with what is happening at the higher layers. Once the layer 1 link is up, layer 2 MAC addresses will be sent from the workstations to the switch and stored in the switch's MAC address table. The switch will then perform the layer 3 routing functions between the different IP subnets and associate specific IPs to their specific MACs in the switches ARP table. The pings will most certainly go through the cables that connect the workstations to the switch as long as you are not blocking ICMP with an ACL. That's my problem though. No work stations will be plugged into switch. Just one port to the next patched together (not my idea). Was just asked if it is possible. |
|
Quoted:
EMI has in Cisco's EMI software version versus SMI? In that case, EMI is layer 3 routing. -or- Electro-magnetic interference? If it's traffic you want, and cannot afford a traffic simulator, then just get some servers connected and use flood ping. Quoted:
Quoted:
Company I work for wants to test EMI on a Cisco switch. <--- Machinist for Company with ccna experience a few years ago and very rusty.
Is it possible to connect ports on the switch to itself and direct traffic down the line across the physical cables to simulate heavy traffic on the switch without physically connecting to other hosts? Or would there be a better way to do this? Switch is a catalyst 4948e. Any help is much appreciated. Garrett EMI has in Cisco's EMI software version versus SMI? In that case, EMI is layer 3 routing. -or- Electro-magnetic interference? If it's traffic you want, and cannot afford a traffic simulator, then just get some servers connected and use flood ping. Yes, it's for electro-magnetic interference. That was their plan, but didn't want to attach all ports to their own nic card. |
|
Quoted:
Those addresses are in the same subnet. You will need to use IPs from different subnets on different VLANs and allow the switch to route between the subnets. Other then that, it should work just fine. Quoted:
Quoted:
my lab equipment let me do it, but its not a switch.... try it. dont know if the commands are the same... not familiar with those switches vlan 100 name test 1 vlan 101 name test 2 int vlan100 ip address 192.168.1.1 255.255.255.0 no shut int vlan101 ip address 192.168.1.2 255.255.255.0 no shut on your physical ints, switchport mode access switchport access vlan [100 or 101] no shut Those addresses are in the same subnet. You will need to use IPs from different subnets on different VLANs and allow the switch to route between the subnets. Other then that, it should work just fine. Yes, creating the second VLAN would fail and the console would produce an error. Maybe a typo in both subnet masks, or octet of an IP address? Plus, for a standalone switch, routing needs to be enabled. Plus, if it's an older switch with older IOS, the "ip default gateway" command needs to be deleted prior to enabling routing. There was a guy on here years ago who was trying to enable routing but it was failing. He forgot to delete that first. Don't know if anyone helped him, or he got it working. Never returned to his post. |
|
I would just use a laptop on one end of the cable and switch on the other.
Clear your counters on the switch. Ping the laptop repeatedly. Check your counters. Now you have a baseline, which should include no errors. Clear the counters, and now try the same thing while inducing EMI. Record counter errors after each test. Is that sort of what you want? I may be wrong but I don't think you'll get the traffic to rely on the cable if you use the same switch on separate VLAN's because it will use the switch fabric, not the cable to go between the ports. |
|
Quoted:
I would just use a laptop on one end of the cable and switch on the other. Clear your counters on the switch. Ping the laptop repeatedly. Check your counters. Now you have a baseline, which should include no errors. Clear the counters, and now try the same thing while inducing EMI. Record counter errors after each test. Is that sort of what you want? Kinda, but to include most of the switch ports at once. Not just the port connected to the laptop. Not sure if I am making any sense? |
|
Quoted:
havent messed with that particular model but should be able to do something like this create an interface vlan100 or something create an interface vlan101 give them both an address assign outgoing port switchport access vlan 100 on a return port switchport access vlan101 ping [address101] source [address100] size 9000 repeat 100000 show ints and watch for errors. It might help to set the timeout interval to 0. Just a thought. |
|
Quoted:
Kinda, but to include most of the switch ports at once. Not just the port connected to the laptop. Not sure if I am making any sense? Quoted:
Quoted:
I would just use a laptop on one end of the cable and switch on the other. Clear your counters on the switch. Ping the laptop repeatedly. Check your counters. Now you have a baseline, which should include no errors. Clear the counters, and now try the same thing while inducing EMI. Record counter errors after each test. Is that sort of what you want? Kinda, but to include most of the switch ports at once. Not just the port connected to the laptop. Not sure if I am making any sense? EMI will be induced on the cable, not the switch, so it shouldn't matter which switch ports are used right? You can assume it would affect all ports the same (cause errors). |
|
Cetecom is in Milpitas and San Diego. I have worked with them a bit. There is giant Serbian(croat?) who is very helpful there. I bet they have tested gobs of Cisco stuff.
http://www.cetecom.com/en.html Also, bear in mind all cable is not created equal! It is one of the reasons Panduit sells like all sorts of grades. Its not just EMI but also cross-talk between cables. |
|
You people are over thinking this. Turn off portfast and bpduguard, put all switch ports in same vlan and build vsi on .1. Plug the other ends of the cable into a cheap netgear hub. Ping .255. Like magic, traffic. If you want to do it right use a couple of hosts and iperf/jperf. But what you you really trying to look for EMI wise? I have deployee a ton of ethernet in industrial environments and it does just fine. Almost without exception avoid shielded cat5 and you will be fine. |
|
Quoted:
Kinda, but to include most of the switch ports at once. Not just the port connected to the laptop. Not sure if I am making any sense? Quoted:
Quoted:
I would just use a laptop on one end of the cable and switch on the other. Clear your counters on the switch. Ping the laptop repeatedly. Check your counters. Now you have a baseline, which should include no errors. Clear the counters, and now try the same thing while inducing EMI. Record counter errors after each test. Is that sort of what you want? Kinda, but to include most of the switch ports at once. Not just the port connected to the laptop. Not sure if I am making any sense? Yep You make a lot of sense To do the measurement properly you need to terminate the cables outside of the room/area of influence of the device being tested If it is possible to re-route them back ( not my area) you would not know if it is the cables or the instrument that was more susceptable The right equipment is $100s of thousands of dollars Hell, even cheap equipment is 10s of thousands used |
|
Quoted:
Cetecom is in Milpitas and San Diego. I have worked with them a bit. There is giant Serbian(croat?) who is very helpful there. I bet they have tested gobs of Cisco stuff. http://www.cetecom.com/en.html Also, bear in mind all cable is not created equal! It is one of the reasons Panduit sells like all sorts of grades. Its not just EMI but also cross-talk between cables. Alien crosstalk |
|
Quoted:
Yes, creating the second VLAN would fail and the console would produce an error. Maybe a typo in both subnet masks, or octet of an IP address? Plus, for a standalone switch, routing needs to be enabled. Plus, if it's an older switch with older IOS, the "ip default gateway" command needs to be deleted prior to enabling routing. There was a guy on here years ago who was trying to enable routing but it was failing. He forgot to delete that first. Don't know if anyone helped him, or he got it working. Never returned to his post. Quoted:
Quoted:
Quoted:
my lab equipment let me do it, but its not a switch.... try it. dont know if the commands are the same... not familiar with those switches vlan 100 name test 1 vlan 101 name test 2 int vlan100 ip address 192.168.1.1 255.255.255.0 no shut int vlan101 ip address 192.168.1.2 255.255.255.0 no shut on your physical ints, switchport mode access switchport access vlan [100 or 101] no shut Those addresses are in the same subnet. You will need to use IPs from different subnets on different VLANs and allow the switch to route between the subnets. Other then that, it should work just fine. Yes, creating the second VLAN would fail and the console would produce an error. Maybe a typo in both subnet masks, or octet of an IP address? Plus, for a standalone switch, routing needs to be enabled. Plus, if it's an older switch with older IOS, the "ip default gateway" command needs to be deleted prior to enabling routing. There was a guy on here years ago who was trying to enable routing but it was failing. He forgot to delete that first. Don't know if anyone helped him, or he got it working. Never returned to his post. Would it? I don't know, I'm going to try it in my lab tomorrow |
|
Quoted: Would it? I don't know, I'm going to try it in my lab tomorrow Quoted: Quoted: Quoted: Quoted: my lab equipment let me do it, but its not a switch.... try it. dont know if the commands are the same... not familiar with those switches vlan 100 name test 1 vlan 101 name test 2 int vlan100 ip address 192.168.1.1 255.255.255.0 no shut int vlan101 ip address 192.168.1.2 255.255.255.0 no shut on your physical ints, switchport mode access switchport access vlan [100 or 101] no shut Those addresses are in the same subnet. You will need to use IPs from different subnets on different VLANs and allow the switch to route between the subnets. Other then that, it should work just fine. Yes, creating the second VLAN would fail and the console would produce an error. Maybe a typo in both subnet masks, or octet of an IP address? Plus, for a standalone switch, routing needs to be enabled. Plus, if it's an older switch with older IOS, the "ip default gateway" command needs to be deleted prior to enabling routing. There was a guy on here years ago who was trying to enable routing but it was failing. He forgot to delete that first. Don't know if anyone helped him, or he got it working. Never returned to his post. Would it? I don't know, I'm going to try it in my lab tomorrow It won't let you add second IP address unless it is in different VRF. Depending on IOS level it may not let you create second VSI or will shutdown the first. |
|
<--- CCIE here, (and part-time hobby machinist - not that that matters any)
Do something like this: First, turn off CDP on the switch, because otherwise, it's going to throw a hissy fit about mismatched VLANs when we start doing wacky shit: no cdp run If this were a chassis-based 4500, you would have auto MDIX support on the ports, and could use regular cables. But the 4948 doesn't do auto MDIX, so you're going to have to get or make a bunch of crossover cables. Connect Gig1/1 to Gig1/2. Connect Gig1/3 to Gig1/4. Etc, for as many ports as you want. Finally, connect your last port (let's say it's Gig1/5) to Fa1 (the management port). We're going to use this, because it's in a different VRF. Then, drop this configuration on the switch: vlan 10 vlan 11 vlan 12 ! int FastEthernet1 ip vrf forwarding mgmtVrf ip address 10.1.1.2 no shutdown ! interface vlan10 ip address 10.1.1.1 255.255.255.0 no shutdown ! interface GigabitEthernet1/1 switchport switchport mode access switchport access vlan 10 no shutdown ! interface GigabitEthernet1/2 switchport switchport mode access switchport access vlan 11 no shutdown ! interface GigabitEthernet1/3 switchport switchport mode access switchport access vlan 11 no shutdown ! interface GigabitEthernet1/4 switchport switchport mode access switchport access vlan 12 no shutdown ! interface GigabitEthernet1/5 switchport switchport mode access switchport access vlan 12 no shutdown Now, from the switch CLI, ping 10.1.1.2. Traffic should go out Vlan10, which is out Gig1/1 - and come back in on Gig1/2. At first, it will be a broadcast (ARP), so the switch will unicast flood to port 1/3 (same VLAN). That will come back in on 1/4, which will flood out to 1/5, which will come back in on Fa1 (the management VRF), who will answer the ARP for 10.1.1.2. Now the switch will have L2 forwarding information for that MAC address, an entry in each VLAN. You should get an ICMP response, as the switch is pinging itself, with the traffic flowing over all connected ports. Then, if you want to ratchet up the traffic, you can do a flood-ping (don't expect a lot of responses back - you're going to drop a metric shit-ton of packets in the process, but it'll put a nice amount of traffic over the wires): ping ip 10.1.1.2 repeat 100000000 size 1476 timeout 0 If, for some reason, you want to send the traffic the other way, it's just a matter of pinging the Vlan10 interface from the management VRF: ping vrf mgmtVrf 10.1.1.1 |
|
Quoted:
<--- CCIE here, (and part-time hobby machinist - not that that matters any) Do something like this: First, turn off CDP on the switch, because otherwise, it's going to throw a hissy fit about mismatched VLANs when we start doing wacky shit: If this were a chassis-based 4500, you would have auto MDIX support on the ports, and could use regular cables. But the 4948 doesn't do auto MDIX, so you're going to have to get or make a bunch of crossover cables. Connect Gig1/1 to Gig1/2. Connect Gig1/3 to Gig1/4. Etc, for as many ports as you want. Finally, connect your last port (let's say it's Gig1/5) to Fa1 (the management port). We're going to use this, because it's in a different VRF. Then, drop this configuration on the switch: Now, from the switch CLI, ping 10.1.1.2. Traffic should go out Vlan10, which is out Gig1/1 - and come back in on Gig1/2. At first, it will be a broadcast (ARP), so the switch will unicast flood to port 1/3 (same VLAN). That will come back in on 1/4, which will flood out to 1/5, which will come back in on Fa1 (the management VRF), who will answer the ARP for 10.1.1.2. Now the switch will have L2 forwarding information for that MAC address, an entry in each VLAN. You should get an ICMP response, as the switch is pinging itself, with the traffic flowing over all connected ports. Then, if you want to ratchet up the traffic, you can do a flood-ping (don't expect a lot of responses back - you're going to drop a metric shit-ton of packets in the process, but it'll put a nice amount of traffic over the wires): ping ip 10.1.1.2 repeat 100000000 size 1476 timeout 0 If, for some reason, you want to send the traffic the other way, it's just a matter of pinging the Vlan10 interface from the management VRF: ping vrf mgmtVrf 10.1.1.1 Quoted:
<--- CCIE here, (and part-time hobby machinist - not that that matters any) Do something like this: First, turn off CDP on the switch, because otherwise, it's going to throw a hissy fit about mismatched VLANs when we start doing wacky shit: no cdp run If this were a chassis-based 4500, you would have auto MDIX support on the ports, and could use regular cables. But the 4948 doesn't do auto MDIX, so you're going to have to get or make a bunch of crossover cables. Connect Gig1/1 to Gig1/2. Connect Gig1/3 to Gig1/4. Etc, for as many ports as you want. Finally, connect your last port (let's say it's Gig1/5) to Fa1 (the management port). We're going to use this, because it's in a different VRF. Then, drop this configuration on the switch: vlan 10 vlan 11 vlan 12 ! int FastEthernet1 ip vrf forwarding mgmtVrf ip address 10.1.1.2 no shutdown ! interface vlan10 ip address 10.1.1.1 255.255.255.0 no shutdown ! interface GigabitEthernet1/1 switchport switchport mode access switchport access vlan 10 no shutdown ! interface GigabitEthernet1/2 switchport switchport mode access switchport access vlan 11 no shutdown ! interface GigabitEthernet1/3 switchport switchport mode access switchport access vlan 11 no shutdown ! interface GigabitEthernet1/4 switchport switchport mode access switchport access vlan 12 no shutdown ! interface GigabitEthernet1/5 switchport switchport mode access switchport access vlan 12 no shutdown Now, from the switch CLI, ping 10.1.1.2. Traffic should go out Vlan10, which is out Gig1/1 - and come back in on Gig1/2. At first, it will be a broadcast (ARP), so the switch will unicast flood to port 1/3 (same VLAN). That will come back in on 1/4, which will flood out to 1/5, which will come back in on Fa1 (the management VRF), who will answer the ARP for 10.1.1.2. Now the switch will have L2 forwarding information for that MAC address, an entry in each VLAN. You should get an ICMP response, as the switch is pinging itself, with the traffic flowing over all connected ports. Then, if you want to ratchet up the traffic, you can do a flood-ping (don't expect a lot of responses back - you're going to drop a metric shit-ton of packets in the process, but it'll put a nice amount of traffic over the wires): ping ip 10.1.1.2 repeat 100000000 size 1476 timeout 0 If, for some reason, you want to send the traffic the other way, it's just a matter of pinging the Vlan10 interface from the management VRF: ping vrf mgmtVrf 10.1.1.1 Going to try this today. Thank's for all the help! |
|
Quoted:
That's my problem though. No work stations will be plugged into switch. Just one port to the next patched together (not my idea). Was just asked if it is possible. Ohhhhh, now I see! That would be correct, the switch would then route through the backplane, not the external ports/cables. |
|
Quoted:
<--- CCIE here, (and part-time hobby machinist - not that that matters any) Do something like this: First, turn off CDP on the switch, because otherwise, it's going to throw a hissy fit about mismatched VLANs when we start doing wacky shit: If this were a chassis-based 4500, you would have auto MDIX support on the ports, and could use regular cables. But the 4948 doesn't do auto MDIX, so you're going to have to get or make a bunch of crossover cables. Connect Gig1/1 to Gig1/2. Connect Gig1/3 to Gig1/4. Etc, for as many ports as you want. Finally, connect your last port (let's say it's Gig1/5) to Fa1 (the management port). We're going to use this, because it's in a different VRF. Then, drop this configuration on the switch: Now, from the switch CLI, ping 10.1.1.2. Traffic should go out Vlan10, which is out Gig1/1 - and come back in on Gig1/2. At first, it will be a broadcast (ARP), so the switch will unicast flood to port 1/3 (same VLAN). That will come back in on 1/4, which will flood out to 1/5, which will come back in on Fa1 (the management VRF), who will answer the ARP for 10.1.1.2. Now the switch will have L2 forwarding information for that MAC address, an entry in each VLAN. You should get an ICMP response, as the switch is pinging itself, with the traffic flowing over all connected ports. Then, if you want to ratchet up the traffic, you can do a flood-ping (don't expect a lot of responses back - you're going to drop a metric shit-ton of packets in the process, but it'll put a nice amount of traffic over the wires): ping ip 10.1.1.2 repeat 100000000 size 1476 timeout 0 If, for some reason, you want to send the traffic the other way, it's just a matter of pinging the Vlan10 interface from the management VRF: ping vrf mgmtVrf 10.1.1.1 Quoted:
<--- CCIE here, (and part-time hobby machinist - not that that matters any) Do something like this: First, turn off CDP on the switch, because otherwise, it's going to throw a hissy fit about mismatched VLANs when we start doing wacky shit: no cdp run If this were a chassis-based 4500, you would have auto MDIX support on the ports, and could use regular cables. But the 4948 doesn't do auto MDIX, so you're going to have to get or make a bunch of crossover cables. Connect Gig1/1 to Gig1/2. Connect Gig1/3 to Gig1/4. Etc, for as many ports as you want. Finally, connect your last port (let's say it's Gig1/5) to Fa1 (the management port). We're going to use this, because it's in a different VRF. Then, drop this configuration on the switch: vlan 10 vlan 11 vlan 12 ! int FastEthernet1 ip vrf forwarding mgmtVrf ip address 10.1.1.2 no shutdown ! interface vlan10 ip address 10.1.1.1 255.255.255.0 no shutdown ! interface GigabitEthernet1/1 switchport switchport mode access switchport access vlan 10 no shutdown ! interface GigabitEthernet1/2 switchport switchport mode access switchport access vlan 11 no shutdown ! interface GigabitEthernet1/3 switchport switchport mode access switchport access vlan 11 no shutdown ! interface GigabitEthernet1/4 switchport switchport mode access switchport access vlan 12 no shutdown ! interface GigabitEthernet1/5 switchport switchport mode access switchport access vlan 12 no shutdown Now, from the switch CLI, ping 10.1.1.2. Traffic should go out Vlan10, which is out Gig1/1 - and come back in on Gig1/2. At first, it will be a broadcast (ARP), so the switch will unicast flood to port 1/3 (same VLAN). That will come back in on 1/4, which will flood out to 1/5, which will come back in on Fa1 (the management VRF), who will answer the ARP for 10.1.1.2. Now the switch will have L2 forwarding information for that MAC address, an entry in each VLAN. You should get an ICMP response, as the switch is pinging itself, with the traffic flowing over all connected ports. Then, if you want to ratchet up the traffic, you can do a flood-ping (don't expect a lot of responses back - you're going to drop a metric shit-ton of packets in the process, but it'll put a nice amount of traffic over the wires): ping ip 10.1.1.2 repeat 100000000 size 1476 timeout 0 If, for some reason, you want to send the traffic the other way, it's just a matter of pinging the Vlan10 interface from the management VRF: ping vrf mgmtVrf 10.1.1.1 just labbed this up on a 3400 and this guy has it right. I was like why the fuck is he putting it in a VRF, but then I realized it was to force it to not ping across the backplane as mentioned by another guy. (vlans are not necessary, I was trying hard to make it work my way, lol) my config Switch#show run Building configuration... Current configuration : 1710 bytes ! version 12.2 no service pad service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Switch ! boot-start-marker boot-end-marker ! no logging console ! no aaa new-model system mtu routing 1998 ip routing ! ! ip vrf TEST ! ! ! ! ! ! ! spanning-tree mode rapid-pvst spanning-tree extend system-id ! ! vlan internal allocation policy ascending ! vlan 100 name test1 ! vlan 101 name test2 ! ! ! interface FastEthernet0/1 no switchport ip vrf forwarding TEST ip address 192.168.1.1 255.255.255.0 ! interface FastEthernet0/2 no switchport ip address 192.168.1.2 255.255.255.0 ! interface FastEthernet0/3 shutdown ! interface FastEthernet0/4 shutdown ! interface FastEthernet0/5 shutdown ! interface FastEthernet0/6 shutdown ! interface FastEthernet0/7 shutdown ! interface FastEthernet0/8 shutdown ! interface FastEthernet0/9 shutdown ! interface FastEthernet0/10 shutdown ! interface FastEthernet0/11 shutdown ! interface FastEthernet0/12 shutdown ! interface FastEthernet0/13 shutdown ! interface FastEthernet0/14 shutdown ! interface FastEthernet0/15 shutdown ! interface FastEthernet0/16 shutdown ! interface FastEthernet0/17 shutdown ! interface FastEthernet0/18 shutdown ! interface FastEthernet0/19 shutdown ! interface FastEthernet0/20 shutdown ! interface FastEthernet0/21 shutdown ! interface FastEthernet0/22 shutdown ! interface FastEthernet0/23 shutdown ! interface FastEthernet0/24 shutdown ! interface GigabitEthernet0/1 port-type nni ! interface GigabitEthernet0/2 port-type nni ! interface Vlan1 no ip address ! no ip http server ip http secure-server ip classless ! ! ! ! line con 0 line vty 5 15 ! end Switch# Switch#ping vrf TEST 192.168.1.2 size 9000 repeat 10000 Type escape sequence to abort. Sending 10000, 9000-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!. Success rate is 99 percent (206/207), round-trip min/avg/max = 8/9/17 ms Switch#show int fa0/1 | inc packets|errors 5 minute input rate 1222000 bits/sec, 76 packets/sec 5 minute output rate 1223000 bits/sec, 76 packets/sec 56174 packets input, 102777302 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 56173 packets output, 102777238 bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets |
|
Find a local phone or cable tech with a handheld JDSU or T-berd and pay them in beer to bring it by and let it run RFC2544 or y 1568 tests at wire speed over your test circuit. Loading it up with icmp traffic isn't going to yell you a ton about traffic integrity, but it will let you look at the interface for things like crc errors if you suspect layer 0 issues. |
|
try this too, theres a TDR in the switch. this was kicking around in the back of my head but couldnt munge through the commands without googles. your switch should have it built in. Switch#test cable-diagnostics tdr interface fa0/1 Link state may be affected during TDR test TDR test started on interface Fa0/1 A TDR test can take a few seconds to run on an interface Use 'show cable-diagnostics tdr' to read the TDR results. Switch#show cable-diagnostics tdr interface fa0/1 TDR test last run on: March 01 01:08:31 Interface Speed Local pair Pair length Remote pair Pair status --------- ----- ---------- ------------------ ----------- -------------------- Fa0/1 100M Pair A 8 +/- 15 meters Pair A Normal Pair B 8 +/- 15 meters Pair B Normal Pair C N/A Pair C Not Supported Pair D N/A Pair D Not Supported |
|
Just in case anyone stumbles across this post years from now, and is trying to do the same thing... it didn't work exactly as initially configured, because the switch was using the same built-in MAC address for it's management interface (FastEthernet1) as it was for all of it's SVIs (in this case, Vlan10). So, when the switch ARPed for 10.1.1.2 on Vlan10, it got the ARP response back from Fa1, but it was the same MAC as that of Vlan10. So, when it went to switch a packet with a destination of the MAC address of 10.1.1.2, that dest. MAC was it's own SVI, and the traffic went nowhere.
To solve this, we configured an HSRP address of 10.1.1.3 on FastEthernet1. Now when pinging 10.1.1.3 from Vlan10, we get an ARP response of 0000.0c07.ac00, which is different than the burned-in MAC of the SVI, and then we switch that traffic out Gig1/1, in Gig1/2, back out Gig1/3, back in Gig1/4, out Gig1/5, and finally land on Fa1. It worked in AKsala's test, because he used two physical interfaces, which use unique MAC addresses. As usual, it's all this virtual nonsense that creates the additional headaches. Man... the shit you gotta do just to get a switch to flood itself 
|