SPAN, RSPAN and ERSPAN

Monitor switchports via span vs rspan vs erspan

I’ve been looking to find a good explanation regarding the three subjected features and apart from the Cisco website where you can find it all written in an extremely technical manner I’ve not been able to find much so I thought I’d make another post this weekend about SPAN cause in the end there’s really not much to it yet however it can be confusing to some besides in case you’re asked to do it in your Lab or at a Customer side , you don’t really want to go and waste time looking it up online :)

SPAN copies traffic from one or more CPUs, one or more ports, one or more EtherChannels, or one or more VLANs, and sends the copied traffic to one or more destinations for analysis by a network analyzer such as a SwitchProbe device or other Remote Monitoring (RMON) probe or Wireshark etc …

The port can be configured to be monitored and then the traffic that is sent or received on that port can be redirected to the port on the same switch (SPAN) or on a different switch (RSPAN) or can be directed to different switches, which provides remote monitoring of multiple switches across your network( ERSPAN) (ERSPAN uses a GRE tunnel to carry traffic between switches.)

=============================================================================
=============================================================================
=============================================================================

SPAN

Recently you’ve been having some problems with R1 or IP Phone or the Server or any of the above devices connected to SW1 and for some reason you can’t telnet or ssh to R1 or to the Server etc  …

Wireshark_PC is your PC or a laptop of course :)

Let’s say something is up with the IP_PHONE and you want to capture all traffic the phone is sending to SW1 and forward a copy of it to you PC where you have your wireshark running , our Local SPAN config will look like this :

Switch1(config)# monitor session 1 source interface FastEthernet 0/15
Switch1(config)# monitor session 1 destination interface FastEthernet0/30

Or maybe there’s a problem with the phone and the printer at the same time , you can do :

Switch1(config)# monitor session 1 source interface FastEthernet 0/11 –   15 both
Switch1(config)# monitor session 1 destination interface FastEthernet0/30

But personally I would split these two into two separate SPAN sessions because otherwise it will be not so eye-friendly to differentiate the traffic unless you’re a Wireshark Guru :)

=============================================================================
=============================================================================
=============================================================================

RSPAN

RSPAN allows you to create a SPAN session on one switch but have the destination of the SPAN be on another switch that is on the same network. Basically you create a special VLAN intended only for transporting SPAN traffic across switches. This comes in handy when the problem you are working on is on a switch in another part of the building or campus that you are in versus where you are at. By doing this type of spanning  you need to be a little more careful than when you SPAN traffic from one port to another on the same switch. The reason is,  it is highly possible that you can saturate the trunk connection between the remote switch and one or more downstream switches that are between you and the switch where the source port resides.

Let’s say R2 this time is playing up and the problem is that R2 is located in a different building or a city to where you’re at so we need to create a VLAN on both switches SW1 and SW2 that will be use for the traffic :

vlan 999
 name RSPAN
 remote-span

switch2(config)# monitor session 1 source interface FastEthernet 0/14
switch2(config)# monitor session 1 destination remote vlan 999

switch1(config)# monitor session 8 source remote vlan 999
switch1(config)# monitor session 8 destination interface FastEthernet0/30

As you can see we’re sending traffic to the remote vlan on SW2 this time and not to the PC because our PC is still connected to SW1 – simple stuff but can get confusing ! :)

Remember to allow the Remote SPAN VLAN you’ve created on the trunk link between the switches then once you’re done with capturing you can remove it.

=============================================================================
=============================================================================
=============================================================================

ERSPAN

ERSPAN is RSPAN with much bigger muscles !  You only a few platforms that support this. I believe only 6509 chassis’s running a SUP720 switch fabric can handle it .ERSPAN uses a GRE
tunnel to carry traffic between switches.

I will cover this one when I start posting stuff about Nexus switches , 6500 series and Data Centre environment !

=============================================================================
=============================================================================
=============================================================================

Below you will find a table what platform supports which SPAN

VTP versions 1 2 3

Difference between VTP versions

VTP version 1:

Supports normal VLAN numbers (1-1001)

