Understanding Mobile Router/Mobile Network

What does mobile IP do? It allows a mobile router to keep the same IP address while traveling from one network to another and provides IP connectivity to the IP hosts connecting through the mobile router. The hosts behind the mobile router are unaware of this mobility.

Mobile IP has three components:

1. Home agent (HA) - An HA is a router on the home network that maintains an association between the home IP address of the MR and the current care-of address of the MR on the foreign network. HA redirects packets by tunneling them to the MR while it is away from home (in the foreign network).

2. Foreign agent (FA) - An FA is a router on a foreign network that provides a care-of address to the MR. It also detunnels and delivers packets to the MR that were tunneled by the HA.

3. Mobile router (MR) - A mobile router, moves from one network or subnet to another, "hides" the IP roaming from the IP hosts connecting through this mobile router so that the local hosts appear to be directly attached to the home network.

Let's go through a quick example:

 

The HA R1 is advertising (“redistribute mobile”) reachability to the mobile network 140.80.1.0/24 (on the MR R3) to the internet, thereby attracting packets that are destined for this subnet. MR R3 will keep the same IP address 150.1.1.1 while roaming between its home network 150.1.1.0/24 and foreign networks 200.2.2.0/24, 200.6.6.0/24. So When MR R3 is in foreign network 200.2.2.0/24, it will acquire a care-of address 2.2.2.2 from the FA R2. After receiving the care-of address, the MR R3 will register this address with its HA R1. The HA R1 will create a mobility binding table that maps the home IP address 150.1.1.1 of the MR R3 to the current care-of address 2.2.2.2 of the MR R3.

Now when any device on the Internet, called a corresponding node (CN), sends a packet to the mobile network (more specifically to 140.80.1.1), the packet is routed to the HA R1. Then the HA R1 will double tunnel it (outer tunnel to FA R2 care-of address 2.2.2.2 and inner tunnel to MR R3 itself). The FA R2 removes the outer tunnel header and delivers the inner tunneled packet to the connected MR R3. MR R3 performs another decapsulation to deliver the packet to the destination node 140.80.1.1 on the mobile network.

However, packets sent from the mobile network 140.80.1.0/24 are routed directly to the CN unless a reverse tunnel is configured.

Let's check the configuration on those routers for IP mobility:

Rack1R1 (HA)

!
interface Loopback0
 description HA address
 ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
 description home network
 ip address 150.1.1.254 255.255.255.0
!
interface FastEthernet0/1
 description connected to internet
 ip address 180.1.17.1 255.255.255.0
!
! Enables Mobile IP
router mobile
!
router ospf 1
! Redistributes the virtual network into the routing protocol
 redistribute mobile subnets
!
! Enables home agent service
ip mobile home-agent address 1.1.1.1
! Defines mobile router's home network as virtual network
ip mobile virtual-network 150.1.1.0 255.255.255.0
! Specifies mobile router on the virtual network
ip mobile host 150.1.1.1 virtual-network 150.1.1.0 255.255.255.0
! Specifies all the networks behind mobile router
ip mobile mobile-networks 150.1.1.1
 description network behind the mobile router
 network 140.80.1.0 255.255.255.0
! Enables security association between HA and MR
ip mobile secure host 150.1.1.1 spi 100 key ascii CISCO algorithm md5 mode prefix-suffix

Rack1R2 (FA)

!
interface Loopback0
 description care-of-address
 ip address 2.2.2.2 255.255.255.0
!
interface FastEthernet0/0
 description foreign network
 ip address 200.2.2.254 255.255.255.0
! Enables foreign agent service on an interface
 ip mobile foreign-service
 ip mobile registration-lifetime 60
! Enables IRDP
 ip irdp
 ip irdp maxadvertinterval 4
 ip irdp minadvertinterval 3
!
interface FastEthernet0/1
 description connected to internet
 ip address 180.1.27.2 255.255.255.0
!
! Enables Mobile IP
router mobile
!
! Enables foreign agent service globally with the care-of-address
ip mobile foreign-agent care-of Loopback0

Rack1R3 (MR)

!
interface Loopback0
 description mobile network
 ip address 140.80.1.1 255.255.255.0
!
interface Ethernet0/0
 description the roaming interface
 ip address 150.1.1.1 255.255.255.0
! Enables roaming on an interface
 ip mobile router-service roam
!
! Enables Mobile IP
router mobile
!
! Enables security association between MR and HA
ip mobile secure home-agent 1.1.1.1 spi 100 key ascii CISCO algorithm md5 mode prefix-suffix
! Enables the mobile router 
ip mobile router
 address 150.1.1.1 255.255.255.0
 home-agent 1.1.1.1

We will do some testing and verification when mobile router R3 is in the foreign network 200.2.2.0/24 on R2.

Rack1R1#show ip route | inc ^M
M       140.80.1.0 [3/1] via 0.0.0.0, 00:15:18, Tunnel0
M       150.1.1.1/32 [3/1] via 2.2.2.2, 00:15:18, Tunnel1

Rack1R1#show ip mobile binding 
Mobility Binding List:
Total 1
150.1.1.1: 
    Care-of Addr 2.2.2.2, Src Addr 2.2.2.2
    Lifetime granted 00:01:00 (60), remaining 00:00:55
    Flags sbdmg-t-, Identification CE22A5D5.F4C99770
    Tunnel1 src 1.1.1.1 dest 2.2.2.2 reverse-allowed
    MR Tunnel0 src 1.1.1.1 dest 150.1.1.1 reverse-allowed
    Routing Options - 
    Mobile Networks: 140.80.1.0/255.255.255.0 (S)

Rack1R1#sh ip mobile tunnel
Mobile Tunnels:

Total mobile ip tunnels 0
Tunnel0:
    src 1.1.1.1, dest 2.2.2.2
    encap IP/IP, mode reverse-allowed, tunnel-users 1
    Input ACL users 0, Output ACL users 0
    IP MTU 1480 bytes
    Path MTU Discovery, mtu: 0, ager: 10 mins, expires: never
    outbound interface FastEthernet0/1
    HA created, fast switching enabled, ICMP unreachable enabled
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute output rate 0 bits/sec, 0 packets/sec
    0 packets input, 0 bytes, 0 drops
    20 packets output, 23125 bytes
Tunnel1:
    src 1.1.1.1, dest 150.1.1.1
    encap IP/IP, mode reverse-allowed, tunnel-users 1
    Input ACL users 0, Output ACL users 0
    IP MTU 1460 bytes
    Path MTU Discovery, mtu: 0, ager: 10 mins, expires: never
    outbound interface Tunnel0
    HA created, fast switching enabled, ICMP unreachable enabled
Mobile Tunnels:

    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute output rate 0 bits/sec, 0 packets/sec
    0 packets input, 0 bytes, 0 drops
    20 packets output, 22725 bytes

Rack1R1#show ip mobile mobile-networks
Mobile Networks:
MR 150.1.1.1 [network behind the mobile router]:
    Configured: 140.80.1.0/255.255.255.0
    Registered:

Rack1R2#sh ip route | be Gateway
Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
O       1.1.1.0 [110/3] via 180.1.27.7, 15:28:38, FastEthernet0/1
O    222.22.2.0/24 [110/2] via 180.1.27.7, 15:28:48, FastEthernet0/1
     2.0.0.0/24 is subnetted, 1 subnets
C       2.2.2.0 is directly connected, Loopback0
O    200.6.6.0/24 [110/3] via 180.1.27.7, 15:28:48, FastEthernet0/1
     140.80.0.0/24 is subnetted, 1 subnets
O E2    140.80.1.0 [110/20] via 180.1.27.7, 00:29:32, FastEthernet0/1
     6.0.0.0/24 is subnetted, 1 subnets
O       6.6.6.0 [110/3] via 180.1.27.7, 15:28:48, FastEthernet0/1
C    200.2.2.0/24 is directly connected, FastEthernet0/0
     180.1.0.0/24 is subnetted, 3 subnets
O       180.1.17.0 [110/2] via 180.1.27.7, 15:28:48, FastEthernet0/1
C       180.1.27.0 is directly connected, FastEthernet0/1
O       180.1.67.0 [110/2] via 180.1.27.7, 15:28:48, FastEthernet0/1
     150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
O       150.1.1.0/24 [110/3] via 180.1.27.7, 00:29:32, FastEthernet0/1
M       150.1.1.1/32 [3/1] via 150.1.1.1, 00:30:09, FastEthernet0/0
                     [3/1] via 150.1.1.1, 00:00:08, FastEthernet0/0

