BCMSN - Switch Port Analyzer (SPAN) [CCNP]

SPAN: Description [Credits to ETts for this explanation]

Switched Port Analyzer (SPAN), sometimes called port mirroring or port monitoring, copies switch network traffic and forwards it out the SPAN port for analysis by a network analyzer. By enabling SPAN, you can monitor traffic on a switch port by forwarding incoming and outgoing traffic to another port for data collection and analysis. You can use a network analyzer on this monitor port to troubleshoot network problems by examining traffic on other ports or segments without taking the network out of service.

Suppose, for instance, that you want to examine traffic flowing in and out of a port, or within a virtual local-area network (VLAN). In a shared network, such as Ethernet, you would attach a network analyzer to an available port on the hub and your analyzer would listen to all traffic on the segment, as illustrated in the figure.

The analyzer decodes the frames and provides you with an analysis of the frame contents, such as the packets and other higher-layer protocol information.

In a switched network, however, this is not as simple as in a shared network. In a switched network, the switch filters frames from transmitting out a port unless the bridge/switch table believes the frame's destination is on that port, or the frame needs to be flooded, such as during a spanning-tree update. This is not going to work for you because you want to see all the switch traffic, from all the VLANs. The SPAN switch feature enables you to attach an analyzer on a switch port and capture traffic from other ports in the switch, as illustrated in the figure below.

The SPAN port mirrors traffic from one or more source interfaces on any VLAN, or from one or more VLANs to a destination port for analysis. The network analyzer attaches to the SPAN port and examines the traffic as it passes through the switch. The network analyzer enables you to dig into the details of your network traffic. For SPAN configuration, the source interfaces and the destination interface must be on the same switch.

NOTE: SPAN does not affect the switching of network traffic on source interfaces; copies of the frames received or transmitted by the source interfaces are sent to the destination interface.

http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008015c612.shtml

SPAN: Configuration

Scenario: In order to configure port Fa0/1 as a destination port, the source ports Fa0/2 and Fa0/5, and the management interface (VLAN 1), select the interface Fa0/1 in the configuration mode.

Step 1: Enter destination port

S4#conf t

S4(config)#int fa0/1

S4(config-if)#

Step 2: Enter the list of ports to be monitored:

S4(config-if)#port monitor fa0/2

S4(config-if)#port monitor fa0/5 (With this command, every packet that these two ports receive or transmit is also copied to port Fa0/1.)

Step 3: Issue a variation of the port monitor command in order to configure the monitoring for the administrative interface (administrative interface as in vlan interface where the above 2 ports belong)

S4(config-if)#port monitor vlan 1 (The vlan 1 keyword simply refers to the administrative interface of the switch. Note: Both of the above ports should belong to VLAN 1 for SPAN to work)

Note: This configuration applies to 2900XL/3500XL.

RSPAN: Description

RSPAN allows you to monitor source ports that are spread all over a switched network, not only locally on a switch with SPAN. This feature appears in CatOS 5.3 in the Catalyst 6500/6000 Series Switches and is added in the Catalyst 4500/4000 Series Switches in CatOS 6.3 and later.

The functionality works exactly as a regular SPAN session. The traffic that is monitored by SPAN is not directly copied to the destination port, but flooded into a special RSPAN VLAN. The destination port can then be located anywhere in this RSPAN VLAN. There can even be several destination ports.

This diagram illustrates the structure of an RSPAN session:

Full explanation available: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008015c612.shtml

RSPAN (Remote Switched Port Analyzer): Configuration

S4#conf t

S4(config)#vlan [#]

S4(config-vlan)#remote span

S4(config)#monitor session [#] source [interface, remote, vlan]

S4(config)#monitor session [#] destination remote [vlan #]

S2#conf t

S2(config)#vlan [#]

S2(config-vlan)#remote span

S2(config)#monitor session [#] source remote vlan [#]

S2(config)#monitor session [#] destination interface [#]

Show Command/s:

S2#show monitor [session] [#]

Next stop... Inter-VLAN routing.

BCMSN - DHCP Snooping [CCNP]