Supports pruning of unused VLANs (no longer sends broadcasts and unknown unicasts

supports cleartext and MD5 digest password

VTP version 2:

Forwards the VTP messages without checking the version number or domain in transparent mode

Supports Token Ring

Performs consistency check on the VTP / VLAN parameters (from CLI or SNMP)

Pass on Unrecognised TLVs

VTP version 3:

Supports extended VLAN numbers (1-4095)

Transfer information regarding Private VLAN structure

Support for databases other than VLAN (for example MST)

Protection from unintended database overrides during insertion of new switches

Hidden password protection

Voice Vlan ( Three Methods of Configuring Voice VLANs )

Three Methods of Configuring Voice VLANs | Complete Lab Included

The Voice VLAN feature enables access ports to carry IP voice traffic from an IP phone. When the switch is connected to a Cisco 7960 IP Phone, the phone sends voice traffic with Layer 3 IP precedence and Layer 2 class of service (CoS) values, which are both set to 5 by default.

There are three methods to configure Voice VLANs:

1) Separate the Data VLAN for the PC and the Voice VLAN for the IP phone
2) Use a single VLAN for Data and Voice.
3) Use a single VLAN for Data and Voice but add the 902.1p CoS tag

Network Diagram: Configuring Voice VLANs

OPTION 1
Separate the Data VLAN for the PC and the Voice VLAN for the IP Phone. The internal IP Phone switch will tag VoIP traffic with the respective VLAN number and apply a CoS value of 5. The data frames are set untagged and received by the upstream switch on the configured access VLAN. The connection between the IP Phone and the upstream switch is an 802.1q trunk with the native VLAN equal to the Data VLAN.

SW1:
interface FastEthernet0/2
switchport access vlan 10
switchport voice vlan 800
spanning-tree portfast

Switch: show run int f0/2

OPTION 2
Use a single VLAN for Data and Voice. The IP Phone’s internal switch does not tag the frames and acts as a simple bridge. The connection between the IP Phone and the upstream switch is an access port.

SW1:
interface FastEthernet0/4
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport trunk allowed vlan 10,800
switchport mode trunk
switchport voice vlan 800
spanning-tree portfast trunk
spanning-tree bpdufilter enable

Switch: show run int f0/4

OPTION 3
Use a single VLAN for Data and Voice, but to add an 802.1p CoS tag. Data frames received from the PCon the phone, along with VolP frames sent from the phone get a special 802.1q header that carries a VLAN ID equal to zero and has the CoS field set to 5 for VoIP and the value instructed from the switch for data frames. The Catalyst switch acccepts the frames with VLAN zero as if they are in the access VLAN, but also honors the CoS bits to calculate the switch’s internal QoS tag.

SW1:
interface FastEthernet0/6
switchport access vlan 10
switchport voice vlan dot1p
spanning-tree portfast

Switch: show run int f0/6

Tip: As soon as the switchport Voice VLAN command is applied to the port, the spanning-tree portfast feature is automatically enabled.

Our unique lab format (Qmap) gives you access to step-by-step guide for configuringVoice VLANs and show-commands which highlight the impact of the configuration. You will need NetBrain Qmap Reader to view these details with an in-depth topology diagram.

Explain UDP operations

• Starvation
• Latency

http://www.chainringcircus.org/congestion-link-efficiency-traffic-policing-and-shaping/

when TCP traffic slows (slow start) to deal with dropped traffic, UDP traffic does not slow, resulting in queues being filled by UDP packets, starving TCP of bandwidth.

from:

Enterprise QoS Solution Reference
Network Design Guide

When TCP flows are combined with UDP flows within a single service-provider class and the class
experiences congestion, TCP flows continually lower their transmission rates, potentially giving up their bandwidth to UDP flows that are oblivious to drops. This effect is called TCP starvation/UDP
dominance.
TCP starvation/UDP dominance likely occurs if (TCP-based) Mission-Critical Data is assigned to the same service-provider class as (UDP-based) Streaming-Video and the class experiences sustained congestion. Even if WRED is enabled on the service-provider class, the same behavior would be observed because WRED (for the most part) manages congestion only on TCP-based flows.