Rack1R2#sh ip mobile tunnel
Mobile Tunnels:

Total mobile ip tunnels 0
Tunnel0:
    src 2.2.2.2, dest 1.1.1.1
    encap IP/IP, mode reverse-allowed, tunnel-users 1
    Input ACL users 0, Output ACL users 0
    IP MTU 1480 bytes
    Path MTU Discovery, mtu: 0, ager: 10 mins, expires: never
    outbound interface FastEthernet0/1
    FA created, fast switching enabled, ICMP unreachable enabled
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute output rate 0 bits/sec, 0 packets/sec
    20 packets input, 23125 bytes, 0 drops
    0 packets output, 0 bytes

Rack1R2#show ip mobile globals
IP Mobility global information:
Home Agent is not enabled

Foreign Agent

    Pending registrations expire after 7 secs
    Care-of addresses advertised
    Mobile network route injection disabled

        Loopback0 (2.2.2.2) - up

1 interface providing service
Encapsulations supported: IPIP and GRE
Tunnel fast switching enabled, cef switching enabled
Tunnel path MTU discovery aged out after 10 min
NAT UDP Tunneling support enabled
UDP Tunnel Keepalive 110
Forced UDP Tunneling disabled

Rack1R2#show ip mobile visitor 
Mobile Visitor List:
Total 1
150.1.1.1:
    Interface FastEthernet0/0, MAC addr 0006.533a.2581
    IP src 150.1.1.1, dest 200.2.2.254, UDP src port 434
    HA addr 1.1.1.1, Identification CE22AC48.A0CA5400
    Lifetime 00:01:00 (60) Remaining 00:00:32
    Tunnel0 src 2.2.2.2, dest 1.1.1.1, reverse-allowed
    Routing Options - 

Rack1R2#show ip mobile interface
IP Mobility interface information:
Interface FastEthernet0/0:
    IRDP (includes agent advertisement) enabled
    Prefix Length not advertised
    Lifetime is 60 seconds
    Foreign Agent service provided
    Foreign Agent challenge disabled
    Reverse tunnel not supported
    No registration required
    Not busy
    Home Agent access list:
    Registration revocation disabled
         Current number of visitors: 1

Rack1R3#sh ip route | be Gateway
Gateway of last resort is 200.2.2.254 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets
M       1.1.1.1 [3/1] via 200.2.2.254, 00:50:11, Ethernet0/0
     140.80.0.0/24 is subnetted, 1 subnets
C       140.80.1.0 is directly connected, Loopback0
     200.2.2.0/32 is subnetted, 1 subnets
M       200.2.2.254 [3/1] via 200.2.2.254, 00:50:11, Ethernet0/0
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.1.0 is directly connected, Ethernet0/0
M*   0.0.0.0/0 [3/1] via 200.2.2.254, 00:50:11, Ethernet0/0

Rack1R3#sh ip mobile tunnel
Mobile Tunnels:

Total mobile ip tunnels 1
Tunnel0:
    src 150.1.1.1, dest 1.1.1.1
    encap IP/IP, mode reverse-allowed, tunnel-users 1
    IP MTU 1480 bytes
    Path MTU Discovery, mtu: 0, ager: 10 mins, expires: never
    outbound interface Ethernet0/0
    MR created, fast switching enabled, ICMP unreachable enabled
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute output rate 0 bits/sec, 0 packets/sec
    20 packets input, 22725 bytes, 0 drops
    0 packets output, 0 bytes

Rack1R3#show ip mobile router

Mobile Router
    Enabled 08/03/09 21:04:42
    Last redundancy state transition NEVER

Configuration:
    Home Address 150.1.1.1 Mask 255.255.255.0
    Home Agent 1.1.1.1 Priority 100 (best) (current)
    Registration lifetime 65534 sec
    Retransmit Init 1000, Max 5000 msec, Limit 3
    Extend Expire 120, Retry 3, Interval 10

Monitor:
    Status -Registered-
    Active foreign agent 200.2.2.254, Care-of 2.2.2.2
    On interface Ethernet0/0
    Tunnel0 mode IP/IP

Rack1R6#ping 140.80.1.1 size 1460 df-bit 

Type escape sequence to abort.
Sending 5, 1460-byte ICMP Echos to 140.80.1.1, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

Rack1R6#ping 140.80.1.1 size 1461 df-bit 

Type escape sequence to abort.
Sending 5, 1461-byte ICMP Echos to 140.80.1.1, timeout is 2 seconds:
Packet sent with the DF bit set
M.M.M
Success rate is 0 percent (0/5)

Rack1R6#trace 140.80.1.1                 

Type escape sequence to abort.
Tracing the route to 140.80.1.1

  1 180.1.67.7 4 msec 4 msec 0 msec
  2 180.1.17.1 4 msec 0 msec 0 msec
  3 150.1.1.1 4 msec *  0 msec

 

Things to remember in BGP

 

1. BGP uses TCP port 179 for transport. Router with the higher BGP router-id initiates BGP session from a random port.
 
2. The interface from which the BGP router ID is taken does not have to be running BGP. Any valid IP address can be used as BGP router-id, even an address that is not locally configured on the router.
 
3. The BGP router-id must be the same as the OSPF router-id for redistributing the routes from OSPF to BGP or vice versa.
 
4. If the 'network …' command is configured with the 'mask' option under the BGP process, then an exact match (network/mask) must exist in the IP routing table in order to advertise this route into BGP regardless of 'auto-summary' / 'no auto-summary' command. But the 'network …' command configured without the 'mask' assumes the default classful mask and if 'auto-summary' is configured then BGP will advertise a classful network only if any subnets of the classful network exist in the IP routing table. Again if the 'network …' command is configured without the 'mask' option and if 'no auto-summary' is configured, then that router must have the exact classful network in the IP routing table in order to advertise it in BGP.
 
5. To accept and attempt BGP connections to the external peers residing on networks that are not directly connected, we need to use either 'neighbor ebgp-multihop …' or 'neighbor ttl-security …' command. These two commands are mutually exclusive. We can use another command 'neighbor disable-connected-check' to accomplish the same task if the BGP neighbor is one-hop away.
 
6. The synchronization rule states that an iBGP learned prefix cannot be considered best unless there is a matching IGP route for that BGP prefix. BGP only advertises what it considers the best path. This issue can be resolved (1) by redistributing BGP routes into the IGP, (2) by creating a full-mesh of IBGP routers and disabling the synchronization, or (3) by creating a GRE tunnel. When BGP is synchronizing with OSPF, the router ID must match in both protocols in order to make it work.
 
7. When a prefix is received from an eBGP neighbor, it is advertised to both eBGP & iBGP neighbors. When a prefix is received from an iBGP neighbor, it is advertised ONLY to eBGP neighbors and not to any iBGP neighbors. To advertise iBGP leaned routes to other iBGP peers requires the use of route-reflectors or confederations or a full-mesh of iBGP peers.
 
8. While sending BGP updates, EBGP peers modify the next-hop value to its own IP address. But iBGP peers do not modify it.
 
9. The ‘default-information originate’ command, however, requires explicit redistribution of the route 0.0.0.0. . Default routes can be injected into BGP in one of three ways: (1) using the 'network …' command (default route must exist in the local routing table), (2) using the 'default-information originate' command (a redistribution statement must also be configured to redistribute the default route from the local routing table to the BGP table), and (3) using the 'neighbor … default-originate [route-map route-map-name]' command (this method does not even check for the existence of a default route in the IP routing table). The 'default-information originate' command should not be configured with the 'neighbor … default-originate' command on the same router.
 
10. 'weight' and 'local-preference' are set inbound and they affect outbound traffic. But 'as-path' and 'med' are set outbound and they affect inbound traffic.
 
11. The weights assigned with the 'set weight …’ route-map command overrides the weights assigned using the 'neighbor… weight …' command.
 
12. Origin code 'i' is default on the BGP routes advertised by 'network ...', 'aggregate-address ...' (if all subnet has 'i'), and 'neighbor … default-originate' commands. And origin code '?' is default on the BGP routes advertised by 'redistribute ...', 'aggregate-address ...' (if any single subnet has '?', but can be changed using ‘attribute-map’ option), 'default-information originate', and 'bgp inject-map ...' commands.
 
13. When BGP originates a route with the ‘network …’ command, MED is copied from the metric of the original route.
 
14. BGP MED values are not passed beyond the receiving (neighbor) AS.
 
15. Enabling the ‘bgp deterministic-med’ command ensures the comparison of the MED variable when choosing routes advertised by different peers in the same autonomous system. Enabling the ‘bgp always-compare-med’ command ensures the comparison of the MED for paths from neighbors in different autonomous systems.
 
16. The default behavior of BGP routers that run Cisco IOS software is to treat routes without the MED attribute as having a MED of 0, making the route that lacks the MED variable the most preferred. The 'bgp bestpath med missing-as-worst' command can be configured to treat the route that missing MED as the least preferred one.
 
17. ‘bgp bestpath as-path ignore’ is a hidden command in Cisco IOS which allows BGP to not consider the AS path during best path route selection.
 
18. There are two ways to create an aggregate address under BGP. The first is to create a static route to null interface in the routing table for the aggregate address and then advertise it with the ‘network …’ command. The second way is to use the ‘aggregate-address …’ command.
 
19. By default when aggregation is configured in BGP, the 'atomic-aggregate' attribute is attached to the aggregate address if the 'as-set' argument is not used in the 'aggregate-address …' command. The 'as-set' argument reveals the AS numbers which can prevent a routing loop, and once 'as-set' is configured along with the 'aggregate-address …' command, the 'atomic-aggregate' attribute is automatically removed.
 
20. A router reflector and its clients are known collectively as a cluster. If the cluster contains a single route reflector, the cluster ID is the router ID of the route reflector. If the cluster contains multiple route reflectors, each RR must be manually configured with a cluster ID.
 
21. A client router in a route reflection cluster can peer with external neighbors, but the only internal neighbor it can peer with is a route reflector in its cluster or other clients in the cluster. Clients cannot peer with routers outside of their own cluster. However, the RR itself can peer with both internal and external neighbors outside of the cluster and can reflect their routes to its clients.
 
22. In case of route reflection, (1) routes from EBGP are advertised to EBGP, client, non-client (2) routes from client are advertised to EBGP, client, non-client (3) routes from non-client are advertised to EBGP, client.
 
23. When the 'no bgp client-to-client reflection' command is configured the RR does not reflect routes from one client to another. It does, however, continue to reflect routes from clients to peers outside of the cluster, and from peers outside of the cluster to clients.
 
24. Standard and extended BGP communities are removed from the reflected routes unless the 'neighbor ... send-community [both]' is configured on the route reflector. The link bandwidth community is removed from reflected route if the route-reflector performs IBGP multipath load-sharing for that route.
 
25. The “neighbor … nexthop-self” on router reflectors only affects the next hop of eBGP learned routes because the next hop of reflected routes should not be changed. To avoid a common configuration error for reflected routes, the “set ip next-hop” command should not be used in a route map to BGP route reflector clients.
 
26. Unlike route reflector environments in which only the route reflector itself has to support route reflection, all routers within a confederation must support the confederation functionality. 
 
27. EBGP routes external to the confederation are preferred over EBGP routes to member autonomous systems, which are preferred over iBGP routes.
 
28. AS_PATH types are AS_SEQUENCE, AS_CONFED_SEQUENCE, AS_SET, and AS_CONFED_SET. AS_SEQUENCE is an ordered set of AS numbers, and AS_SET is an unordered set of AS numbers. AS_CONFED_SEQUENCE and AS_CONFED_SET are the same as AS_SEQUENCE and AS_SET but are used only within BGP confederations.
 
29. When 'bgp bestpath med confed' command is configured, the router picks the confederation-internal path with the lowest MED and ignores the path with the external AS number.
 
30. BGP private autonomous system numbers are from 64,512 to 65,535
 
31. BGP prefixes can be filtered using (1) 'distribute-list', (2) 'prefix-list', (3) 'filter-list', (4) 'policy-list', (5) community/extended community lists, (6) 'route-map' .
 
32. For BGP, the ‘distance …’ command sets the administrative distance of the External BGP (eBGP) route. This command only affects the routing table and not the BGP table.
 
33. The 'network … backdoor' command has the same effect as the 'network …' command. The EBGP route is treated as a local BGP route, and the administrative distance is changed to 200. The difference is that the address specified by the network backdoor command is not advertised to EBGP peers.
 
34. iBGP routes are not redistributed into an IGP unless you use "bgp redistribute-internal" command under BGP routing process.
 
35. 'bgp inject-map ... exist-map ...' command injects prefixes in the local BGP RIB when a valid parent route exists. Only prefixes that are equal to or more specific than the aggregate route (existing prefix) can be injected. exist-map (route-map) must contain a 'match ip address prefix-list ...' command statement to specify the aggregate prefix and a 'match ip route-source prefix-list ...' command statement to specify the route source. If the parent route is a default route, we can inject any route out of it.
 
36. A BGP neighbor cannot be configured to work with both peer groups and peer templates. BGP peer templates and BGP peer groups are mutually exclusive.
 
37. Peer session template can inherit only one session template directly, but peer policy template can inherit multiple policy templates.
 
38. When the maximum number (as set by the ‘neighbor … maximum-prefix ...’ command) of prefixes are reached, the string "PfxRcd" appears in the entry, the neighbor goes to shutdown state, and the connection becomes idle.
 
39. No penalty is applied to a BGP peer reset when route dampening is enabled. Although the reset withdraws the route, no penalty is applied in this instance.
 
40. In case of iBGP multipath load sharing, when multiple iBGP paths installed in a routing table, a route reflector will advertise only one of the paths (one next hop).
 
41. For multiple paths to the same destination to be considered as multipaths, all attributes including weight, local preference, autonomous system path (entire attribute and not just length), origin code, MED, and IGP distance must be same. But if 'bgp bestpath as-path multipath-relax' command is configured, the AS paths still have to be the same length, but don't have to be identical.
 
42. Though BGP Multipath allows the installation of multiple BGP paths (for load sharing purpose) into the IP routing table for the same prefix, it does not affect the bestpath selection. A router still designates one of the paths as the best path and advertises this best path to its neighbors.
 
43. 'neighbor … dmzlink-bw' command can be used with eBGP and iBGP multipath features to enable unequal cost load balancing over multiple links. BGP can originate the link bandwidth community only for directly connected links to eBGP neighbors.
 
44. The 'bgp update-delay ...' command is used to tune the maximum time the software will wait after the first neighbor is established until it starts calculating best paths and sending out advertisements.
 
45. The routers configured with the “neighbor … local-as …” command prepend local-AS in inbound EBGP updates and prepend both actual AS number and local-AS number in outbound EBGP updates.
 
46. The “neighbor … local-as …” command is valid only if the peer is a true eBGP peer. It does not work for two peers in different sub-ASs in a confederation.
 
47. In a route-map, a continue clause can be executed, without a successful match, if a route map entry does not contain a match clause. But if a match clause exists, the continue clause is executed only if a match occurs. If no successful matches occur, the continue clause is ignored. The continue statement proceeds to the specified route map entry only after configured set actions (if any) are performed.
 
48. When multiple values are configured in the same community list statement, a logical AND condition is created. All community values must match to satisfy an AND condition. When multiple values are configured in separate community list statements, a logical OR condition is created. The first list that matches a condition is processed.
 
49. While redistributing OSPF into BGP, by default only OSPF intra-area and inter-area routes are redistributed into BGP.
 
50. When a BGP router with synchronization enabled has also a OSPF route (redistributed from BGP) for a iBGP-learned route, then the OSPF ASBR router-id must match the originating BGP router-id in order to synchronize BGP route with OSPF route.
 
51. An “update group” is a group of peers with a common outbound policy which will be converged as if they are in a peer-group.

 

EVC : Flexible VLAN Tag Rewrite

Following the previous post about Flexible Frame Matching, this new post describes the second major step in configuring service instances using the EVC framework : Flexible VLAN Tag Rewrite.

Each service instance can change the existing VLAN tag to be a new VLAN tag by adding, removing, or translating one or two VLAN tags. Flexible VLAN tag rewrite includes 3 main operations :

1) pop (remove an existing tag)
2) push (add a new tag)
3) translate (change one or two tags to another one or two tags) - this can be seen as a combination of pop and push operations

Theoretically, any existing combination of one or two VLAN tags can be changed to any new combination of one or two VLAN tags by just using a simple (as soon as you get the idea) line of configuration. Practically, there are some limitations what you'll see below.

These are the relevant CLI options under the service instance (you need first to have configured flexible frame matching for these to appear) :