DHCP Snooping:

DHCP snooping is a feature intended to prevent a malicious user from pretending to be the network DHCP server and thus intercepting DHCP packets.

Scenario where DHCP Snooping might be used:

This is where a rogue dhcp server is introduced on a network. Generally a host will accept the first ip-address for a DHCP 'Offer' packet it receives. If the rogue server sends it's ip information with the valid ip-address but a gateway of the rogue server, or even DNS address of the rogue server then it will be able to gather all traffic from the suceptible hosts.

By using a feature known as 'dhcp snooping' this form of attack can be prevented on switches.

(1) Trusted - An interface is trusted for DHCP traffic

(2) Untrusted - An interface is not trusted, unauthorized DHCP traffic will be dropped and port will enter err-disabled mode (all ports are placed into this by default when dhcp snooping is enabled)

Configuration:

Step 1 - Enable DHCP Snooping on the entire switch:

S4#conf t

S4(config)#ip dhcp snooping

Step 2 - Enable DHCP Snooping for a particular VLAN

S4(config)#ip dhcp snooping vlan 4

Step 3 - Ports can then be configured as trusted with the ip dhcp snooping trust command.

S4(config)#int fa0/1

S4(config-if)#ip dhcp snooping trust

For a better understanding on DHCP Snooping, I found an excellent tutorial by Chris Bryant:

http://www.mcmcse.com/cisco/guides/dhcp_snooping.shtml

CCNP 2010 - Update

Cisco updated it now....

CCNP Certification - Cisco Systems - http://www.cisco.com/web/learning/le3/le2/le37/le10/learning_certification_type_home.html

Cisco recommends to take the TSHOOT instead of ISCW or ONT for those who have completed the BSCI and BCMSN .

Here's a good article from Network World on the new CCNP curriculum:

http://www.networkworld.com/community/node/56413?ts0hb&story=ccnp

BCMSN Lab - Layer 2 Etherchannel Configuration: LACP [CCNP]

Configuring LACP between S2 and S4

S2#conf t
S2(config)#int range fa0/3 - fa0/4
S2(config-if)#channel-protocol lacp
S2(config-if)#channel-group 1 mode on
S2(config-if)#exit

S4#conf t
S4(config)#int range fa0/3 - fa0/4
S4(config-if)#channel-protocol lacp
S4(config-if)#channel-group 1 mode on
S4(config-if)#int fa0/1 (not necessary but might as well do it)
S4(config-if)#switchport mode access (not necessary but might as well do it)
S4(config-if)#spanning-tree portfast (not necessary but might as well do it)

and that's it...

BCMSN Lab - Etherchannel Configuration [CCNP]

(1) Layer 2 Etherchannel: Configuration

Method 1 - If you want to use a negotiation protocol, use the following command:

(a) PAGP

S2#conf t
S2(c0nfig)#int range fa0/3 - fa0/4
S2(config-if)#channel-protocol pagp
S2(config-if)#channel-group [group-no] mode [desirable/auto] (use desirable on at-least 1 side for establishing an etherchannel link)

S4#conf t
S4(config)#int range fa0/3 - fa0/4
S4(config-if)#channel-protocol pagp
S4(config-if)#channel-group [group-no] mode [desirable/auto] (now, we could be either auto or desirable and it would negotiate a link. Let's go 'auto' to have a desirable-auto match here)

Note: It is essential that the same settings are used on both end-to-end switches, i.e: same group-no.

If you do a 'show ip int brief' now you should see 'Port-channel[group-no]' come 'up' (might take a moment or so) at this stage. You can further do the following show Etherchannel commands:

S4#show etherchannel
S4#show etherchannel detail
S4#show etherchannel summary
S4#show etherchannel brief

Alternatively you can choose to implement LACP in the same manner:

(b) LACP

S2#conf t
S2(c0nfig)#int range fa0/3 - fa0/4
S2(config-if)#channel-protocol lacp
S2(config-if)#channel-group [group-no] mode [active/passive] (use active on at-least 1 side for establishing an etherchannel link)

