There is a whole lot there in that Topology to get to, but it really just committing to memory the logic of how each switch must be configured appropriately, as for RSPAN you will see the Destination is not that Listener port but rather a Transit VLAN to carry that traffic back to our Listener Port!
**Switch Note I’ve found working with my home lab, is that sometimes Int VLAN1 will go to Admin Down while configuring new VLANs, and need to be “no shut” on int VLAN 1 to bring it back up.
Another important note for Exam day, Trunk links and Port-Channels can be a “source” for a monitor session, but NOT a destination (like a VLAN configured for remote SPAN or RSPAN).
Not sure if this will show in the exam room, but I’ve run into it enough times it is worth noting for exam day.**
A brief review of SPAN / RSPAN stuff before we get to configuration lab!
This will be bullet point style as any elaboration will be done during labbing:
- SPAN Source = This will Always be the target interface / VLAN / etc that you want to monitor traffic on that will be sent to the Destination Port / RSPAN VLAN
- Span Destination = Where to send traffic to reach its “listening” port, this will vary between SPAN and RSPAN
- Maximum of 66 SPAN instances can be run on a single switch
- Destination Port will be unusable (mostly) except for receiving SPAN traffic!
- RSPAN Requires Layer 2 Trunks that allows your RSPAN VLAN to traverse all links to your Destination, so watch out for VTP / Manual pruning!
- One Destination interface per SPAN Instance!
That last point is important to remember the detail of, that you can have multiple Destination Ports for the same Instance of SPAN, however you can NOT point your SPAN configuration at a Destination Port already in use by another SPAN session #!
Important to know that difference for easy points on Exam Day!!!
With the basics down and clear as mud, lets bring some clarity to it with labbing!
First off we’ll look at SPAN (local config), and take a look at TX traffic talking from Int Fa1/0/1, and send it to our Destination / Listener on Fa1/0/6:
SW1 SPAN Source Config:
SW1(config)#monitor session ?
<1-66> SPAN session number
SW1(config)#monitor session 1 ?
destination SPAN destination interface or VLAN
filter SPAN filter VLAN
source SPAN source interface, VLAN
SW1(config)#monitor session 1 source ?
interface SPAN source interface
remote SPAN source Remote
vlan SPAN source VLAN
SW1(config)#monitor session 1 source int ?
FastEthernet FastEthernet IEEE 802.3
GigabitEthernet GigabitEthernet IEEE 802.3z
Port-channel Ethernet Channel of interfaces
SW1(config)#monitor session 1 source int fa1/0/1 ?
, Specify another range of interfaces
– Specify a range of interfaces
both Monitor received and transmitted traffic
rx Monitor received traffic only
tx Monitor transmitted traffic only
<cr>
SW1(config)#monitor session 1 source int fa1/0/1 – 2 ?
, Specify another range of interfaces
both Monitor received and transmitted traffic
rx Monitor received traffic only
tx Monitor transmitted traffic only
<cr>
SW1(config)#monitor session 1 source int fa1/0/1 – 2 both
SW1(config)#
So we could have use commas to pick out specific ports rather than a range, but its good to know that you do NOT use the “range” word in SPAN config, you just add the dash on “SOURCE PORTS” as we will see what happens when we try this on Destinations!
Speaking of configuring our Destination port on SW1:
SW1 SPAN Destination Config:
SW1(config)#monitor session 1 destination ?
interface SPAN destination interface
remote SPAN destination Remote
SW1(config)#monitor session 1 destination int ?
FastEthernet FastEthernet IEEE 802.3
GigabitEthernet GigabitEthernet IEEE 802.3z
SW1(config)#monitor session 1 destination int fa1/0/6 ?
, Specify another range of interfaces
– Specify a range of interfaces
encapsulation Set encapsulation for destination interface
ingress Enable ingress traffic forwarding
<cr>
SW1(config)#monitor session 1 destination int fa1/0/6 – 8 ?
, Specify another range of interfaces
encapsulation Set encapsulation for destination interface
ingress Enable ingress traffic forwarding
<cr>
SW1(config)#monitor session 1 destination int fa1/0/6
SW1(config)#
I first wanted to demonstrate that it will indeed take a range of multiple Destinations to my surprise, I thought the rule is one per instance, but it did not throw errors when I configured / unconfigured it (not shown here) so it must work I suppose.
So for exam day, multiple Source and Destination ports it appears.
One other thing, the (mostly) part of a Destination port being usable, is in the word shown as a sub-command modifier “ingress” at the tail end, which allows the device hooked to this port to have normal Internet communication on that VLAN:
SW1 Ingress Configuration:
SW1(config)#monitor session 1 destination int fa1/0/6 ingress ?
dot1q ingress forwarding using dot1q encapsulation
isl ingress forwarding using isl encapsulation
untagged ingress forwarding using untagged encapsulation
vlan Set default VLAN for untagged ingress traffic
SW1(config)#monitor session 1 destination int fa1/0/6 ingress vlan ?
<1-4094> Default VLAN for untagged ingress traffic
SW1(config)#monitor session 1 destination int fa1/0/6 ingress vlan 1 ?
<cr>
SW1(config)#monitor session 1 destination int fa1/0/6 ingress vlan 1
SW1(config)#
There is no specific reason I chose VLAN 1, at first I thought you probably couldn’t send normal traffic over interfaces in the same VLAN you are monitoring, but tried it:
SW1(config)#monitor session 1 destination int fa1/0/6 ingress vlan 10
SW1(config)#
And it worked! This lab is full of surprises so far, hopefully they all stay good!
Verification Commands for SPAN Session # 1:
SW1#sh monitor
Session 1
———
Type : Local Session
Source Ports : <—- Whhaaaa?
Both : Fa1/0/1-2
Destination Ports : Fa1/0/6
Encapsulation : Native
Ingress : Enabled, default VLAN = 10
Ingress encap : Untagged
SW1#
Couple of mysteries here I need to debunk, it appears “Source Ports:” is empty, but below it shows Both: and our source ports, also the Encap types in Pink will use the Native VLAN on the switch if not specified for their “non-SPAN traffic”
Changing Source ports to Tx only on SW1 to review output:
SW1(config)#monitor session 1 source int fa1/0/1 – 2 tx
SW1(config)#do sh mon
Session 1
———
Type : Local Session
Source Ports :
TX Only : Fa1/0/1-2
Destination Ports : Fa1/0/6
Encapsulation : Native
Ingress : Enabled, default VLAN = 10
Ingress encap : Untagged
SW1(config)#
So the “Source Ports:” is really just a header, and under it you can See Tx / Rx / Both info.
Got it!
So lets take a look at our Destination Interface, as I said it will be mostly unusable:
SW1(config)#do sh int fa1/0/6
FastEthernet1/0/6 is up, line protocol is down (monitoring)
This is kind of a mystery to me with the ingress command I haven’t really fully worked with outside of labbing, I am not sure how you can have internet connectivity on a port with the line protocol down – But I don’t care enough to dig deep into that this AM.
Point here is a port that is Up/Down (Monitoring), you have a SPAN Destination Port!
Without further ado, lets get into RSPAN, as it is a bit trickier to work with!
Its really not too difficult, but its easy to forget, so please don’t just read this but lab it a few times to really get an understanding of what goes where for exam day success!
First we want to configure VLAN 300 for RSPAN Traffic on both switches:
SW1 / SW2 both configs quick:
SW1(config)#vlan 300
SW1(config-vlan)#remote-span ?
<cr>
SW1(config-vlan)#remote-span
SW1(config-vlan)#
ASR#2
[Resuming connection 2 to sw2 … ]
SW2(config)#vlan 300
SW2(config-vlan)#remote-span
SW2(config-vlan)#
Easy Peasy!
Now we want to make an Instance 2, which maps SW2 Int Fa1/0/2 to Destination Port Fa1/0/6, however we will need to configure it to ride over our newly constructed RSPAN VLAN to make it there:
SW2 Source Configuration:
SW2(config)#monitor session 2 ?
destination SPAN destination interface or VLAN
filter SPAN filter VLAN
source SPAN source interface, VLAN
SW2(config)#monitor session 2 source ?
interface SPAN source interface
remote SPAN source Remote
vlan SPAN source VLAN
SW2(config)#monitor session 2 source int fa1/0/2 ?
, Specify another range of interfaces
– Specify a range of interfaces
both Monitor received and transmitted traffic
rx Monitor received traffic only
tx Monitor transmitted traffic only
<cr>
SW2(config)#monitor session 2 source int fa1/0/2 both ?
<cr>
SW2(config)#monitor session 2 source int fa1/0/2 both
SW Destination Configuration:
SW2(config)#monitor session 2 dest ?
interface SPAN destination interface
remote SPAN destination Remote
SW2(config)#monitor session 2 dest remote ?
vlan Remote SPAN destination RSPAN VLAN
SW2(config)#monitor session 2 dest remote vlan ?
<1006-4094> Remote SPAN destination extended RSPAN VLAN number
<2-1001> Remote SPAN destination RSPAN VLAN number
SW2(config)#monitor session 2 dest remote vlan 300 ?
<cr>
SW2(config)#monitor session 2 dest remote vlan 300
SW2(config)#
Verification from SW2:
SW2(config)#do show mon
Session 2
———
Type : Remote Source Session
Source Ports :
Both : Fa1/0/2
Dest RSPAN VLAN : 300
Pretty straight forward. Monitor Session 2, Source Fa1/0/2, Destination VLAN 300.
We will just configure that in reverse on SW1, and we should be good to go!
SW1 Source Configuration:
SW1(config)#monitor session 2 source ?
interface SPAN source interface
remote SPAN source Remote
vlan SPAN source VLAN
SW1(config)#monitor session 2 source vlan ?
<1-4094> SPAN source VLAN
SW1(config)#monitor session 2 source vlan 300 ?
, Specify another range of VLANs
– Specify a range of VLANs
both Monitor received and transmitted traffic
rx Monitor received traffic only
tx Monitor transmitted traffic only
<cr>
SW1(config)#monitor session 2 source vlan 300
I would use the <cr> unless explicitly stated not to, as this will accept Tx only, Rx only, or Both SPAN traffic types, where as putting in “Both” will not capture Tx or Rx only traffic.
^ Another very important detail for easy points on exam day (and the real world)!
SW1 Destination Configuration:
SW1(config)#monitor session 2 destination ?
interface SPAN destination interface
remote SPAN destination Remote
SW1(config)#monitor session 2 dest ?
interface SPAN destination interface
remote SPAN destination Remote
SW1(config)#monitor session 2 dest int ?
FastEthernet FastEthernet IEEE 802.3
GigabitEthernet GigabitEthernet IEEE 802.3z
SW1(config)#monitor session 2 dest int fa1/0/6 ?
, Specify another range of interfaces
– Specify a range of interfaces
encapsulation Set encapsulation for destination interface
ingress Enable ingress traffic forwarding
<cr>
SW1(config)#monitor session 2 dest int fa1/0/6
% Interface(s) Fa1/0/6 already configured as monitor destinations in other monitor sessions <<<—- EHHHH WRONG ANSWER! This is running Monitor Session 1!
SW1(config)#
Wanted to demonstrate that to really drive the point home, you can not map different SPAN sessions to one currently in use by a different SPAN Instance, which you can verify with either “sh monitor” or “sh int #” to verify it is already in monitor mode.
So I added another Destination port so we may wrap this up here:
SW1(config)#
*Mar 1 02:26:27.284: %LINK-3-UPDOWN: Interface FastEthernet1/0/7, changed state to up
*Mar 1 02:26:28.291: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/7, changed state to up
SW1(config)#monitor session 2 dest int fa1/0/7
Perfection! Now to verify on SW1 the SPAN / RSPAN verification:
SW1 Verification:
SW1(config)#do sh mon
Session 1
———
Type : Local Session
Source Ports :
TX Only : Fa1/0/1-2
Destination Ports : Fa1/0/6
Encapsulation : Native
Ingress : Enabled, default VLAN = 10
Ingress encap : Untagged
Session 2
———
Type : Local Session <— Local?
Source VLANs :
Both : 300
Destination Ports : Fa1/0/7
Encapsulation : Native
Ingress : Disabled
SW1(config)#
That all looks great, except why is it showing Local Session, when we configured a Remote Span Monitor Session? To troubleshoot I’ll first hop on SW2 to look at its output for Monitor Session 2:
SW2 Verification:
SW2#sh mon
Session 2
———
Type : Remote Source Session
Source Ports :
Both : Fa1/0/2
Dest RSPAN VLAN : 300
SW2#
There it is, so because we didn’t actually use the keyword “remote vlan” anywhere in our configurations as the source was simply “source vlan 300” on SW1, it will not display as a Remote SPAN session – Watch out for this trickery on exam day cause that is the little niche information that I would expect Cisco to try to pull a fast one on you with!
A quick glimpse at VSPAN, just so you’re aware how its configured (exact same)
Instead of using an Interface as your Source, you would use a VLAN # instead:
SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#monitor session 3 ?
destination SPAN destination interface or VLAN
filter SPAN filter VLAN
source SPAN source interface, VLAN
SW2(config)#monitor session 3 source ?
interface SPAN source interface
remote SPAN source Remote
vlan SPAN source VLAN
SW2(config)#monitor session 3 source vlan ?
<1-4094> SPAN source VLAN
SW2(config)#monitor session 3 source vlan 5 ?
, Specify another range of VLANs
– Specify a range of VLANs
both Monitor received and transmitted traffic
rx Monitor received traffic only
tx Monitor transmitted traffic only
<cr>
SW2(config)#monitor session 3 source vlan 5 both
I’m not going to fully configure this, but if you see a VLAN being configured as the “Source” for traffic, you are looking at VSPAN (which monitor VLAN traffic).
This is going to be another area for a Cisco gotcha, I could see a multiple choice asking what type of span session you are configuring based on the following command, but now you will know that Source = VSPAN and Destination = RSPAN when it comes to VLANs!
I am not sure why anyone would ever want to try to capture ANY type of traffic from an entire VLAN, but it is a configuration option for SPAN, but it is just simply using a VLAN # instead of an interface as your SPAN Source.
And that is all there is to it!
If your RSPAN crosses 20 different switches for the Source to reach its Destination, you will need to configure the RSPAN VLAN on each of them with the 2 following commands:
SW2(config)#vlan 500
SW2(config-vlan)#remote-span
SW2(config-vlan)#
Or whatever the # is, also you will need to verify Trunks are not VTP or Manually Pruning that VLAN along the path, and if so take some corrective action!
If you have any follow up questions please share in comments, otherwise, until next time keep on Grinding away until you tackle these exams! 🙂
The DEVNET GRIND! 