7600(config-if-srv)#rewrite ingress tag ?
pop        Pop the tag
push       Rewrite Operation of push
translate  Translate Tag

Pop operation

7600(config-if-srv)#rewrite ingress tag pop ?
1  Pop the outermost tag
2  Pop two outermost tags

! remove one tag
7600(config-if-srv)#rewrite ingress tag pop 1 ?
symmetric  Tag egress packets as specified in encapsulation


! remove two tags
7600(config-if-srv)#rewrite ingress tag pop 2 ?
symmetric  Tag egress packets as specified in encapsulation

Push operation

7600(config-if-srv)#rewrite ingress tag push ?
dot1q  Push dot1q tag

! add one tag
7600(config-if-srv)#rewrite ingress tag push dot1q ?
<1-4094>  VLAN id

7600(config-if-srv)#rewrite ingress tag push dot1q 20 ?
second-dot1q  Push second dot1q tag
symmetric     Tag egress packets as specified in encapsulation


! add two tags
7600(config-if-srv)#rewrite ingress tag push dot1q 20 second-dot1q ?
<1-4094>  VLAN id

7600(config-if-srv)#rewrite ingress tag push dot1q 20 second-dot1q 30 ?
symmetric  Tag egress packets as specified in encapsulation

Translate operation

7600(config-if-srv)#rewrite ingress tag translate ?
1-to-1  Translate 1-to-1
1-to-2  Translate 1-to-2
2-to-1  Translate 2-to-1
2-to-2  Translate 2-to-2

! remove one tag and add one new tag
7600(config-if-srv)#rewrite ingress tag translate 1-to-1 dot1q 20 ?
symmetric  Tag egress packets as specified in encapsulation


! remove one tag and add two new tags
7600(config-if-srv)#rewrite ingress tag translate 1-to-2 dot1q 20 second-dot1q 30 ?
symmetric  Tag egress packets as specified in encapsulation


! remove two tags and add one new tag
7600(config-if-srv)#rewrite ingress tag translate 2-to-1 dot1q 20 ?
symmetric  Tag egress packets as specified in encapsulation


! remove two tags and add two new tags
7600(config-if-srv)#rewrite ingress tag translate 2-to-2 dot1q 20 second-dot1q 30 ?

symmetric  Tag egress packets as specified in encapsulation

Examples

interface GigabitEthernet1/2
!
service instance 10 ethernet
encapsulation dot1q 10
! remove one tag (10) on ingress
! add one tag (10) on egress
rewrite ingress tag pop 1 symmetric
!
service instance 20 ethernet
encapsulation dot1q 10 second-dot1q 20
! remove two tags (10/20) on ingress
! add two tags (10/20) on egress
rewrite ingress tag pop 2 symmetric
!
service instance 30 ethernet
encapsulation dot1q 30
! add one tag (300) on ingress
! remove one tag (300) on egress (if the resulting frame doesn't match tag 30, it's dropped)
rewrite ingress tag push dot1q 300 symmetric
!
service instance 40 ethernet
encapsulation dot1q 40
! add two tags (400/410) on ingress
! remove two tags (400/410) on egress (if the resulting frame doesn't match tag 40, it's dropped)
rewrite ingress tag push dot1q 400 second-dot1q 410 symmetric
!
service instance 50 ethernet
encapsulation dot1q 50 second-dot1q 1-4094
! remove one tag (50) and add one new tag (500) on ingress
! remove one tag (500) and add one new tag (50) on egress
! the inner tags (1-4094) remain unchanged
rewrite ingress tag translate 1-to-1 dot1q 500 symmetric
!
service instance 60 ethernet
encapsulation dot1q 60
! remove one tag (60) and add two new tags (600/610) on ingress
! remove two tags (600/610) and add one new tag (60) on egress
rewrite ingress tag translate 1-to-2 dot1q 600 second-dot1q 610 symmetric
!
service instance 70 ethernet
encapsulation dot1q 70 second-dot1q 100
! remove two tags (70/100) and add one new tag (700) on ingress
! remove one tag (700) and add two new tags (70/100) on egress
rewrite ingress tag translate 2-to-1 dot1q 700 symmetric
!
service instance 80 ethernet
encapsulation dot1q 80 second-dot1q 200
! remove two tags (80/200) and add two new tags (800/810) on ingress
! remove two tags (800/810) and add two new tags (80/200) on egress
rewrite ingress tag translate 2-to-2 dot1q 800 second-dot1q 810 symmetric

There are some important things to keep in mind when configuring Flexible VLAN Tag Rewrite.

1) You have to use the "symmetric" keyword, although the CLI might not give you this impression:

7600(config-if-srv)#rewrite ingress tag pop 1 ?
symmetric  Tag egress packets as specified in encapsulation


7600(config-if-srv)#rewrite ingress tag pop 1
Configuration not accepted by the platform
7600(config-if-srv)#rewrite ingress tag pop 1 symmetric
7600(config-if-srv)#

Generally rewrite configurations should always be symmetric. Whatever rewrites are on the ingress direction, you should have the reverse rewrites on the egress direction for the same service instance configuration. So, if you pop the outer VLAN tag on ingress direction, then you need to push the original outer VLAN tag back on the egress direction for that same service instance. All this is done automatically by the system when using the "symmetric" keyword. Have a look at the examples included above and check the comments to see what operations are happening on ingress and egress.

2) Due to the mandatory symmetry, some operations can only be applied to a unique tag matching service instance (so they are not supported for VLAN range configurations) or cannot be applied at all.

i.e.
You cannot translate a range of vlans

7600(config-if-srv)#encapsulation dot1q 10 - 20
7600(config-if-srv)#rewrite ingress tag translate 1-to-1 dot1q 30 symmetric
Encapsulation change is not logically valid.

You cannot pop a range of vlans

7600(config-if-srv)#encapsulation dot1q 10 second-dot1q 20,30
7600(config-if-srv)#rewrite ingress tag pop 2 symmetric
Encapsulation change is not logically valid.

If supposedly you could do the above, how could the opposite be done? i.e. if the system removed the tags from frames matching inner vlans 20,30 on the ingress, how would the system know on which frames to add 20 and on which to add 30 on the egress?

Of course you can push a new vlan over a range of vlans.

7600(config-if-srv)#encapsulation dot1q 10-20
7600(config-if-srv)#rewrite ingress tag push dot1q 30 symmetric

You can only push one or two tags for "encapsulation untagged" and "encapsulation default". No pop or translate operations are supported.

As a rule you can think of "you cannot pop or translate something that is not specifically defined as a single unit". Just imagine what would happen in the opposite direction and everything should become clear.

Keep in mind that some configurations might be accepted, but they won't work.

3) You cannot have more than one VLAN tag rewrite configuration under a single service instance. That means you can have either none or one. If there is no VLAN tag rewrite configuration, the existing VLAN tag(s) will be kept unchanged. If you need more than one, you might want to try to create more service instances using more specific frame matching criteria on each one. The translate operation might also seem useful in such conditions.

4) You need to be extra careful when using Flexible VLAN Tag Rewrite and Bridge Domains. Flooded (broadcast/multicast/unknown unicast) packets will get dropped by the service instances that do not agree on the egress tag. Although all service instances under a common bridge domain will get the flooded frame, there is an internal validation mechanism that checks whether the result of egress rewrite (based on the opposite of ingress rewrite) will allow the flooded frame to pass. The push operations under the examples show this behavior.

5) To have an EVC based port act like a L2 802.1q trunk port, you need to remove the outer tag manually and then put it under a bridge domain. On normal L2 switchports this is done automatically by the system.

So this

interface Gi1/1
 switchport
 switchport mode trunk
 switchport trunk allowed vlan 10

is equivalent to this

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 10

Note: The above examples were done on a 7600 with ES+ cards running 12.2(33)SRB IOS.

 

EVC : Flexible Frame Matching

EVC stands for Ethernet Virtual Connection and in Cisco's platforms it's used to represent Cisco's software architecture to address Carrier Ethernet Services. In MEF (Metro Ethernet Forum) terminology EVC means "Ethernet Virtual Connection/Circuit", but here EVC represents also the whole Carrier Ethernet software infrastructure developed by Cisco.

EVC has many advantages one of them being the Flexible Frame Matching. Flexible Frame Matching is a functionality that allows each service instance to match frames with either a unique single vlan, or a list/range of vlans. It can also match single/double tagged frames, untagged frames, or everything else that belongs to the default category.

Flexible Frame Matching is the first major step after configuring a service instance. This is the complete idea:

1) Service Instance definition (create the service instance)
2) Flexible frame matching (configure what frames need to be matched based on vlan match criteria)
3) Flexible VLAN tag rewrite (configure the action to do on the matched frames' vlan tags)
4) Flexible Service Mapping (map the service instance to a service)
5) Extra service features (apply some extra features on the service instance, i.e. QoS)

The middle 3 most important steps can also be described as:

a) Frame matching
b) Frame rewrite
c) Frame forwarding

Example

interface Gi1/1
 ! Service Instance definition
 ! ID is local port significant
service instance 10 ethernet
  ! Flexible frame matching
encapsulation dot1q 10 second-dot1q 20
  ! Flexible VLAN tag rewrite
rewrite ingress tag pop 1 symmetric 
  ! Service Mapping
xconnect 10.10.10.10 100 encapsulation mpls 
  ! Extra service features
service-policy input TEST-INPUT-POLICY

The current EVC implementation supports matching only on vlan tags, but in future we may see matching on other L2 fields too, since the hardware is quite capable.

These are the current supported vlan matching configurations:

• Single tagged frames, where match criteria can be a single vlan, a list/range of vlans, or any vlan (1-4094)

encapsulation dot1q 
encapsulation dot1q , 
encapsulation dot1q  - 
encapsulation dot1q any

• Double tagged frames, where first VLAN tag can be only single (software limitation), while second VLAN tag can be single, list/range, or any

encapsulation dot1q  second-dot1q 
encapsulation dot1q  second-dot1q , 
encapsulation dot1q  second-dot1q  - 
encapsulation dot1q  second-dot1q any

• Untagged frames, where all untagged frames are matched

encapsulation untagged

• Default tag frames, where all tagged/untagged frames that are not matched by other more specific service instances are matched

encapsulation default

Examples

interface Gi1/1
!
service instance 10
  ! single tagged frames with a specific tag
encapsulation dot1q 10
!
service instance 20
  ! single tagged frames with multiple tags
encapsulation dot1q 20,22,24,26-28
!
service instance 30
  ! single tagged frames with any tag
encapsulation dot1q any
!
service instance 40
  ! frames with a specific single outer tag and specific single inner tag
encapsulation dot1q 10 second-dot1q 20
!
service instance 50
  ! frames with a specific single outer tag and multiple inner tags
encapsulation dot1q 10 second-dot1q 20,22,24,26-28
!
service instance 60
  ! frames with a specific single outer tag and any inner tag
encapsulation dot1q 10 second-dot1q any
!
service instance 70
  ! frames without a tag
encapsulation untagged
!
service instance 80
  ! frames that do not match under any other service instance
encapsulation default

There are some important things to keep in mind when configuring Flexible Frame Matching.

1) When you have multiple vlan match criteria configured under different service instances of a single physical interface, the most specific is the one that wins (it's like the longest match rule used in the routing table). So the order of service instances under an interface doesn't have the same effect like the classes in MQC. This is because frame matching is done by hardware using the linecard's TCAM table, where each frame matching configuration gets converted to 1 or more TCAM entries (vlan lists/ranges in matching criteria are the most TCAM consuming configurations). The number of 16000 service instances per ES20 module is based on the assumption that each service instance uses a single TCAM entry.

2) When you don't get any match according to the above longest match rule, matching is done according to a looser match algorithm, where a single tag configuration matches all frames that have a common outer tag (regardless of the number of inner tags) and a double tag configuration matches all frames that have common the first 2 tags (regardless of the number of 2+ inner tags; btw, i'm planning of doing a triple-tag test soon).

Example

interface G1/1
service instance 10 ethernet
encapsulation dot1q 10
service instance 20 ethernet
encapsulation dot1q 10 second-dot1q 20
service instance 30 ethernet
encapsulation default

On the above configuration:

10/20 will be matched by service instance 20 (both tags matched)
10/30 will be matched by service instance 10 (outer tag matched)
20/30 will be matched by service instance 30 (no tag matched)

"encapsulation dot1q 10" matches "10", "10/20", "10/30" and so on.
"encapsulation dot1q 10 second-dot1q 20" matches "10/20", "10/20/30", "10/20/40" and so on.

Note: The above examples were done on a 7600 with ES+ cards running 12.2(33)SRB IOS.

 

Basics: What’s the Difference Between STP BPDU Guard and Root Guard

Courtesy - Ethereal Mind


BPDU Guard and Root Guard are enhancements to Spanning Tree Protocol (STP) enhancements that improve the reliability of the protocol to unexpected events.

Why ?

Remember that the purpose of the the Spanning Tree algorithm is to create a single path through the network to prevent loops because the Ethernet frame has no loop prevention mechanism. As a result an Ethernet network is always designed like an inverted tree like this:


There are loops in this design that are implemented for resilience ie. STP will block a given path in planned operation but an alternate path can be activated if the primary path fails.

However, STP is susceptible to various failures due to poor network design 1 or certain types of operational problems. Both BPDU Guard and Root Guard are used to enforce design discipline and ensure that the STP protocol operates as designed.

BPDU Guard

BPDU guard disables the port upon BPDU reception if PortFast is enabled on the port. This effectively denies devices connected to these ports from participating in the desgined STP thus protecting your data centre core.

Note: In the event of the BPDU being received the port will typically be shutdown in “errdisable” state and will require manually reenabling the port. Alternately you can configure the port to attempt to re-enable by configuring the “errdisable timeout”

Root Guard

Root guard allows the device to participate in STP as long as the device does not try to become the root. If root guard blocks the port, subsequent recovery is automatic. Recovery occurs as soon as the offending device ceases to send superior BPDUs.

Where ?

Because BPDU Guard and Root Guard are primarily to ensure design enforcement ( integrity / security) , they must configured in specific locations in the networks.

---

1. By “design” I mean that people add new switches in the wrong places which breaks that controlled design as shown here.

 

Realtime Chat between Cisco Routers

You might probably know that it's possible to send messages from one vty line to another on a single Cisco router.

R1#send ?
  *        All tty lines
  <0-17>   Send a message to a specific line
  aux      Auxiliary line
  console  Primary terminal line
  log      Logging destinations
  qdm      Send a message to QDM client
  vty      Virtual terminal
  xsm      Send a message to XSM client

R1#send 1
Enter message, end with CTRL/Z; abort with CTRL/C:
Hi
^Z
Send message? [confirm]

R1#

***
***
*** Message from tty0 to tty1:
***
Hi

There is a way to send automatically some custom-made udp packets from a Cisco router to a specific destination, in order to emulate the heartbeat mechanism of SixXS. Tcl seemed like a nice option, but as far as i know its implementation in Cisco IOS doesn't support extensions (Tcl doesn't have a builtin command for udp channels, so we must use an extension to enable it).

Asynchronous Serial Traffic Over User Datagram Protocol or UDPTN (UDP Telnet) is an IOS feature that provides the ability to encapsulate asynchronous data into UDP packets, and then unreliably transmit this data without needing to establish a connection with a receiving device. UDPTN is similar to Telnet in that both are used to transmit data, but UDPTN is unique in that it does not require that a connection be established with a receiving device.

Its usage is quite simple. You just have to enable udptn as an output transport under your vtys and then open a connection to the remote end.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#line vty 0 15
R1(config-line)#transport output ssh udptn
R1(config-line)#^Z
R1#

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#line vty 0 15
R2(config-line)#transport output ssh udptn
R2(config-line)#^Z
R2#

You have various options regarding the role of each device, but usually one end is transmitting and the other end is receiving. If you need 2-way communication, then you need to enable both directions. You can use any port above 1024 or just the default 57.

R1#udptn 1.1.1.2 3740 /transmit /receive
Trying 1.1.1.2, 3740 ... Open

R2#udptn 1.1.1.1 3740 /transmit /receive
Trying 1.1.1.1, 3740 ... Open

It becomes more interesting if you send packets to a multicast/broadcast address, so everyone having an open connection there will see the data.

There are some annoying things, like that you can't see locally the entered chars, or that you get chars on top of the previous chars (you can use spaces in order to clear the line), but you can't expect the full thing.

R2#udptn 1.1.1.1 3740 /transmit /receive
Trying 1.1.1.1, 3740 ... Open
How are you doing today?     ! This was typed on R1

R1#udptn 1.1.1.2 3740 /transmit /receive
Trying 1.1.1.2, 3740 ... Open
Fine, thanks                 ! This was typed on R2

Voila! You just made it possible to have a chat with your friend at a remote Cisco router! If you want to stop the session, you can use Ctrl-Shift-6 + x and then enter the "disconnect" command.

There are 2 terminal options that can be configured under source vtys and can change the behavior of text output:

dispatch-timeout 10000 : This one makes the packets be transmitted every 10 secs
dispatch-character 13 : This one causes the current number of typed chars to be sent after you press Enter (ASCII 13). By default each char is sent immediately.

Note : Because of its ability to send raw UDP datagrams that might conflict with other protocols, UDPTN has an implicit access list that only allows UDPTN connections to UDP port 57 (default) or UDP ports greater than 1024.

If only now i could find a way to send such messages automatically, i would probably solve my initial issue. EEM doesn't provide a mechanism to feed chars into a remote session and the Tcl "typeahead/exec" solution makes the process get stuck (and i can't find a way to clear it). Any idea how to send Ctrl-Shift-6 + x?
 

Understanding Spanning Tree Protocol

Spanning-tree Protocols
802.1d (Standard Spanning-tree)
So the entire goal of spanning-tree is to create a loop free layer 2 domain. There is no TTL in a layer 2 frame so if you don’t have spanning-tree, a frame can loop forever. So the original 802.1d standard set out to fix this. There are a few main pieces to the 802.1d process. They are…

1. Elect a root bridge.
This bridge is the ‘root’ of the spanning-tree. In order to elect a root bridge, all of the switches send out BPDU (Bridge Protocol Data Units). The BPDU has a bridge priority in it which the switches use to determine which switch should be the root. The lowest ID wins. The original standard specified a bridge ID as…

 

As time progressed there became a need to create multiple spanning-trees for multiple VLANs (we’ll get to that later). So, the bridge ID format had to be changed. What they came up with was..

 

 

So, now you know why you need to have a bridge priority that’s in multiples of 4096 (if you don’t.. A total of 4 bits gives you a total of 16 values, 16 * 4096 gives you 65,536 which is the old bridge priority max value – 1).

 

So at this point, we have a mess of switches swarming around with BPDUs. If a switch receives a BPDU with a lower bridge priority it knows that it isn’t the root. At that point, it stops sending out it’s own bridge ID and starts sending out BPDUs with the better (lower) priority that it heard of. In the end, all of the switches will be forwarding BPDUs with the lowest bridge ID. At that point, the switch originating the best(lowest) bridge ID knows that it is the root bridge.

 

2. Each switch selects a root portSo now that we know which switch is the root, every non-root switch needs to select it’s root port. That is, the port with the lowest cost to the root switch. To determine this, the root port sends ‘Hellos’ out of all of it’s port every 2 seconds. When a non-root switch receives the hello, it does a couple of things. First, it reads the ‘cost’ from the hello message and updates it by adding the port cost. So if a hello came in a fast Ethernet port with a cost of 4, the switch would add 19 to it giving you a new cost of 23. After all of the hellos are sent, the switch picks it’s root port by selecting the port which had the lowest calculated cost. Now, a bit about port costs. See the table below…

Interface Speed	Original IEEE Port Cost	New IEEE port Cost
10 Mbps	100	100
100 Mbps	10	19
1000 Mbps	1	4
10000 Mbps	1	2

So as you can see, with the increase in speed came a upgrade to the port costs. Now that we have 40 gig interfaces I’m wondering if they will redo that again. At any rate, if there is a tie, say two ports that have a calculated cost of 23. The switch breaks the tie in the following fashion..

1. Pick the lowest bridge ID of switch that sent the hellos
2. Pick the lowest port priority of the switch that sent the hellos
3. Use the lowest port number of the switch that sent the hellos
(We’ll talk about port priorities in a bit) Now that we have a root port we can move onto step 3.

3. Pick a designated portThis part is pretty easy. Basically, each segment can only have one designated port. The switch that forwards the lowest cost hello onto a particular segment becomes the designated switch and the port that it uses to do that is the designated port. So, that would mean that each port on the root bridge would be a designated port. Then, ports that are neither root ports or designated ports (non-designated ports) go into blocking state. If a tie occurs, the same tiebreaker process occurs as in step 2.

At this point, we have a fully converged spanning-tree!

Normal OperationUnder normal operation the root sends hellos out of all it’s active ports. Each connected switch receives the hellos on their root ports, updates it, and forwards it out of it’s designated port (if it has one). Blocked ports receive the hellos, but never forward them.

Topology Changes
When a switch notices a topology change, it’s responsible for telling all other connected switches about the change. The most effective way to do this, is to tell the root switch so that it can tell all of the other switches. When a switch notices a topology change, it sends a TCN (topology change notification) out it’s root port. The switch will send the TCN every hello time until the upstream switch acknowledges it. The upstream switch acknowledges by sending a hello with a TCA (topology change acknowledgement). This process continues until the root becomes notified. The root will then set the TC flag on it’s hellos. When switches in the tree see the TC set in the hello from the root, they know that there has been a topology change and that they need to age out their CAM tables. Switches aging out their CAM tables is an important part of a topology change and reconvergence.

802.1D Port States

Blocking – The port is blocking all traffic with the exception of receiving STP BPDUs. The port will not forward any frames in this state.
Listening – Same as blocking but will now begin to send BPDUs.
Learning – The switch will begin to learn MAC information in this state.
Forwarding – Normal full up and up port state. Forwarding normal traffic.

TimingThere are a couple of main timers in the STP protocol. These are..
Forward Delay Timer – Default of 15 seconds
Hello – Default of 2 seconds
MaxAge – Default of 20 seconds

Spanning-Tree enhancements (Cisco Proprietary)
PortFast – Immediately puts a port into forwarding mode. Essentially disables the STP process. Should only be used for connecting to end hosts.
UplinkFast – Should be used on access layer switches connecting to distribution. Used to fail over the root port in the case of the primary root port failing. CAM entries are timed out by the access layer generating multicast frames with attached devices MACs as the source for the frames. This is different than the normal TCN process as described earlier. UplinkFast also causes the switch to increase the root priority to 49152 and set all of the ports costs to 3000.
BackboneFast – Used to detect indirect STP failures. This way the switch doesn’t have to wait MaxAge to reconverge. The feature needs to be configured on all switches in order for it to work. The switch queries it’s upstream switches when it sops receiving hellos with a RLQ (Root Link Query). If the upstream switch had a failure it can reply to the local switch so that it can converge to another port without waiting for the MaxAge to expire.

802.1w (Rapid Spanning-Tree)
Rapid spanning-tree takes 802.1d and makes it faster. In addition, they take some of the Cisco proprietary features and standardize them. Here are some of the notable changes that 802.1w makes.

-Switches only wait to miss 3 hellos on their root port prior to reconverging. This number in 802.1d was 10 (MaxAge, or 10 times hello).
-Fewer port states. 802.1w takes the number of port states from 5 (Im counting disabled) down to 3.

The new states are discarding, learning, and forwarding.
-Concept of a backup DP when a switch has multiple ports connected to the same segment.
-Standardization of the Cisco proprietary PortFast, UplinkFast, and BackboneFast.

802.1w Link TypesPoint to Point – Connects a switch to another switch in full duplex mode.
Shared – Connects a switch to a hub using half duplex
Edge – A user access port

802.1w Port roles
Root Port – The same as in 802.1d
Designated Port – The same as in 802.1d
Alternate Port – Same as the uplink fast feature, backup RP connection
Backup Port – Alternate DP port, can take over if the existing DP fails

802.1s (Multiple Spanning-Tree)
Multiple spanning-tree (MST) lets you map VLANs into a particular spanning tree. These VLANs are then considered to be part of the same MST region. MST uses the same features as RSTP for convergence, so if you are running MST, you are by default also running RSTP. Much like any other ‘group’ technology, there are several parameters that must be met before switches/vlans can become part of the same region.

-MST must be globally enabled
-The MST region name must be configured (and the same on each switch)
-Define the MST revision number (and make it the same on each switch)
-Map the same VLANs into each region (or instance)

MST can con-exist with other switches that don’t talk MST. In this case, the entire MST region appears to be a single switch to the other ‘external’ spanning-tree. The spanning-tree that connects the region to the ‘outside’ is considered to be the IST, or Internal Spanning Tree.

Spanning-tree Protection
There are several ‘protection’ mechanisms available that can be implemented in conjunction with spanning-tree to protect the spanning-tree from failure or loops.

BPDU Guard – Should be enabled on all ports that will never connect to anything but an end user port. The configuration will err-disable a port if a BPDU is received on that port. To recover from this condition the port must be shut/no shut.

Root Guard – Protects the switch from choosing the wrong RP. If a superior BPDU is heard on this port the port is placed into root-inconsistent state until the BPDUs are no longer heard.

UDLD – Unidirectional link detection is used to detect when one side (transmit or receive) is lost. States like this can cause loops and loss of connectivity. UDLD functions in two modes, aggressive and normal. Normal mode uses layer 2 messaging to determine if a switches transmission capabilities have failed. If this is detected, the switch with the failed transmit side goes into err-disable. In aggressive mode the switch tries to reconnect with the other side 8 times. If this fails, both sides go into err-disable.

Loop Guard – When a port configured with loop guard stops hearing BPDUs it goes into loop-inconsistent state rather than transitioning into forwarding.
 

Difference between NX-OS and IOS

NX-OS is derived from the Cisco MDS (storage) switches and converted in order to make it work with Cisco Switching technology. It’s designed to support high performance and high realibility networks in the datacenter. It’s really based on MontaVista Software embedded Linux, which you can still discover when it boots up. NX-OS is still command line but some of the commands might be different comparing it to IOS.

One of the important differences is that NX-OS is driven by a license model whereas IOS just cared about which image you ran. in NX-OS all features are there, you just need to enable them and activate a valid license for it.

Interfaces behave a bit differently in NX-OS. In IOS you had a difference between FastEthernet, Ethernet and GigabitEthernet (even TenGigabitEthernet) interfaces. No more in NX-OS. You just have ‘Ethernet’ interfaces. Below you see a ‘show int brief’ on a Nexus 5000 series :

switch(config)# sh int brief

-------------------------------------------------------
Ethernet      VLAN   Type Mode   Status  Reason  Speed     Port
Interface                                                                   
--------------------------------------------------------
Eth1/1        1      eth  access down    SFP validation failed       10G(D) --
Eth1/2        1      eth  access down    SFP not inserted            10G(D) --
Eth1/3        1      eth  access down    SFP validation failed       10G(D) --
Eth1/4        1      eth  access down    SFP not inserted            10G(D) --
Eth1/5        1      eth  access down    SFP validation failed       10G(D) --
Eth1/6        1      eth  access down    SFP not inserted            10G(D) --
Eth1/7        1      eth  access down    SFP validation failed       10G(D) --
Eth1/8        1      eth  access down    SFP not inserted            10G(D) --
Eth1/9        1      eth  access down    SFP not inserted            10G(D) --
Eth1/10       1      eth  access down    SFP not inserted            10G(D) --
Eth1/11       1      eth  access down    SFP not inserted            10G(D) --
Eth1/12       1      eth  access down    SFP not inserted            10G(D) --
Eth1/13       1      eth  access down    SFP not inserted            10G(D) --
Eth1/14       1      eth  access down    SFP not inserted            10G(D) --
Eth1/15       1      eth  access down    SFP not inserted            10G(D) --
Eth1/16       1      eth  access down    SFP not inserted            10G(D) --
Eth1/17       1      eth  access down    SFP not inserted            10G(D) --
Eth1/18       1      eth  access down    SFP not inserted            10G(D) --
Eth1/19       1      eth  access down    SFP not inserted            10G(D) --
Eth1/20       1      eth  access down    SFP not inserted            10G(D) --
Eth2/1        1      eth  access down    SFP not inserted            10G(D) --
Eth2/2        1      eth  access down    SFP not inserted            10G(D) --
Eth2/3        1      eth  access down    SFP not inserted            10G(D) --
Eth2/4        1      eth  access down    SFP not inserted            10G(D) --
Eth2/5        1      eth  access down    SFP not inserted            10G(D) --
Eth2/6        1      eth  access down    SFP not inserted            10G(D) --

Notice all interfaces are marked ‘Ethx/x’.

There are some important points you need to know before deploying a Nexus in your switching environment :

• SVI command-line interface (CLI) configuration and verification commands are not available until you enable the SVI feature with the feature interface-vlan command.
• Tunnel interface command-line interface (CLI) configuration and verification commands are not available until you enable the Tunnel feature with the feature tunnel command.
• Interfaces support stateful and stateless restarts after a supervisor switchover for high availability.
• Only 802.1q trunks are supported, so the encapsulation command isn’t necessary when configuring a layer-2 switched trunk interface. (Cisco ISL is not supported)
• An IP subnet mask can be applied using /xx or xxx.xxx.xxx.xxx notation when configuring an IP address on a layer-3 interface. The IP subnet mask is displayed as /xx in the configuration and show interface command output regardless which configuration method is used.
• The CLI syntax for specifying multiple interfaces is different in Cisco NX-OS Software. The range keyword required in Cisco IOS Software has been omitted from the syntax (IE: interface ethernet 1/1-2), and the interface range can be configured in ascending or descending order. Cisco IOS Software requires the interface range to be configured in ascending order.
• When monitoring interface statistics with the show interface CLI command, a configurable load-interval can be configured per interface with the load-interval counters command to specify sampling rates for bit-rate and packet-rate statistics. The Cisco IOS Software supports the load-interval interface command, but doesn’t support multiple sampling rates.
• I/O modules have a locator-LED (beacon) that allows remote-hands-support personnel to easily identify a specific port. The beacon light can be enabled per interface in interface configuration mode with thebeacon CLI command.
• An administrator can configure port profiles as templates that can be applied to a large number of interfaces to simplify the CLI configuration process. Port profiles are “live” configuration templates, so modifications to a port profile are automatically applied to the associated interfaces. Cisco IOS uses port macros to simplify the CLI configuration process, but unlike Port Profiles they are applied one time.
• The supervisor module out-of-band management ethernet port located on the supervisor module is configured with the interface mgmt 0 CLI command.
• The supervisor module out-of-band Connectivity Management Processor (CMP) port is configured in the NX-OS with the interface cmp module <#> CLI command. The CMP port can also be configured by attaching to the CMP using the attach cmp CLI command.
• The NX-OS support Nexus 2000 (models 2224TP, 2248TP, 2232PP) Fabric Extender (FEX) connectivity. The parent Nexus 7000 manages Nexus 2000’s software and CLI configuration, so the Nexus 7000 is a single managed entity for all connected Nexus 2000′s. Nexus 2000 host ports are configured using the interface ethernet CLI command. A Nexus 2000 can only be connected to the 10GE M1, M1-XL and F2 modules (Please read the documentation on cisco.com to understand port connectivity restrictions.)
• Proxy ARP is disabled on all interfaces by default.

The following list provides some additional facts about the Cisco NX-OS that should be helpful when configuring interfaces.

• An interface can only be configured in 1 VDC at a time.
• When assigning interfaces to a VDC on the 48 port SFP/UTP M1 series modules there are no restrictions.
• When assigning interfaces to a VDC on the 32 port 10GE M1 series modules, all four interfaces in a port group (IE. group 1 =1,3,5,7 group 2 =2,4,6,8, etc.) must be assigned to the same VDC.
• When assigning interfaces to a VDC on the 32 port 1/10GE F1 Series module, both ports in a port group (IE. 1-2, 3-4, etc.) must be assigned to the same VDC.
• When assigning interfaces to a VDC on the 48 port 1/10GE F2 Series module, all four ports in a port group (IE. 1-4, 5-8, etc.) must be assigned to the same VDC.
• When assigning interfaces to a VDC on a Nexus 2224TP, 2248TP, 2232PP all interfaces must belong to the same VDC.
• One 10 GE interface per port group can be configured in dedicated mode using the rate-mode dedicated interface CLI command on the M1 series modules (The remaining three ports are disabled).
• The mgmt 0 port is associated to all configured VDCs allowing TELNET/SSH and IP management applications such as SNMP to access the VDC directly. All mgmt 0 ports must be configured in the same IP subnet.
• The default port type is configurable for L3 routed or L2 switched in the setup startup script. (L3 is the default port type prior to running the script)
• A layer-2 switched trunk port sends and receives traffic for all VLANs by default (This is the same as Cisco IOS Software). Use the switchport trunk allowed vlan interface CLI command to specify the VLANs allowed on the trunk.
• The clear counters interface ethernet CLI command resets the counters for a specific interface.
• An interface configuration can be reset to its default values with the default interface global configuration command.
• The 48 port UTP M1 series module supports Time Domain Reflectometry (TDR) cable diagnostics. All 12 ports in a port group must be shutdown prior to running the test cable-diagnostics tdr interface ethernet CLI command. The results can be verified with the show interface ethernet cable-diagnostics-tdr command.