S4#conf t
S4(config)#int range fa0/3 - fa0/4
S4(config-if)#channel-protocol lacp
S4(config-if)#channel-group [group-no] mode [active/passive] (now, we could be either active or passive and it would negotiate a link. Let's go 'passive' to have an active-passive match here)

Note: Again, it is essential that the same settings are used on both end-to-end switches, i.e: same group-no.

and in this way using method 1 you can either:
(a) implement PAGP for negotiating Etherchannel links (on Cisco platform)
or you can:
(b) implement LACP for negotiating Etherchannel links (on cross-compatible platforms)

Method 2 - If you want to hardcode the ports for etherchannel (which is what I personally prefer), you CANNOT use the above 'channel-protocol' command from Method 1. It won't work.

S2#conf t
S2(c0nfig)#int range fa0/3 - fa0/4
S2(config-if)#channel-group [group-no] mode on (notice: on does not have a protocol)

S4#conf t
S4(config)#int range fa0/3 - fa0/4
S4(config-if)#channel-group [group-no] mode on

This hardcodes it as anetherchannel link without using any negotiation (PAGP or LACP).

(2) Layer 3 Etherchannel: Configuration

There is not too much to the config than layer 2.

In layer 3 Etherchannel, we assign an ip-address to the port-channel interface (not the indivitual interfaces) that we created above.

Step 1 is to disable the channel-group extablished on L2 domain. In step 3 we'll re-enable it after we convert port-channel interface in Step 2.

Step 1: Disable channel-group and convert physical interfaces to routed ports.

S2#conf t
S2(config)# int range fa0/3 - fa0/4
S2(config-if)#no channel-group [grp-no]
S2(config-if)#no switchport

Step 2: Convert port-channel interface to routed port and set ip-address.

S2(config-if)#int port-channel[grp-no] (to configure the port-channel[grp-no] interface)
S2(config-if)#? (notice, dhcp snooping and multicast support are only available.-> we'll dig into both of em' later. So, to get more options we conver this port into a routed port using the following cmd:)
S2(config-if)#no switchport (turns of L2 capabilities of the switchport & makes it a L3 interface)
S2(config-if)#ip address 10.1.1.1 255.255.255.0 (assign an ip to the port-channel)

Step 3: Re-enable channel-group (on physical-interfaces)

S2(config-if)#int range fa0/3 - fa0/4
S2(config-if)#channel-group 1 mode [on |active/passive for lacp or|desirable/auto for pagp]

and the same 3 steps are performed on the connected layer 3 switch...

Tip - Servers as of late have started supporting etherchannel too. You can get servers from Dell and order them with multiple network cards that can be 'LACP compliant', meaning we can have a bundled channel, like maybe a 2Gbps interface coming from the server interface to the switch and really having a high bandwidth connection.

Etherchannel: Best practises