Explain TCP operations

1.1.e [ii] MSS

The maximum segment size (MSS) is a parameter of the TCP protocol that specifies the largest amount of data, specified in octets, that a computer or communications device can receive in a single TCP segment. It does not count the TCP header or the IP header.[1] The IP datagram containing a TCP segment may be self-contained within a single packet, or it may be reconstructed from several fragmented pieces; either way, the MSS limit applies to the total amount of data contained in the final, reconstructed TCP segment

ICMP Redirect

The ICMP Redirect

You will not find this very often … sometimes, you will come across a network where there are two routers on the same broadcast segment, each responsible for different networks. So how do you get your hosts to know which gateway should they use? You could setup two default gateways – both Windows and Linux allow that. However, you could also rely on ICMP Redirects – this feature is enabled by default on Cisco routers.

I will be working on the following topology:

Host1 is set with one single gateway of 192.168.1.254 (Router1). When Host1 tries to reach Host4 by sending a ping to 192.168.3.4, Host1 identifies the destination IP is not on the same LAN so it sends to its default gateway. Router1, knows how to reach 192.168.3.0 network through Router2. – so Router1 forwards the packet to Router2 -it does so by using the same interface as where the packet was received! This will then trigger Router1 sending the ICMP Redirect message to Host1 saying – “Next time you need to send a packet to 192.168.3.0 network, just use Router2 straight, since it’s on the same segment as I am!”

Notice this is different from standard routing where the normally, Router1 would forward the traffic out to another router, only this time, using another interface and not the same interface on which the packet was received!

Let’s see this in action …

The routing table on Host1 and Router1 look like this:

You can see that Router1 routes packets for network 192.168.3.0 through 192.168.1.253 (Router2); also, Host1 routes any packet through its default gateway which is set to 192.168.1.254 (Router1). Let’s send a ping to 192.168.3.1 now …

Router1 receives the packet since it is the default gateway to Host1; Router1 then forwards the packet to Router2 as per it’s own routing table; in doing so, it used the same interface on which the same packet was received – so Router1 will also send a redirect message to the sender. As a result, you can see that Host1, automatically adds a route in its routing table pointing to 192.168.1.253 – despite its default gateway being 192.168.1.254!

Next time Host1 sends a packet to host 192.168.3.1, it will use the gateway of 192.168.1.253.

Notice also that the route added in Host1′s routing table, is a host route, not a network route. So clearly, this method presents a disadvantage – each host will have a route entry, even if they are part of the same network!

You can also disable this behaviour by using the interface command “no ip redirects“.

ICMP - Destination Unreachable Message

ICMP - Destination Unreachable Message Introduction This ICMP message is quite interesting, because it doesn't actually contain one message, but six! This means that the ICMP Destination unreachable futher breaks down into 6 different messages. We will be looking at them all and analysing a few of them to help you get the idea. To make sure you don't get confused, keep one thing in mind: The ICMP Destination unreachable is a generic ICMP message, the different code values or messages which are part of it are there to clarify the type of "Destination unreachable" message was received. It goes something like this: ICMP Destination "unreachable". The ICMP - Destination net unreachable message is one which a user would usually get from the gateway when it doesn't know how to get to a particular network. The ICMP - Destination host unreachable message is one which a user would usually get from the remote gateway when the destination host is unreachable. If, in the destination host, the IP module cannot deliver the packet because the indicated protocol module or process port is not active, the destination host may send an ICMP destination protocol / port unreachable message to the source host. In another case, when a packet received must be fragmented to be forwarded by a gateway but the "Don't Fragment" flag (DF) is on, the gateway must discard the packet and send an ICMP destination fragmentation needed and DF set unreachable message to the source host. These ICMP messages are most useful when trying to troubleshoot a network. You can check to see if all routers and gateways are configured properly and have their routing tables updated and synchronised. Let's look at the packet structure of an ICMP destination unreachable packet: