BGP Conditional Route Injection

NJECT-MAP & EXIST-MAP

With conditional route injection we can insert more specific routes into a BGP table based on the existance of another route which means that now we will combine the inject-map with the exist-map. The exist-map determines if the aggregate is present. Let’s go back  on R3 to just a summary-only aggregate

R3(config-router)#aggregate-address 4.4.0.0 255.255.0.0 summary-only

Now we will create an (inject-map) to advertise 4.4.45.44 and 4.4.46.44 to R2 based on the existing aggregate (exist-map)

Before let’s check the BGP table on R1

So on R2 :

R2(config)#ip prefix-list AGGR3 seq 5 permit 4.4.0.0/16
R2(config)#ip prefix-list SOURCER3 seq 5 permit 192.168.23.3/32
R2(config)#ip prefix-list SENDTOR1 seq 5 permit 4.4.45.44/32
R2(config)#ip prefix-list SENDTOR1 seq 10 permit 4.4.46.44/32

R2(config)#route-map MUSTEXIST per 10
R2(config-route-map)#match ip add pre AGGR3
R2(config-route-map)#match ip route-source pre SOURCER3

R2(config)#route-map INJECTTHIS permit 10
R2(config-route-map)#set ip address prefix-lists SENDTOR1

R2(config)#router bgp 200
R2(config-router)#bgp inject-map INJECTTHIS exist-map MUSTEXIST

Now let’s check the BGP table on R1

As you can see networks 4.4.45.44/32 and 4.4.46.44/32 have been learned from 192.168.12.2 which is what we expect however if we also check R3 table

Hmm.. This config should not cause a loop but just in case we do not want R3 to learn its own routes back from its neighbors so we can simply on R2 add a keyword “copy-attributes” to this statement

R2(config)#router bgp 200
R2(config-router)#bgp inject-map INJECTTHIS exist-map MUSTEXIST copy-attributes

That way AS-PATH will be included in the advertisement and R3 will not install these routes in its BGP table if it learns them from R2 and R1 in this case , loop prevention.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Not shown is BB2 connected off of Sw2. BB2 is the source of all the routes you’ll see in the BGP table.

For this example I have an aggregate of 192.168.0.0/21 create on R1, which it in turn is advertising to R2 and Sw3.  I also have a suppress-map on the aggregate to suppress the 192.168.3.0/24 route.

R1#sh ip bgp
BGP table version is 12, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.0.0/21   0.0.0.0                            32768 i
*> 192.168.1.0      10.21.12.21              0    100      0 (12) 2122 i
*> 192.168.2.0      10.21.12.21              0    100      0 (12) 2122 i
s> 192.168.3.0      10.21.12.21              0    100      0 (12) 2122 i
*> 192.168.4.0      10.21.12.21              0    100      0 (12) 2122 i
*> 192.168.5.0      10.21.12.21              0    100      0 (12) 2122 i
*> 192.168.6.0      10.21.12.21              0    100      0 (12) 2122 i
*> 192.168.7.0      10.21.12.21              0    100      0 (12) 2122 i
*> 192.168.8.0      10.21.12.21              0    100      0 (12) 2122 i
*> 192.168.9.0      10.21.12.21              0    100      0 (12) 2122 i

R1#sh ip bgp 192.168.0.0/21
BGP routing table entry for 192.168.0.0/21, version 11
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
        1    2
  Local, (aggregated by 112 1.1.1.1)
    0.0.0.0 from 0.0.0.0 (1.1.1.1)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best

And if we look at the BGP table on R2 we’ll see that we have the aggregate, but not the suppressed route.

R2#sh ip bgp
BGP table version is 10, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.0.0/21   10.1.2.1                 0             0 112 i
*> 192.168.1.0      10.1.2.1                               0 112 2122 i
*> 192.168.2.0      10.1.2.1                               0 112 2122 i
*> 192.168.4.0      10.1.2.1                               0 112 2122 i
*> 192.168.5.0      10.1.2.1                               0 112 2122 i
*> 192.168.6.0      10.1.2.1                               0 112 2122 i
*> 192.168.7.0      10.1.2.1                               0 112 2122 i
*> 192.168.8.0      10.1.2.1                               0 112 2122 i
*> 192.168.9.0      10.1.2.1                               0 112 2122 i

Now the fun stuff starts.

What we’re going to do is inject the 192.168.3.0/24 route back into our BGP table even though it’s still suppressed on R1.  We do this with the BGP inject-map, also known as the title of this post: BGP conditional route injection.

As I stated at the onset this one takes a bit of typing. We need to create a route-map that calls a prefix-list to define the route we want to inject, and we create another route-map that calls a prefix-list that defines the aggregate we want to match, and another prefix-list that defines the source of the aggregate.

That’s 3 prefix lists, and 2 route-maps.

Then with all of that nonsense in hand we define the inject-map within the BGP process itself (or within the BGP address-family if that’s the way you’re doing things).

Let’s get started shall we?  We’ll be doing the config on R2.

ip prefix-list ADVERTISE-1 permit 192.168.3.0/24
!
ip prefix-list AGGREGATE-1 permit 192.168.0.0/21
!
ip prefix-list SOURCE-1 permit 10.1.2.1/32
!
route-map ADVERTISE-MAP-1
 set ip address prefix ADVERTISE-1
!
route-map EXIST-MAP-1
 match ip address prefix-list AGGREGATE-1
 match ip route-source prefix-list SOURCE-1
!
router bgp 2313
 bgp inject-map ADVERTISE-MAP-1 exist-map EXIST-MAP-1

Before we look at the results of this I want to quickly talk about my aforementioned impromptu troubleshooting fiasco this evening.  Please direct your attention to the route-map ADVERTISE-MAP-1.  This route-map calls the prefix-list the defines the routes we are going to inject into the BGP table.

Please note, THIS MUST BE A SET AND NOT A MATCH.

I had it as a match and it took a long time for me to see it. Under the stress of the Lab this could really bugger up your day. At least one person in #cciestudy, and one person on Twitter that looks at this also didn’t catch it.

OK, with the nastiness over with for the night, let’s get back to seeing what we actually accomplished with this config.

R2#sh ip bgp
BGP table version is 13, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.0.0/21   10.1.2.1                 0             0 112 i
*> 192.168.1.0      10.1.2.1                               0 112 2122 i
*> 192.168.2.0      10.1.2.1                               0 112 2122 i
*> 192.168.3.0      10.1.2.1                               0 ?
*> 192.168.4.0      10.1.2.1                               0 112 2122 i
*> 192.168.5.0      10.1.2.1                               0 112 2122 i
*> 192.168.6.0      10.1.2.1                               0 112 2122 i
*> 192.168.7.0      10.1.2.1                               0 112 2122 i
*> 192.168.8.0      10.1.2.1                               0 112 2122 i
*> 192.168.9.0      10.1.2.1                               0 112 2122 I

It’s fairly obvious which one of these things is not like the other thing. It’s also fairly obvious that that thing is our previously suppressed route.  Excellent.

Al closer look at our injected route:

R2#sh ip bgp 192.168.3.0
BGP routing table entry for 192.168.3.0/24, version 13
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
        1
  Local, (aggregated by 112 1.1.1.1), (injected path from 192.168.0.0/21)
    10.1.2.1 from 10.1.2.1 (1.1.1.1)
      Origin incomplete, localpref 100, valid, external, atomic-aggregate, best

I won’t walk through all of the output, but of note is that it still shows as an aggregate. This seems logical since I could have made it a /23 or a /22, as long as it’s smaller than the original aggregate (a /21 in this example). Because there’s no way to know what the real networks are is should be classified as an aggregate.

If for any reason you need to set different attributes for the injected route there’s 2 ways to go about doing it.  The first simply copies all the attributes from the aggregate into the injected route. This is done with the copy-attributes keyword on the inject-map command.

R2(config-router)# bgp inject-map ADVERTISE-MAP-1 exist-map EXIST-MAP-1 ?
  copy-attributes  Copy attributes from aggregate
  <cr>

The second method is to set the desired attributes within the route-map used to specify the injected route(s). In this example this is the ADVERTISE-MAP-1 route-map.

I’ll also toss in one more command on R2 specific to this example:

R2#sh ip bgp injected-paths
BGP table version is 13, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.3.0      10.1.2.1                               0 ?

This command simply shows you any entries in your BGP table that are a result of an inject-map on the local router.

We can also see that the route is being propagated to R3 as it should be.

R3#sh ip bgp 192.168.3.0/24
BGP routing table entry for 192.168.3.0/24, version 226
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
        1    2
  Local, (aggregated by 112 1.1.1.1), (Received from a RR-client)
    10.1.2.1 (metric 65) from 2.2.2.2 (2.2.2.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, atomic-aggregate, best

BGP local-as, dual-as and replace-as

On Cisco routers running BGP, the command local-as can be used to tweak the AS number announced to BGP peers. This can be handy in some situations to overcome (mostly political) obstacles, but it can be harmful if not thoroughly thought out.

Under normal conditions, a BGP router will advertise routes which originate within its autonomous system (AS) with an AS path length of one, listing only its own AS number specified under BGP process configuration (e.g.router bgp 65001). Contrary to what might be assumed, the local-as command does not replace the AS number advertised to peers. Rather, it prepends it to the actual AS number, resulting in an AS path length of two. Routes advertised to neighbors with a local AS configured will appear to arrive via the specified AS, but will still be known to have originated from the actual AS.

When might this be of concern? Suppose we were to establish BGP adjacencies between three spoke routers and a central hub router, illustrated below. The hub site is AS 65000, and the three spoke sites are to be AS 65001, 65002, and 65003.

Unfortunately, the third spoke router has been misconfigured as AS 65002. The hub router expects to peer with us as AS 65003, and duly complains that something is wrong using a BGP notification. Note that 0xFDEA is the hexadecimal equivalent of the decimal AS number 65002.

%BGP-3-NOTIFICATION: received from neighbor 172.16.0.9 2/2 (peer in wrong AS) 2 bytes FDEA

There are two ways to rectify this error. The preferred way would be to reconfigure the spoke router's BGP process with the correct AS number. Unfortunately, this requires tearing down and restoring the entire BGP configuration. This might not be immediately feasible, particularly if other adjacencies have already been established using the incorrect AS number.

The other, presumably more convenient option, is to associate a local AS with the hub router adjacency using thelocal-as parameter. The relevant configuration would look like this:

router bgp 65002
 neighbor 172.16.0.9 remote-as 65000
 neighbor 172.16.0.9 local-as 65003
 !
 address-family ipv4
  neighbor 172.16.0.9 activate
 exit-address-family

From the hub router, it appears that R3 is advertising the 192.168.3.0/24 network as AS 65003, but the route appears to have originated in AS 65002:

Hub# show ip bgp 192.168.0.0 255.255.0.0 longer-prefixes
BGP table version is 10, local router ID is 172.16.0.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0      172.16.0.2               0             0 65001 ?
*> 192.168.2.0      172.16.0.6               0             0 65002 ?
*> 192.168.3.0      172.16.0.10              0             0 65003 65002 ?

While this hack is effective in establishing the BGP adjacency, it prevents the networks behind R2 and R3 from communicating with one another. This is because BGP routers don't install routes advertised with their own AS in the path. In fact, the hub router, knowing this rule, doesn't even propagate the networks advertised by R3 to R2:

R2# show ip bgp neighbors 172.16.0.5 received-routes
BGP table version is 5, local router ID is 192.168.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/30    172.16.0.5                             0 65000 65001 ?
*> 192.168.1.0      172.16.0.5                             0 65000 65001 ?

Total number of prefixes 2 

The reverse is also true for routes advertised from R2 toward R3. Thus, the networks behind R2 and R3 can both talk to the networks behind R1, but not to one another. Only when R3 is reconfigured with the proper BGP AS will full communication be established.

router bgp 65003
 neighbor 172.16.0.9 remote-as 65000
 !
 address-family ipv4
  neighbor 172.16.0.9 activate
 exit-address-family

R2# show ip bgp neighbors 172.16.0.5 received-routes
BGP table version is 11, local router ID is 192.168.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/30    172.16.0.5                             0 65000 65001 ?
*> 172.16.0.8/30    172.16.0.5                             0 65000 65003 ?
*> 192.168.1.0      172.16.0.5                             0 65000 65001 ?
*> 192.168.3.0      172.16.0.5                             0 65000 65003 ?

Total number of prefixes 4 

---------------------------------------------

… making your network appear as a set of nested autonomous systems:There are two reasons for the weird AS path:

R1 inserts local-as into inbound EBGP updates
R2 (configured like R1) inserts local-as as well as its real AS (65001) in outbound EBGRP update

To fix the AS path, you need the BGP Support for Dual AS Configuration introduced in IOS release 12.3T. This feature adds two options to the local-as configuration command:

no-prepend disables local-as prepending on incoming EBGP updates;
replace-as replaces router's own AS with local-as on outgoing EBGP updates.

When the configuration on R1 and R2 includes these two keywords …:
router bgp 65001
 neighbor 10.1.0.2 remote-as 10
 neighbor 10.1.0.2 local-as 20 no-prepend replace-as
 neighbor 10.1.0.2 description EBGP to AS 10
… the path propagated through AS 65001/AS 20 looks as expected:
AS30#show ip bgp | include 20
*> 172.16.0.0     10.1.0.5     0 20 10 i

BGP 4-byte ASN

Prior to January 2009, BGP autonomous system numbers that were allocated to companies were 2-octet numbers in the range from 1 to 65535 as described in RFC 4271, A Border Gateway Protocol 4 (BGP-4). Due to increased demand for autonomous system numbers, the Internet Assigned Number Authority (IANA) will start in January 2009 to allocate four-octet autonomous system numbers in the range from 65536 to 4294967295. RFC 5396, Textual Representation of Autonomous System (AS) Numbers, documents three methods of representing autonomous system numbers. Cisco has implemented the following two methods:

•  Asplain--Decimal value notation where both 2-byte and 4-byte autonomous system numbers are represented by their decimal value. For example, 65526 is a 2-byte autonomous system number and 234567 is a 4-byte autonomous system number.
•  Asdot--Autonomous system dot notation where 2-byte autonomous system numbers are represented by their decimal value and 4-byte autonomous system numbers are represented by a dot notation. For example, 65526 is a 2-byte autonomous system number and 1.169031 is a 4-byte autonomous system number (this is dot notation for the 234567 decimal number).

Formula to calculate ASN 4bytes(quotient.remainder):
Example for AS 769672:

quotient => 769672 / 65536 = 11
remainder = 769672 - (11*65536) = 48776
Result: AS 11.48776 

 BGP TTL Security

By default, IOS sends BGP messages to EBGP neighbors with an IP time-to-live (TTL) of 1. (This can be adjusted with ebgp-multihop attached to the desired neighbor or peer group under BGP configuration.) Sending BGP messages with a TTL of one requires that the peer be directly connected, or the packets will expire in transit. Likewise, a BGP router will only accept incoming BGP messages with a TTL of 1 (or whatever value is specified byebgp-multihop), which can help mitigate spoofing attacks.

However, there is an inherent vulnerability to this approach: it is trivial for a remote attacker to adjust the TTL of sent packets so that they appear to originating from a directly-connected peer.

By spoofing legitimate-looking packets toward a BGP router at high volume, a denial of service (DoS) attack may be accomplished.

A very simple solution to this, as discussed in RFC 5082, is to invert the direction in which the TTL is counted. The maximum value of the 8-bit TTL field in an IP packet is 255; instead of accepting only packets with a TTL set to 1, we can accept only packets with a TTL of 255 to ensure the originator really is exactly one hop away. This is accomplished on IOS with the TTL security feature, by appending ttl-security hops <count> to the BGP peer statement.

Only BGP messages with an IP TTL greater than or equal to 255 minus the specified hop count will be accepted. TTL security and EBGP multihop are mutually exclusive; ebgp-multihop is no longer needed when TTL security is in use.

BGP Disable-Connected-Check vs eBGP Multihop

Disable-connected-check enables a directly connected eBGP neighbor to peer using a loopback address without adjusting the default TTL of 1. What normally happens for eBGP neighbor statements, is that a check is done on the router to confirm that the neighbor is listed as being directly connected in the routing table. If eBGP neighbors are peering using loopbacks then the address of the neighbor will not listed as being directly connected in the routing table, and it is therefore not possible to complete this check. However with disable-connected-check, this particular check is not enforced. However, the default TTL of 1 still applies.  So it is compulsory that the neighbor is only ever a maximum of one hop away.  The difference with eBGP multihop, is that you can specify how many hops away a neighbor is allowed to be. You are actually adjusting the TTL instead.

In the diagram below, I’m going to start by configuring BGP between R1 & R2 using loopbacks over their directly connected fa0/0 interfaces with #disable-connected-check.

R1(config-router)#neighbor 2.2.2.2 remote-as 2
R1(config-router)#neighbor 2.2.2.2 update-source lo0
R1(config-router)#neighbor 2.2.2.2 disable-connected-check
R1(config-router)#ip route 2.2.2.2 255.255.255.255 12.12.12.2
R1(config)#
*Mar 1 00:17:22.095: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up

R2(config)#router bgp 2
R2(config-router)#neighbor 1.1.1.1 remote-as 1
R2(config-router)#neighbor 1.1.1.1 update-source lo0
R2(config-router)#neighbor 1.1.1.1 disable-connected-check
R2(config-router)#ip route 1.1.1.1 255.255.255.255 12.12.12.1
R2(config)#
*Mar 1 00:17:22.083: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

As you can see, the neighbors came straight up. If I now try and use the path via R1-R3-R4-R2, i.e. a path that is not directly connected, the neighbors will not establish a session because the ttl will only be set to 1, and therefore cause a reachability problem. This is shown below.

R2(config)#int fa0/0
R2(config-if)#shut
R2(config-if)#no ip route 1.1.1.1 255.255.255.255 12.12.12.1
R2(config-if)#ip route 1.1.1.1 255.255.255.255 24.24.24.2
//Note that 24.24.24.2 = R4//
R2(config)#end

R1(config)#int fa0/0
R1(config-if)#shut
R1(config-if)#no ip route 2.2.2.2 255.255.255.255 12.12.12.2
R1(config-if)#ip route 2.2.2.2 255.255.255.255 13.13.13.2
//Note that 13.13.13.2 = R3//
R1(config-if)#do ping 2.2.2.2 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/66/80 ms

R1(config-if)#
R1(config-if)#
*Mar 1 00:25:23.763: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Down BGP Notification sent
R1(config-if)#
*Mar  1 00:25:23.763: %BGP-3-NOTIFICATION: sent to neighbor 2.2.2.2 4/0 (hold time expired) 0 bytes

R1#sh ip bgp sum
BGP router identifier 1.1.1.1, local AS number 1
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4     2       8      12        0    0    0 00:04:33 Active

So because the neighbor is no longer 1 hop away (regarding disable-connected-check) the session drops, a notification is sent, and the hold time expires. However if I use ebgp-multihop instead of the disable-connected check, the session will form (because we increased the TTL). This is shown below.

R1(config)#router bgp 1
R1(config-router)#no neighbor 2.2.2.2 disable-connected-check
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 3

R2(config)#router bgp 2
R2(config-router)#no neighbor 1.1.1.1 disable-connected-check
R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 3

*Mar 1 00:41:45.159: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

R2#sh ip bgp sum
BGP router identifier 2.2.2.2, local AS number 2
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4     1      27      31        1    0    0 00:15:02      0

In conclusion, if you want to use the disable-connected-check feature, then ensure the neighbor is directly connected. Otherwise, you need to use ebgp-multihop, or ttl-security to establish the session.

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