SPAN not forwarding traffic??

Hey all. Bit stuck on this, hope to get some assistance if possible. I'm working on page 37 of IEWB1 ver 4.

In a nutshell, I have 3 routers connected to SW1, with two of the routers belonging to VLAN 13, while the other router is in the default VLAN. I configured SPAN on SW1 to redirect all incoming traffic from vlan 13 to the interface going to the router in the default VLAN. I tested this by running debug ip packet, to see if it was receiving the packets from VLAN 13, even though it's not a member of VLAN 13. The config I came up with matches the solution by IEWB..but it's just not receiving it.

Since the routers in VLAN 13 are working fine, I'll just post the SW1 config, which has to be where the problem is, I think.

SW1:
monitor session 1 source vlan 13 rx
monitor session 1 destination interface Fa0/5

When I ping from RouterA (VLAN 13) to 255.255.255.255 just like the workbook, I get a response from RouterB (VLAN 13)..which I believe I should be seeing the packet actually had to RouterC (VLAN 1..where SPAN is pointing to).

The odd thing is, RouterC is receiving the CDP packets from Router's A & B, so I know it is redirecting some traffic, just not my ICMP traffic I guess.

Any ideas??

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

cisco_trooper

CDP is layer 2 operating over the native VLAN. How are the router interfaces configured?

Mrock4

I know CDP operates over 1 (Vlan 1, that is), but it still makes no sense. The config seems proper..I don't know.

The two VLAN 13 router interfaces are simply assigned an IP, and that's it. Those are working. The one that isn't is assigned an IP also.

The SW config for each interface is:

f0/1 (RouterA)
switchport access vlan 13

f0/3 (RouterB)
switchport access vlan 13

f0/5 (RouterB..was configured this way)
switchport trunk encap dot1q
switchport mode trunk

I then removed the f0/5 config, since IEWB doesn't have that in there. Nothing changed. I don't think it would need to be a trunk anyways since the idea behind this lab is to redirect traffic from the VLAN it originated from, into a VLAN that it doesn't belong to (in this case, RouterC). I've got to be missing something!! My lab time ended, but when I come up with some ideas I'll fire it up again..

cisco_trooper

You are just trying to get me to buy IEWB....

Mrock4

Maybe..

I'm not entirely challenged (at least to the point I expected) with it, but bear in mind, I've been studying nothing but switching..and I am on the switching portion of it. Once I hit the QoS section I'm going to be hurting.

I'm about to lab it up on that scenario for an hour to figure out what's going on. Another thing with the CDP thing...SW1 is not showing up as a CDP neighbor, but two devices on the other side of SW1 are..meaning CDP traffic is being copied and forwarded regardless. Kind of interesting to see that behavior, because generally you only see directly connected devices.

I will prevail..eventually..

Now go buy IEWB

cisco_trooper

Mrock4 wrote:

Maybe..

I'm not entirely challenged (at least to the point I expected) with it, but bear in mind, I've been studying nothing but switching..and I am on the switching portion of it. Once I hit the QoS section I'm going to be hurting.

I'm about to lab it up on that scenario for an hour to figure out what's going on. Another thing with the CDP thing...SW1 is not showing up as a CDP neighbor, but two devices on the other side of SW1 are..meaning CDP traffic is being copied and forwarded regardless. Kind of interesting to see that behavior, because generally you only see directly connected devices.

I will prevail..eventually..

Now go buy IEWB

You are killing me. We both know what will happen if I get my hands on that right now....

Mrock4

True. I'll be good if I can get this SPAN issue. I'm working on it now, just can't get it for the life of me. I guess we learn more from our failures...I should learn a lot :-/ hah..

kryolla

try connecting a laptop with wireshark and see if any traffic gets captured

networker050184

kryolla wrote:

try connecting a laptop with wireshark and see if any traffic gets captured

+1

Also what type of switch are you running this on?

Mrock4

networker050184 wrote:

kryolla wrote:

try connecting a laptop with wireshark and see if any traffic gets captured

+1

Also what type of switch are you running this on?

These are on 3550's via mindtech's CCIE rack rental.

Upon further investigation, I decided to throw another switch in the mix, to see if it was something on the first 3550. I discovered (after trunking another 3550 with the first), that R5 (with the same config it had on the other link) IS receiving the broadcasts infact. They are not showing up in the debugs, but they are definitely incrementing once I send a broadcast out from R1. It wasn't before on the previous link. Makes me wonder if it was some sort of strange issue with the first 3550.

Since that was on the rental, I can't hook up wireshark, but I am going to play with it a lot more before I move on.

To make it stranger, I used a standard VSPAN on the first switch, and a second VSPAN (with same session ID) on the second..not RSPAN.

It's scenarios like this a real rack is beneficial. I need to begin ordering it looks like..

Mrock4

OK, so to test the theory that the switch might have been acting weird, I switched all of the router configs around, so the router that wasn't receiving anything was now part of VLAN 13, and one of the previous VLAN 13 routers was now the one that should be receiving copies of VLAN 13 traffic....works fine.

The only issue I still have is that I am not getting ANY debug output when there is incoming packets being sent from the SPAN session to this router..any thoughts? The IEWB shows some sample output, but I can't seem to duplicate it. They got it with debug ip packet. Even using "debug all" gets zero debug output..hmm...

Edit: I hate my life. Right after I posted this, I literally made no changes, but to stop debugging, exit out of the router, get back in, debug ip packet/debug ip icmp...ping 255.255.255.255 and I saw my debug output that I was waiting on.

cisco_trooper

this is where live equipment is invaluable. this is how the stuff acts in production.

networker050184

I always try to reboot after any changes (if possible that is why most changes are made after hours). A lot of times you will beat yourself over the head why something is configured correctly but won't work. A simple restart usually fixes it faster than waiting for things to go through on their own.

If you ever get into working with Adtrans remember a reboot is your best friend.

Mrock4

cisco_trooper wrote:

this is where live equipment is invaluable. this is how the stuff acts in production.

Other than using dynamips to experiment, I'm actually planning to continue using mindtech's rentals. Granted, it's remote access to a rack..but it's still a real rack. I just hate the lag.

BTW CT..lost that bid by a LONG ways. Hoping to get my hands on a couple of 3550's and go from there. This is going to be a long, expensive journey.

I appreciate the input guys..