-All ports must use same speed and duplex (hard code!)
-Interfaces in a bundle are redundant (If one link goes down, others will still work)
-No interfaces in a bundle can be span ports (span = switchport analyser, which is used to sniff on a switch. This featue cannot be used with etherchannel.)
-Interfaces in bundle must be in the same VLAN or configured as a trunk.
-Any changes to port-channel affects all bundled ports (If we change the configuration under the 'port-channel[grp-no]' interface, it is the umbrella that applies to every single physical interface underneath. But...)
-Any changes to indivitual ports affect only that port (It's not like the port-channel inherits what the configuration is of the physical interface, so suppose if you change the VLAN config of an interface that can't affect the whole bundle by dropping that interface out since it doesn't inherit that into the etherchannel/port-channel interface.)

...and that is the concept of Etherchannel.

BCMSN - Etherchannel [CCNP]

What is Etherchannel?

Etherchannel is aggregation of redundant links.


Etherchannel makes use of the 3 links blocked by spanning-tree by aggregating all four links into 1 logical link. Etherchannel can do that for upto 8 ports! (if you have a 6500 switch).

Advantages:

(1) Uses all links to maximize bandwidth.
(2)Load-balances over all 3 links.
(3)Uses automatic fail-over (if 1 link fails, it becomes a 3Gbps link, in this case).
(4)Simplifies logical interface configuration - Just configure 1 interface and the rest (3 in this case) will follow.

Two negotiation protocols:

(1) Port Aggregation Protocol (PAGP)

-Cisco Proprietary (first to come out)
-Port modes: auto, desirable, on

-When a port is set to 'auto' it will automatically tune itself to whatever the connected port is set to. Auto-Auto on both sides won't make it an etherchannel because both sides are waiting for one side to be a desirable connection. Auto-Desirable thus would work however the best bet, and my personal preference is to set both sides to 'on' thus hardcoding the trunk and disabling this whole 'negotiation' game.

PAGP is more of a legacy protocol now.

(2) Link Aggregation Control Protocol (LACP)

-Industry Standard (802.3AD)
-Port modes: passive, active, on

-passive = auto and active = desirable. Just different words, function is exactly the same.

LACP is more common and widely used due to it being industry-standard.

2 flavours of Etherchannel:

(1) Layer 2 Etherchannel: (For layer 2 switches such as 2950's.) is a simple bundling of multiple physical interfaces into a single logical port. That logical port acts and feels like a normal switchport except that it has a lot more bandwidth than a single switchport, and does load-balancing on those links, so basically it's something seen on a layer 2 domain.

(2) Layer 3 Etherchannel: (For layer 3 switches such as 3550 or above) means we could take all of the switchports and bundle them at layer 2 (which is where they all link up) but then assign them to a logical layer interface called a Port-Channel interface. That port-channel interface can be assigned an ip-address, it can ping, it's just like a routed port.

Common to see L3 Etherchannel configured between the distribution and core layer of the network.

In the next post, we'll move on to configuring Etherchannel...

BCMSN - New stuff on Spanning-Tree [CCNP]

& some earlier revision from CCNA...

For more info on STP and L2/L3 switching in general, refer to chapter 3 of the CCNP BCMSN Official Exam Certification Guide. A lot of it covers on how frames travel through a switched network, and the CAM table (content addressable memory better known as the MAC address-table), along with the TCAM table (ternary content addressable memory; which is used for ACL storage within a table format). Overall, a good read.

STP Costs [CCNA Rev.]

Important ones are in blue italics...

4 Mbps - 250
10 Mbps - 100
16 Mbps - 62
45 Mbps - 39
100 Mbps - 19
155 Mbps - 14
622 Mbps - 6
1 Gbps - 4
10 Gbps - 2

The cost can be adjusted manually using the following command:

(a) Change STP cost for ALL VLANs's (STP)

S1#conf t
S1(config)#int fa0/1
S1(config-if)#spanning-tree cost [1-200000000]

(b) Change STP cost per-vlan (PVSTP)

S1#conf t
S1(config)#int fa0/1
S1(config-if)#spanning-tree vlan [id] cost [1-200000000]

More on Spanning-Tree...

BPDU's - BPDU's are transmitted every 2 seconds to the multicast address 01-80-c2-00-00-00 in the following two types:

(1) Topology Change Notification (TCN) BPDU - When a change takes place in the network topology.
(2) Configuration BPDU - Used for STP calculations. The root bridge originates these while the non-root bridges forward them.

STP Timers: Description - Following is a short description of various STP timers :

(1) Hello - Hello timer originates 'Configuration BPDU's'. Default hello timer = 2 seconds.
(2) Forward Delay - Forward Delay timer sets the amount of time an interface spends in the STP listening and learning stage. Default timer = 15 seconds.
(3) Max-Age - MaxAge Timer defines how long a bridge or switch should wait after the last received hello message before believing that the network topology has changed and it can no longer hear the hello messages sent by the root bridge or switch. Default Timer = 20 seconds.
(Basically, Max-Age is the aging time of superior switch's BPDU's.)

STP Timers: Commands - Following are the commands used to set the timers:

(a) Hello:
S1#conf t
S1(config)#spanning-tree vlan [id] hello-time [seconds]

(b) Forward Delay
S1#conf t
S1(config)#spanning-tree vlan [id] forward-time [seconds]

(c) Max-Age
S1#conf t
S1(config)#spanning-tree vlan [id] max-age [seconds]

STP: Further spanning-tree concepts...

Portfast - Portfast is a tool that essentially turns off spanning-tree on your switches, so the port will become active as soon as you plug in but that will cause loops in the network. Basically, Portfast allows a switch to go directly from blocking to forwarding mode. It is suitable for ports where 1 host is connected.

(a) Enable Portfast on the port where 1 host is connected:

S1#config t
S1(config)#int [interface-id that is connected to 1 host]
S1(config-if)#spanning-tree portfast

(b) Enable Portfast on ALL Ports:
S1#config t
S1(config)#spanning-tree portfast default

I find (a) to be most commonly used. This is where you enable portfast only on the ports that are connected to a 'HOST'. (Remember when it comes to RSTP, you need to enable portfast for it to work in your network.)

uplinkfast - uplinkfast reduces STP 'convergence' time from 50 seconds (15 secs for listening + 15 secs for learning + 20 secs for max-age = 50 secs of delay-time by default) to around 1-3 seconds on trunk links between switches. It is enabled globally and for ALL VLAN's. Should be done between access and distribution layer switches rather than distro and core layers.

(a) Enable uplinkfast - Priority becomes 49152, Cost is updated by +3000
S1#conf t
S1(config)#spanning-tree uplinkfast

Increases priority to 49152 so if this cmd is executed on the root switch, make sure to increase the priority on the other secondary switches from 32768 default-value to > 49152.

backbonefast - backbonefast should be enabled on ALL switches in the network. This is so all switches can respond to RLQ's a.k.a. root link queries.

(a) Enable backbonefast on ALL switches in the LAN - Cuts 'convergence time' to 30 seconds (by eliminating max-age-time)
S1#conf t
S1(config)#spanning-tree backbonefast

BPDU Guard - BPDU Guard actually shuts down a port in an 'err-disabled state' if a bpdu comes in on that particular port/s.

(a) Enable BPDU Guard on a single port:

S1#conf t
S1(config)#int [interface-id]
S1(config-if)#spanning-tree bpduguard [enable/disable]

(b) Enable BPDU Guard on ALL ports running portfast:
S1#conf t
S1(config)#spanning-tree portfast bpduguard default

BPDU Filter - BPDU Filtering stops the port from going into an err-disabled state when it receives a bpdu.
If enabled globally: a port running portfast will STOP running portfast if a BPDU is received.
If enabled at the interface level: the bpdu's will simply be ignored and dropped.

(a) Enable BPDU Filter on a single port running portfast:

S1#conf t
S1(config)#int [interface-id]
S1(config-if)#spanning-tree bpdufilter [enable/disable]

(b) Enable BPDU Filter on ALL ports running portfast:

S1#conf t
S1(config)#spanning-tree portfast bpdufilter default

This is not to be confused with BPDU Guard as it's exactly the opposite of it. BPDU Filter actually stops running Portfast and thus should never be enabled in an RSTP network.

Also note, for BPDU Guard and BPDU Filter, you have to type in'spanning-tree portfast' followed by 'bpduguard' or 'bpdufilter' to enable either two in global-config mode (for ALL ports running portfast). Note especially the keyword 'portfast' after 'spanning-tree'.

Root Guard - Root Guard ignores superior bpdu's by going into root-inconsistent state (so I think basically, the Max-Age timer of 20 secs is ignored).

(a) Enable Root-Guard to ignore superior BPDU's on an interface:
S1#conf t
S1(config)#int [int-id]
S1(config-if)#spanning-tree guard root

S1#show spanning-tree inconsistentports (to show ports blocking superior bpdu's)

STP: Show Commands...

S1#show spanning-tree

S1#show spanning-tree summary totals (pretty good to see what's running/enabled)
S1#show spanning-tree interface [num] detail
S1#show spanning-tree inconsistentports (to show ports blocking superior bpdu's)
S1#show interface [interface-id] switchport

Those are some of the main concepts with regards to spanning-tree in the BCMSN curriculum.