Another big thing in the NX-OS software is the virtualization methods. In the Nexus 7000 series you are able to create VDC’s. These VDC’s stand for Virtual Device Contexts and in fact duplicate a complete switch seperated from your other VDC’s. Talk about virtualization! Every VDC has it’s own CAM table, own VLAN’s, own everything! The hardware itself is the only shared part of this solution.

Next to VDC’s, the NX-OS software introduced VPC technology. This stands for Virtual Portchannel. Using this technology you can build high available, non-blocking designs using all Nexus switches.
 

Cisco Guide to Harden Cisco IOS Devices

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml



 

Collection Of Cisco Commands Used For Configuration

 

Below is collection of Cisco commands that are often used in configuration. It covers 90% of CCNA commands.

__
Basic commands

enable - Priviliged exec mode
conf t - Enters global configuration
hostname - Renames router to
exit - Back once
end - Back to #

banner motd * - Editing banner, end with *
enable secret - Set enable password to

int x - Configure interface x
ip add IP MS - Set IP and MaSk for interface
no sh - Starts interface (w/ sh close int)
clock rate - Clock rate n for serial ports
bandwidth - Set bandwidth n in kilobit

line console x - Configure line x
line vty x - Configue vty x
password x - Password x for line
login - Logs in for password

service password-encryption - Encrypts password
no ip domain-lookup - No ip domain lookup
ip default-gateway - Default gateway (when no routing)
ip default-network - Default network (when there is routing)
ip route 0.0.0.0 0.0.0.0 - Default route address to 0, from/to (x=ip or int)
ip route - Static route from/to ip or interface
ip route - is the value for administrative distance
logging trap debugging - Shows all console messages

copy run start - Copies running config to startup
erase startup - Erases startup config
delete flash: - Delete from flash memory

__
Basic sh/debug commands

sh history - Shows history
sh run/start - Shows running/start config
sh int - Shows interfaces
sh arp - Shows arp
sh ip ro - Shows ip routes
sh prot - Shows protocols
sh users - Shows users

sh ip route
sh protocols
sh interface

debug ip rip/eigrp/ospf

__
SSH and user

hostname
ip domain name
crypto generate rsa

line vty 0 4
no transport input
transport input ssh

username privilege secret - Creates xy user with privelege(0-15) password

__
DHCP commands

ip dhcp pool x - Makes a dhcp pool with name x and enters
network ip ms - Gives IP and mask for dhcp pool
ip dhcp excluded-add ip ip - Excluded addresses (ex. 192.168.1.7-10)
dns-server ip - DNS server for dhcp
domain-name x - Configures x domain name
default-router ip - The default router address (switch)
lease n - Lease time (n) for dhcp clients

DHCP for VLANs

1. Create vlans (vlan 10) and assign vlan to port
1. Create trunk link
2. Create subint (int fa0/0.10)
3. Set encapsulation dot1q and IP address
4. Make dhcp pool
5. In pool set "default route"
6. Request dhcp

Note --> default route = int ip address

__
ACLs

1-99: standard
100-199: extended
2000-2699: extended

access-list 1 permit - Permits on acl 1
access-list 101 permit - Permits on acl 101
ip access-list - ACL using a name and (config-ext-nacl)#

Example:
access-list established
access-list 1 permit tcp 192.168.1.0 0.0.255.255 any eq 80 established

lt = less than
gt = greater than
neq = not equal
eq = equal
range = range of ports

int
ip access-group - Sets ACL on interface

__
NAT/PAT commands

Static NAT
ip nat inside - On interface, inside int
ip nat outside - On interface, outside int
ip nat inside source static - Global NAT config
ip nat outside source static - Global NAT config

Dynamic PAT
ip nat pool netmask - Makes a pool from to
ip nat source list pool - Uses an ACL on pool as NAT

Port Translation
ip nat source list interface overload - Configues PAT using ACL

sh ip nat translations
sh ip nat statistics

__
Switch Port security commands

switchport mode access - Turns on access mode
switchport port-security - Enables port security
switchport port-security mac - Enables port security statically
switchport port-security maximum n - Sets maximum number of secure addresses to n
switchport port-security mac-address sticky - Enables sticky learning for MAC

__
VLANs and VTP

sh dtp interface - To determine current settings

__
STP
spanning-tree vlan 1-4094 priority
spanning-tree vlan 1-4094 root primary
spanning-tree vlan 1-4094 root secondary

__
CDP commands

cdp run - Enables CDP
no cdp run - Disables CDP
cdp enable - Enable CDP for interface
no cdp enable - Disable CDP for interface
sh cdp x - Shows CDP (x=entry/interface/neighbor)

__
RIP
router rip - Router rip config
version - Sets version
network - Sets given ips for RIP
default-information originate - Advertise static routes

Secure RIP

Int-->
ip rip auth mode md5 - Use md5 for rip
ip rip auth key-chain - Use key chain for md5 (key chain needed!)

__
EIGRP

router eigrp - Router EIGRP config with AS number
network - Sets network info for share
no auto-summary - Disables auto-summary
redistribute - Shares routes: static, rip, ospf..etc
auto-summary - Enables auto summarization
passive-interface - Disables eigrp on an interface

Interface
ip summary-address eigrp as ip ms - Manual summarization
ip hello-interval eigrp as n - Eigrp hello interval, n=seconds
ip hold-time eigrp as n - Eigrp hold-timer, n= sec from 1 to 65535

sh ip eigrp topology ip - EIGRP Topology on ip

Secure EIGRP

router rip
passice-int default
no passive-int - turn off passives

Int-->
ip auth mode eigrp md5 - Use md5 for eigrp
ip auth key-c eigrp - Use key-chain for eigrp

__
OSPF
ip ospf
network - Sets network info for share
router-id - Router ID
clear ip ospf proces - Restarts ospf
passive interface - Disables ospf on an interface
default-information originate - Advertise static routes

int -
ip ospf priority - Priority on interface
ip ospf cost - Cost of interface
auto-cost reference - Bandwith
ip ospf hello-interval - Hello interval in sec
ip ospf dead-interval - Dead interval in sec

DR (highest ospf prio) > BDR
Backup Designated Router, others are DROthers. DR updates all.

Secure OSPF

router ospf
area auth message-dig

Int-->
ip ospf message-digest-key md5
ip ospf auth message-dig

__
BGP commands

router bgp n - Sets n as AS number for the router
neighbor ip remote_as n - Identifies bgp neighbor (for CPE)
network ip mas - Sets router's network address
metric weights tos k1-k5 - Changes metric for routing

__
Frame Relay

int x
encapsulation frame-relay - Needed for subintercae too!
frame-relay map ip - Give other side's DLCI
frame-relay map ip br - Sends broadcast too
sh fr map
sh fr pvc

int . point-to-point
frame-relay interface-dlci - Self DLCI number!

__
TFTP recovery

IP_ADDRESS - IP address on the LAN interface
IP_SUBNET_MASK - Subnet mask for the LAN interface
DEFAULT_GATEWAY - Default gateway for the LAN interface
TFTP_SERVER - IP address of the TFTP serve
TFTP_FILE - Cisco IOS filename on the server
tftpdnld - download

Test network throughput with TTCP

TTCP is hidden IOS command designed to measure network throughput. In order to use TTCP you need to configure a sender and a receiver. Keep in mind this will result in increased Router load.

R2#ttcp transmit 192.168.1.1
 
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> 192.168.1.1
ttcp-t: connect (mss 1460, sndwnd 4128, rcvwnd 4128)
ttcp-t: 16777216 bytes in 75696 ms (75.696 real seconds) (~215 kB/s) +++
ttcp-t: 2048 I/O calls
ttcp-t: 0 sleeps (0 ms total) (0 ms average)

R1#ttcp receive
 
ttcp-r: buflen=8192, align=16384/0, port=5001
rcvwndsize=0, delayedack=yes  tcp
ttcp-r: accept from 192.168.1.2 (mss 1460, sndwnd 4128, rcvwnd 2668)
ttcp-r: 16777216 bytes in 75696 ms (75.696 real seconds) (~215 kB/s) +++
ttcp-r: 8330 I/O calls
ttcp-r: 0 sleeps (0 ms total) (0 ms average)