Tuesday, April 30, 2013

Things to Remember in OSPF


DR and BDR

DR - Designated Router and BDR backup designated Router are Routers on a Broadcast segment. For example Ethernet a DR and optionally an BDR is chosen. The election is based on
  • The highest priority on the interface
    • Default priority is 1. Can be set in the range 0 - 255
    • If priority is set to 0 the router can not be a DR
    • The priority is set on a per-link basis.
  • The highest RID - Router ID
interface fastethernet 0/0
 ip ospf priority 255

RID: Router ID

The RID is the IP address which the Router is known as.
  1. Set manually
  2. Highest Loopback IP address
  3. Highest IP address if no Loopbacks defined
interface Loopback 0
 ip address 10.10.10.1
!
interface Loopback 1
 ip address 192.168.10.1
!
router ospf 1
  router-id 10.10.10.1

Stub Areas

OSPF RFC's describe Stub and Not-So-Stubby-Area. Totally Stub Area is a Cisco proprietary standard.

What is Stub Areas

Stub Areas are part of a network which don't need to have a copy of the total Link-State database. It reduces the memory requirements and CPU overhead of the router. Often stub areas only have a default gateway.

Stub Area

  • Stub Areas blocks Type 5 LSA's. (External Routes)
    • Routing to the outside world is based on a default route.
    • A Stub Area will accept Summary Routes from other Areas.

Totally Stub Area

  • totally Stub Areas blocks Type 3,4 and 5 LSA's. Only a default gateway.
    • Has a default route out of the Area,

NSSA: Not So Stubby Area

  • A NSSA imports a limited number of External Routes. The number of Routes is limited to those Routes required to provide connectivity between Areas.

Example

Example

Stub Area example


Example

Totally Stub Area example


Example

NSSA: Not So Stubby Areas


Example

Example

Example

Example

Virtual links


Example

Example

Example

Single Area configuration

Example 1


Example network 1



hostname R1
!
interface fastethernet 0/0
  ip address 192.168.0.1 255.255.255.0
!
interface fastethernet 0/1
  ip address 10.0.1.1 255.255.255.0
!
router ospf 88
  network 192.168.0.0 0.0.0.255 area 0
  network 10.0.1.0 0.0.0.255 area 0
hostname R2
!
interface fastethernet 0/0
  ip address 192.168.0.2 255.255.255.0
!
interface fastethernet 0/1
  ip address 10.0.2.1 255.255.255.0
!
router ospf 77
  network 192.168.0.0 0.0.0.255 area 0
  network 10.0.2.0 0.0.0.255 area 0
hostname R3
!
interface fastethernet 0/0
  ip address 192.168.0.3 255.255.255.0
!
interface fastethernet 0/1
  ip address 10.0.3.1 255.255.255.0
!
interface serial 0/0
  ip address 172.16.0.1 255.255.255.252
!
router ospf 66
  network 192.168.0.0 0.0.0.255 area 0
  network 10.0.3.0 0.0.0.255 area 0
  network 172.16.0.0 0.0.0.3 area 0
hostname R4
!
interface fastethernet 0/1
  ip address 10.0.4.1 255.255.255.0
!
interface serial 0/0
  ip address 172.16.0.2 255.255.255.252
router ospf 66
  network 172.16.0.0 0.0.0.3 area 0
  network 10.0.4.0 0.0.0.255 area 0

Default administrative Distance

 

Cisco implementation


Default Administrative Distance (metric)
Route SourceDistance
Connected Interface0
Static Route out an Interface0
Static Route to a next hop1
EIGRP summary route5
External BGP20
Internal EIGRP90
IGRP100
OSPF110
IS-IS115
RIP (Version 1 og 2)120
EGP140
ODR (On Denmand Routing)160
External EIGRP170
Internal BGP200
Ukendt source255

 

LSA Types

 

LSA Types
Type ABR Sent to Meaning
1 O 224.0.0.5 Router Link: Indeholder alle Routerens Links. Floodes til Area
2 O 224.0.0.6 Network Link: Floodes fra DR til Area. Indeholder alle Naboer på MA-medie
3 O IA Summary Link: Sendes fra Area til Area gennem ABR. Indeholder IA Summaries.
4 O IA ASBR summary Link: Sendes fra ASBR’s. Indeholder externe router.
5 O E1/2 Externe Router fra ASBR. E1 intern + extern cost. E2 kun extern cost.
7 O E1/2 Externe Routes fra ASBR i NSSA
8 OSPF and BGP internetworking
9,10,11 Opaque LSA used by Cisco for MPLS

 

The following are descriptions of each type of LSA.

 

Type 1


Every router generates router link advertisements for each area to which it belongs. A type 1 LSA describes the collective states of the directly connected links (interfaces) of the router. These LSAs are flooded only within the area in which they are originated.

 

  Type 2


A type 2 LSA is generated for every transit broadcast and NBMA network within an area. A transit network has at least two directly attached OSPF routers. Ethernet is an example of a transit network.
The DR of the network is responsible for advertising the network LSA. A type 2 network LSA lists each of the attached routers that make up the transit network, including the DR itself, as well as the subnet mask used on the link. The type 2 LSA then floods to all routers within the transit network area. Type 2 LSAs never cross an area boundary. The link-state ID for a network LSA is the IP interface address of the DR that advertises it.

Type 3


The ABR sends type 3 summary LSAs. Type 3 LSAs advertise any networks owned by an area to the rest of the areas in the OSPF autonomous system, as shown in Figure .
The link-state ID is set to the network number; the mask is also advertised.

By default, OSPF does not automatically summarize groups of contiguous subnets or summarize a network to its classful boundary. The network operator uses configuration commands to specify how the summarization occurs. By default, a type 3 LSA is advertised into the backbone area for every subnet defined in the originating area, which can cause significant flooding problems. Consequently, you should always consider using manual route summarization at the ABR.

Summary LSAs are flooded throughout a single area only, but are regenerated by ABRs to flood into other areas.

Note By default, summary LSAs do not contain summarized routes.

Type 4

A type 4 summary LSA is generated by an ABR only when an ASBR exists within an area. A type 4 LSA identifies the ASBR and provides a route to it. The link-state ID is set to the ASBR router ID. All traffic destined to an external autonomous system requires routing table knowledge of the ASBR that originated the external routes.

In Figure , the ASBR sends a type 1 router LSA with an external bit (e bit) that is set to identify itself as an ASBR. When the ABR, which is identified with a border bit (b bit) in the router LSA, receives the type 1 LSA, it builds a type 4 LSA and floods it to the backbone (area 0). Subsequent ABRs regenerate a type 4 LSA to flood into their areas.

Type 5

Type 5 external LSAs describe routes to networks outside the OSPF autonomous system. Type 5 LSAs are originated by the ASBR and are flooded to the entire autonomous system.

The link-state ID is the external network number. Because of the flooding scope, and depending on the number of external networks, the default lack of route summarization can be a major issue with external LSAs. Therefore, you should summarize blocks of external network numbers at the ASBR to reduce flooding problems.

Type 6

Type 6 LSAs are specialized LSAs that are used in multicast OSPF applications.

Type 7

Type 7 is an LSA type that is used in not-so-stubby areas (NSSAs). They are originated by ASBRs within NSSAs and are flooded only within the NSSA in which they originated.

Type 8

Type 8 is a specialized LSA that is used in internetworking OSPF and Border Gateway Protocol (BGP).

Types 9, 10, and 11

The opaque LSAs, types 9, 10, and 11, are designated for future upgrades to OSPF for application-specific purposes. For example, Cisco Systems uses opaque LSAs for Multiprotocol Label Switching (MPLS) with OSPF. Opaque LSAs are distributed using standard LSDB flooding mechanisms. Each type has a different flooding scope.

Notes

  • loopback interfaces advitces as /32 unless ip ospf network point-to-point command is run on the Interface. 
 

Cisco launches first apprenticeship Cisco training programme for companies


Cisco has created its first apprenticeship programme, delivered in partnership with QA Apprenticeships. The programme aims to "develop a qualified, motivated workforce of Cisco practitioners around the UK", said Cisco.

Cisco added: "The move will give new apprentices the skills to manage and optimise Cisco network systems, handing IT employers a new source of talent to deliver commercial projects and expand their business."

The programme will run at both advanced and higher levels, with the first Cisco apprenticeship programmes commencing this autumn in the south east of England, with applications taken throughout this summer.

QA Apprenticeships, which will provide the training for the new programme, and Cisco recently celebrated winning the Apprenticeship Programme of the Year award from the Learning & Performance Institute for a second year running.

The award was won for creating and growing a bespoke apprenticeship programme for Cisco itself, which has brought over 20 apprentices into the networking and telecoms kit provider to date.

Ian Foddering, chief technology officer at Cisco UK and Ireland, said: “We have been aware for some time about the increasing demand from our partners and customers for apprentices with a strong Cisco knowledge. We are naturally delighted to be able to launch this programme, delivered by QA Apprenticeships, that will develop talent as we have experienced."

The new programme will offer CCNA (Cisco Certified Network Associate) and CCNP (Cisco Certified Network Professional) qualifications to apprenticeships who take part. These qualifications can also be achieved from other training providers.

Ben Pike, director of QA Apprenticeships, said: “We have worked closely with Cisco to develop their in-house apprenticeship scheme. That they have chosen us as delivery partners for their accredited industry programme cements that partnership."

 

Monday, April 29, 2013

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.  
  3. 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.
  4.  
  5. The BGP router-id must be the same as the OSPF router-id for redistributing the routes from OSPF to BGP or vice versa.
  6.  
  7. 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.
  8.  
  9. 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.
  10.  
  11. 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.
  12.  
  13. 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.
  14.  
  15. While sending BGP updates, EBGP peers modify the next-hop value to its own IP address. But iBGP peers do not modify it.
  16.  
  17. 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.
  18.  
  19. '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.
  20.  
  21. The weights assigned with the 'set weight …’ route-map command overrides the weights assigned using the 'neighbor… weight …' command.
  22.  
  23. 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.
  24.  
  25. When BGP originates a route with the ‘network …’ command, MED is copied from the metric of the original route.
  26.  
  27. BGP MED values are not passed beyond the receiving (neighbor) AS.
  28.  
  29. 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.
  30.  
  31. 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.
  32.  
  33. 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.
  34.  
  35. 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.
  36.  
  37. 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.
  38.  
  39. 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.
  40.  
  41. 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.
  42.  
  43. 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.
  44.  
  45. 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.
  46.  
  47. 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.
  48.  
  49. 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.
  50.  
  51. 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. 
  52.  
  53. EBGP routes external to the confederation are preferred over EBGP routes to member autonomous systems, which are preferred over iBGP routes.
  54.  
  55. 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.
  56.  
  57. 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.
  58.  
  59. BGP private autonomous system numbers are from 64,512 to 65,535
  60.  
  61. 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' .
  62.  
  63. 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.
  64.  
  65. 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.
  66.  
  67. iBGP routes are not redistributed into an IGP unless you use "bgp redistribute-internal" command under BGP routing process.
  68.  
  69. '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.
  70.  
  71. 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.
  72.  
  73. Peer session template can inherit only one session template directly, but peer policy template can inherit multiple policy templates.
  74.  
  75. 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.
  76.  
  77. 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.
  78.  
  79. 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).
  80.  
  81. 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.
  82.  
  83. 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.
  84.  
  85. '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.
  86.  
  87. 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.
  88.  
  89. 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.
  90.  
  91. 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.
  92.  
  93. 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.
  94.  
  95. 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.
  96.  
  97. While redistributing OSPF into BGP, by default only OSPF intra-area and inter-area routes are redistributed into BGP.
  98.  
  99. 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.
  100.  
  101. 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.
 

Wednesday, April 24, 2013

EVC framework : Flexible Service Mapping



Configuring service instances using the EVC framework : Flexible Service Mapping.

Probably the biggest advantage of the EVC framework is the ability to support multiple services per physical port. This means that under a single physical port you can have any of the following mixed together :

- 802.1q trunk
- 802.1q tunnel
- Local connect
- Scalable EoMPLS (EoMPLS xconnect)
- Multipoint Bridging (L2 bridging)
- Multipoint Bridging (VPLS, SVI-based EoMPLS)
- L3 termination

Besides all of the above, by using the EVC framework you can combine multiple different services from different physical ports, i.e. when using multipoint bridging (aka bridge-domains), in order to put them into the same virtual circuit.


 
 
 



Local connect is a L2 point-to-point service between two service instances on the same system. The service instances can by under the same port (hair-pinning) or under different ports. In contrast with the traditional L2 bridging, this one doesn't use any MAC learning and it's solely between 2 points. Also Local Connect doesn't require any global VLAN resource.

In order to have the following two service instances connect to each other by a L2 point-to-point service, you need first to remove their difference, which is the outer tag (you can also remove both tags).

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

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 20 second-dot1q 100
  rewrite ingress tag pop 1 symmetric

! EVC-LC-10-20 is just a name for this point-to-point connectionconnect EVC-LC-10-20 Gi1/1 10 Gi1/2 20

Note : You can use the same service instance number under different physical ports.

In order to have the following two service instances be connected by Local Connect, you don't need any VLAN tag rewrite, because they both have the same vlans.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 10-20

connect EVC-LC-10-20 Gi1/1 10 Gi1/2 20


In order to have the following two service instances be connected by Local Connect, you can either translate the vlan on one of them, or remove the tags on both of them.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag translate 1-to-1 dot1q 20 symmetric

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 20

connect EVC-LC-10-20 Gi1/1 10 Gi1/2 20


Scalable EoMPLS or EoMPLS xconnect is a L2 point-to-point service between two service instances on different systems. Like Local Connect it doesn't use any MAC learning and it's solely between 2 points. It also doesn't require any global VLAN resource (this applies to scalable EoMPLS only; for SVI-based EoMPLS check VPLS below).

You can have any VLAN tag rewrite configuration under the service instances, as long as you keep in mind the following :

a) If both sides are EVC based, then you need to have common VLAN tag rewrite configurations on both sides
b) If one side is not EVC based, then depending on whether it's a physical interface or a subinterface, you'll probably need to remove one tag from the EVC side (subinterfaces remove tags by default)

Note : By default, VC type 5 is used for EoMPLS. In case VC type 4 is negotiated and used, an additional tag will be added after the VLAN tag rewrite configuration and before the data gets EoMPLS encapsulated.

7600-1
interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  xconnect 1.1.1.2 10 encapsulation mpls

7600-2
interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  xconnect 1.1.1.1 10 encapsulation mpls


Note : Have a look at Scalable EoMPLS for additional information.

Multipoint Bridging uses the concept of bridge-domains. Bridge-domain (BD) is like a traditional L2 broadcast domain where MAC-based forwarding is used for communication between participants (i'll try to write a new post with more details about bridge-domains). Bridge-domains use global VLAN resources.

In the following example, three service instances are put into the same bridge-domain by translating the tags where necessary.

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

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 20
  bridge-domain 20

interface Gi1/3
 service instance 30 ethernet
  encapsulation dot1q 30
  rewrite ingress tag translate 1-to-1 dot1q 20 symmetric
  bridge-domain 20


The bridge-domain ID represents the global VLAN used in the system. Extra care needs to taken in case of L2 trunk/tunnel ports participating in a bridge-domain :

a) L2 trunk ports remove automatically the tag on ingress and add it automatically on egress. Equivalent EVC ports need that to be done manually by using the appropriate rewrite actions.
b) L2 tunnel ports add a new tag on ingress and remove it on egress. Equivalent EVC ports do not need any similar rewrite actions, because by default bridge-domains add a new tag on top of the already existing one.

In the following example two ports (a L2 trunk port and an EVC port) are put into the same bridge-domain (Vlan 20). Tag 10 needs to be removed from the EVC port before it joins bridge-domain 20.

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

interface Gi2/1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 20
 switchport mode trunk


In the following example two ports (a L2 tunnel port and an EVC port) are put into the same bridge-domain (Vlan 20). On the EVC port, tag 20 is added on top of tag 10 in order to have the incoming frames join bridge-domain 20.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  bridge-domain 20

interface Gi2/1
 switchport access vlan 20
 switchport mode dot1q-tunnel


VPLS or SVI-based EoMPLS can be accomplished by configuring xconnect under a SVI. This SVI is the same as the one defined by the bridge-domain ID.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30

interface Vlan 30
  xconnect 1.1.1.2 10 encapsulation mpls


By adding "split-horizon" after the bridge-domain ID in both service instances, there can be no L2 communication between them.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30 split-horizon

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30 split-horizon

interface Vlan 30
  xconnect 1.1.1.2 10 encapsulation mpls


By adding an additional tag through a rewrite action in both service instances, you can differentiate them, while they are being transfered through the same VC.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20
  rewrite ingress tag push dot1q 21 symmetric
  bridge-domain 30 split-horizon

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 10-20
  rewrite ingress tag push dot1q 22 symmetric
  bridge-domain 30 split-horizon

interface Vlan 30
  xconnect 1.1.1.2 10 encapsulation mpls


SVI-based EoMPLS can be considered like a VPLS, where there is only one VC pointing to one neighbor.

Note : Have a look at SVI-based EoMPLS for additional information.

For L3 termination you have the usual two options : use subinterfaces or use bridge-domains (just like switchports) and SVIs. ES/ES+ and SIP-400 cards support termination of double-tagged traffic too.

Keep in mind the following :

a) you must remove all tags before terminating L3 traffic
b) you must use matching rules based on unique single or double tags (no vlan ranges are supported, although they might be accepted)

This is an example using a bridge-domain and the equivalent SVI:
interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 40

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 20 second-dot1q 30
  rewrite ingress tag pop 2 symmetric
  bridge-domain 40

interface Vlan 40
  ip address 1.1.1.1 255.255.255.0


This is an example using subinterfaces:

interface Gi1/1.10
 encapsulation dot1q 10
 ip address 1.1.1.1 255.255.255.0

interface Gi1/1.20
 encapsulation dot1q 20 second-dot1q 30
 ip address 1.1.1.1 255.255.255.0


Note : ES cards have a major limitation : single-tagged vlans configured under a subinterface are global significant. On the other hand, double-tagged vlans are local significant. On the ES+ and SIP-400 cards, both single-tagged and double-tagged vlans are local significant.
 

Saturday, April 20, 2013

Preparing for Citrix Certification Part 3 of 3

Courtesy - Carl Wester

In Part 2 of this series, you were given my personal observations into preparing for and taking Citrix certification exams. In the final article in this series I will give you some short random thoughts about:
  • Why should you get certified?
  • How do I study for exams (since I’ve taken so many)?
  • How are exams scored?
  • What to look for in an exam center.
  • My favorite exam centers.
  • Dealing with not passing an exam.

Why should you get certified?

Certification is one way to prove you have a basic and specific level of product knowledge. If you work, or plan to work, for a Citrix Partner, certification may be a requirement of your job. Earning CCA certifications is also one way to get a jump on others who may apply for the same position you have applied for. Having your CCA certification can help prove to a potential employer that you have worked and studied to improve your product knowledge.

Not everyone needs to be certified. I doubt that a company would ask Brian Madden if he was certified before he implemented a XenApp farm. There could come a time when your resume and experience level is so impressive that being certified may not matter. Even those with a lot of heavy real world experience still spend a lot of time in the lab keeping current and also working to stay ahead. Until you move into a company management position, there should never be a time when you are not spending time in the lab improving your current and future knowledge and skills.

How do I study for exams?

I take exam preparation very seriously. I have a serious personal flaw that does not like failure and will accept nothing less than a perfect score. If I do not make a perfect score that means there is something I didn’t know or misunderstood about the product I was tested on. It could also mean the test was wrong or there was a flaw in the product documentation! J I do not wish this curse on anyone else.
I start by looking at the Exam Prep Guide to see what kind of test will be given. Will it be what I call a:
  • fact based exam
  • decision tree based exam
  • simulation exam
If there is an online course available I will take it. When I take the online course, I look at the online resources to see what other material I may need to study and I download it. Once I have worked through all the labs in the course, I then start reading every line of all the product documentation (did I tell you I read around 600 words a minute?). While reading the product documentation, I will also build a lab setup to work with the software. I also monitor the Citrix support forums and the relevant zones on Experts Exchange. This allows me to see if I understand the product well enough to maybe answer a question or even to see if I understand what is being discussed.
Once I feel comfortable enough I schedule the exam for at least one week away. That gives me enough time to go back through the online course lab to see if I can do the labs with just the overview directions and not use the step-by-step directions. I will also continue reviewing the admin guide for the product.

The day before the exam, I will review product documentation and then stop studying after lunch. That night, I will waste some time watching TV and go to bed early. Being a morning person, I wake up very early, review the admin guide a final time and then head to the testing center. My favorite testing center just happens to have one of my favorite breakfast places just around the corner. I go eat a breakfast of scrambled eggs and ham, review my notes and go around the corner to the testing center. I sit in my car for a few minutes just to chill out.

When I enter the testing center I make a quick trip to the rest room and then go sign in. The exam proctor will take me to my assigned computer and log me in. After I enter my credentials and verify I am taking the correct exam, I sit for a minute, take a few deep breathes, stretch and then start the exam.

How are exams scored?

Citrix is the only vendor I am aware of that will tell you how they score their certification exams. The Scoring Secrets for Citrix Exams – Divulged is an article written by Citrix employee Alejandra Amador-Garcia that explains the scoring process. Also, some Exam Prep Guides will tell you how an exam is scored. For the Citrix Access Suite 4.0: Design (1Y0-614) exam, the prep guide section 9 is titled Scoring Design Decisions. The Citrix Access Suite 4.0: Build/Test (1Y0-456) Exam Prep Guide also has a section devoted to explaining the scoring and answering process.

What to look for in an exam center

A good exam center will allow you to concentrate on the exam. A bad exam center can hurt your exam experience in that you will spend most of your thought processes complaining about the testing environment.
A good exam center will have:
  • Fast computers
  • Large monitors
  • Clean keyboard
  • Clean mouse
  • Comfortable room that is neither a meat locker nor sauna
  • Good lighting
  • Clean rest room that is close by
  • QUIET
A bad exam center will be a testing nightmare. Here are some of the things I have come across in what I consider really bad exam centers:
  • Computers so slow it can take a minute or longer to move from question to question
  • Keyboards so filthy you want to get a penicillin shot after the exam
  • The mouse rollers are so coated with filth the pointer barely moves
  • Computers with the cases off
  • One place was so cold I had to wear a winter coat
  • One place had the exam room right next to the training room so I heard every word of the course being taught
  • One testing center was on the top floor and the only rest room was on the bottom floor
Once you find a really good exam center, you will not want to test anywhere else.
The exam companies used to send out e-mail surveys to find out about your testing experience. I have not seen a survey in a couple of years. If you think your exam center is a bad center let Citrix Education hear about your bad exam center experience.

My favorite exam centers

I have taken over 100 certification exams in numerous exam centers in seven states (not counting the states of confusion and paranoia that exist during the exam). I have had more worse exam center experiences than good. My top two exam centers are:

#1: DataSchenk, Inc.
611 Potomac Plaza
Suite 101
Smyrna, TN

#2: New Horizons Computer Learning Center
10200 Linn Station Road
Suite 110
Louisville, KY

DataSchenk is my #1 choice because:
  • IT IS QUIET — no road noise, no office noise, no training room noise
  • Very clean facility — even a private rest room that is clean, well supplied and roomy
  • Very friendly staff — never seen the receptionist without a smile and a helpful attitude
  • Free water and soft drinks — fridge is full of all kinds of soft drinks including my favorite ginger ale
  • Free snacks — for AFTER the exam of course
  • Free candy outside the exam room – to help control your blood sugar or nerves
  • Fast computer — no delay no matter the type of exam questions
  • Large monitor — great for viewing exhibits and other exam features
  • Comfortable exam room
  • My two favorite breakfast places are just around the corner

Dealing with failing an exam

I know of no one that has not failed at least one exam. I have failed four: one Cisco, one Microsoft and two Citrix exams. The two Citrix exams were 456 and 614 and I failed those miserably the first time. How do you deal with failing an exam after putting so much time, energy and effort into the preparation?

First realize it is just an exam. An exam failure does not mean you failed as a person or an administrator/engineer/architect. As soon as possible following the exam, write down notes to yourself about what was on your exam and what you were not prepared for or what took you completely by surprise. Review the Exam Prep Guide. Did you miss an exam objective or requirement while you were studying?

Note: revealing these notes to other people is very likely a violation of your exam contract. Don’t do it.

Use your notes with the product documentation. Is what you missed covered in the documentation?
Use your notes with your lab. What else can you do in your lab to learn about the questions you missed?

Use your exam score sheet and review your weak areas. Spend more time in the lab going over your weak areas. And then spend more time in your lab.
Remember this about failing an exam: relax, life goes on, you are not a failure.

Parting Thoughts

Certification is a rewarding trip even though at times it is frustrating and painful. I hope your journey rewards you with the titles and money you seek. I hope your quest to improve your product knowledge and skills does not stop once you obtain your certifications.
 

Wednesday, April 17, 2013

Preparing for Citrix Certification Part 2 of 3


Courtesy - Carl Webster


In Part 1 of this series, you were given the necessary resources to get you started on your Citrix certification journey. In this article, I will give you my personal observations into preparing for and taking Citrix certification exams.

Ready, Set, Go

Now that you studied for your exam, what now? You probably have several questions.
  • What is a good way to get ready to take the exam?
  • What should you do the day before the exam?
  • What should you do the day of the exam?
  • What should you do during the exam?
  • What are the exams like?

NOTE:
These are my viewpoints, so before I start answering the above questions, I have a few statements. Don’t ask me about any specific exam. Don’t ask me about any exam questions. I will not answer those questions. Don’t tell me about what you saw on an exam or any question you saw on an exam or any question type you saw on an exam. You agree to a Non Disclosure Agreement before you start your exam. Honor that agreement. I do not want to know or need to know what was on your exam and I will not tell you what was on my exam.

What is a good way to get ready to take the exam?

Spend a LOT of time in your lab, read the product documentation, study, learn to think like an exam developer and come up with your own questions and don’t use a brain dump. Know the defaults for installing a product. If installed using all the default options, what menu options are available? What menu options are not available?

Schedule the exam and then commit to a study schedule. I am a morning person so I like to schedule my exams for mornings. The type of exam and the amount of time the exam allows for will affect your scheduling. The 1Y0-456 Build/Test exam allows FOUR hours to take the exam. Most exam centers will not allow that exam to be scheduled after 1PM.

Look at the Exam Prep Guide for the exam you are taking and look at the number of questions on the exam and the amount of time allowed. If your exam has 50 questions to be answered in 70 minutes, that is roughly 1 minute and 20 seconds per question. Do you think you can answer 50 questions in 70 minutes? Or do you think you can complete the 1Y0-456 exam in less than four hours? If you are stressed out about the time and the number of questions, you may not be prepared to take the exam.

Or you could be someone who just stresses out about taking exams. Calm down, take a deep breath and just relax. It is just an exam and life will go on. Just remember, the person who makes a perfect score is just as certified as the person who makes the minimum score. Exam scores are not posted to your exam profile. Exam scores are not available to a potential employer or to your current employer.
Relax while you get ready for your exam.

What should you do the day before the exam?

The day before your exam should be a relaxing day. Go back over the Exam Prep Guide for your exam. Go back over the number of questions, the time allowed, the passing score percentage and the objectives. If you are using the exam prep questions from Citrixxperience.com, you should be able to easily answer the questions and work through any simulations.

Don’t have any caffeine after lunch. Don’t consume too much sugar or carbs after lunch. Before dinner time, go over your study sheets and study guides ONE LAST time for today. Do not study after dinner. Watch some TV, go for a walk and just relax. Go to bed early. Relax. Sleep well. You are ready to knock the exam out of the park and beat my score! J RELAX.

What to do the day of the exam?

Go over your study materials as a review.
Eat a meal without too many carbs. You do not want your blood sugar spiking and then dropping during the exam.

Leave early for the testing center. Better to be early and relaxed than running late and stressed out.
When you arrive at the testing center, go ahead and make sure you can find the correct building or office. Make sure you know where the rest rooms and water fountains are. Some testing centers will have their own private facilities. You may want to go ahead and make a quick trip to the rest room before signing in.

All you need to take into the testing center are your two forms of identification and your vehicle keys. Leave everything else locked up in your vehicle. You may need a jacket or coat as some testing centers are as cold as a meat locker. Just make sure to empty all the pockets of any jacket or coat you bring.

What should you do during the exam?

During the exam — RELAX. You will need to agree to the NDA and you will have the option to sample the various types of exam questions that may be on your exam. i.e. Multiple choice, drag-and-drop, decision tree, full-screen simulation, embedded simulation.
You are free to get up and use the rest room or get a drink during your exam but your time allowed for the exam will keep running.

Do not spend too much time on a question. If you are stuck and the exam allows it, mark the question for review and come back to it. At the end of the exam, the exam review will allow you to see which questions you did not answer and or have marked for review. Each exam is different is what you are allowed to review or change. This is usually described in Section 6 of the Exam Prep Guide. Some exams are designed in a way that going back to review or change an answer is not allowed.

If you think a question is confusing, is marketing B.S. and shouldn’t be on the exam or you disagree with the answers, then you are allowed to make comments. Citrix does review the comments but your comments will not affect your score but do affect the time allowed (i.e the clock is ticking while you are making comments).

After you end the exam, you will know in a short amount of time whether you passed and how well you did. If you were not successful this time, take the score sheet and see what exam sections you need to understand better. You may want to make some notes on what areas in the exam you did not feel sufficiently prepared for. That way you can go back to your lab and brush up on those areas before attempting the exam again.

What are the exams like?

Contrary to what you may believe, certification exams are not designed to trick you or deceive you. Exam questions are designed to determine if you meet the minimum required standards for the goals set for the exam you are taking. If you believe a question is a trick question, make a comment during the exam on that question.

The questions are not designed to trick you but you must pay attention to the wording of the questions. Some of the words to pay attention to are “should”, “could”, “must”, “require/required/requires”. Examples include:

What should the administrator do…
What could the administrator do…
What must the administrator do…
What is the administrator required to do…

In the future, I hope more exams start using live lab simulations. This is where you are given an objective and then dropped into a real live lab environment. This environment is loaded with all the software you are being tested on. This way, you can prove you know your stuff and it will be very difficult to “fake it ‘til you make it”. This will also make it extremely difficult for exams to show up on brain dump sites.

Conclusion.

An exam should not be the conclusion to your learning about a product. You should continue to use your lab to expand your product knowledge. With the many products Citrix now makes available and the products available for Tech Preview, it should take you a long time to run out of products and components to play with in your lab.

I also encourage you to actively participate in the Citrix Support Forums, Brian Madden’s forums and Experts Exchange. Helping others and trying to answer questions are excellent ways to give back to the Citrix community, increase your knowledge and get ready for your next exam.
In the final article in this series, Part 3, I will give you some Random Thoughts about:
  • Why get certified?
  • How do I study for exams (since I’ve taken so many)?
  • How are exams scored?
  • What to look for in an exam center
  • My favorite exam centers
  • Another word on dealing with not passing an exam
 

Monday, April 15, 2013

Preparing for Citrix Certification Part 1 of 3



This article series will give you insight into preparing for and taking certification exams from someone who has successfully taken over 100 of them. Specifically, this Part 1 article will cover preparing for and taking Citrix certification exams. There is no such thing as just reading a book and passing a Citrix certification exam. You need to have some practical experience with Citrix products to pass the certification exams.

There are five things you will need to help prepare for Citrix exams:
  1. Computer lab
  2. Citrix exam prep guide
  3. Citrix product documentation
  4. Study material
  5. Experience using the product

Computer Lab

A fancy computer lab is not necessary to study for most Citrix exams. A basic laptop with 2GB of RAM will suffice for most of the Administrator level exams. There are several free and commercial virtualization products that can be used:
There are many other virtualization products to select from. Building a lab environment to help you learn the products should not be hard.

Microsoft and Citrix make products available for trial use. Most Microsoft server products are available for 180-day evaluations. Using the trial version of Server 2008 is just fine for a basic lab setup. Citrix also offers trial licenses for most products after you create a MyCitrix account. Microsoft also offers the Action Pack Subscription plan to give you the use of software that is not limited to 180 days.

Bottom line: there is nothing to keep you from building a simple lab and obtaining the software you need to learn the products and prepare for the exams.

Citrix Exam Prep Guide

In order to understand what you need to know to take an exam, Citrix has available an Exam Prep Guide for every certification exam. Go to http://www.citrixtraining.com/courses/exams/index.cfm and search by Product and or Certification to find the appropriate guide. For example, search for the Product XenApp and click the link for Exam A05. Towards the bottom of the screen under More Info: you will see the A05 Exam Prep Guide. The Guide is a PDF file that contains all the information you need to know about the certification exam. In each guide you will find information on:
  • Purpose of the exam (i.e. what skills are being tested)
  • The number of questions
  • Passing score
  • Time limit
  • Preparatory recommendations for the exam
  • Resources used to develop the exam
  • Exam objectives
  • Format of questions on the exam (i.e. multiple choice, drag and drop, simulations, etc)
  • Practice questions
My recommendation is to concentrate on these three sections:
  • Preparatory recommendations for the exam
  • Resources used to develop the exam
  • Exam objectives
By thoroughly reading and understanding these three sections, you should understand what you need to work on in your lab. Using the A05 Exam Prep Guide as an example, let’s look at these three sections.

Section 3 — Preparatory Recommendations for the Exam

Look at subsection 3.2, Recommended Knowledge and Skills.
Candidates should have the following knowledge and skills prior to taking this exam:
  • Basic configuration of Microsoft Windows Server 2003 and 2008
  • Management of users’ permissions and rights in Microsoft Active Directory 2003
  • Intermediate administration skills, including:
o An understanding of protocols (TCP)
o An understanding of firewall concepts
o An understanding of email administration and account creation
o An understanding of Terminal Services policies and profiles
o The ability to create shares and give access to shared folders/files
  • Knowledge of basic database concepts
This section gives you the minimum skills that Citrix believes you should have before taking this exam.

Section 5.3 — Resources Used to Develop the Exam

This section will give you a list of materials that Citrix used to come up with exam questions. I recommend reading every resource listed.

Section 5.4 — Exam Objectives

This section gives you an idea of what areas the exam developers will test you on during the exam. Using the resources from Section 5.3, look at the Objectives column and try to come up with your own exam questions as you are reading.

Citrix Product Documentation

Along with the resources list in Section 5.3 of the Exam Prep Guide, you should read all the related product documentation available in the various PDF files or now on eDocs. When taking an exam for XenApp, you should understand the various components that are included with XenApp. For example:
  • Publishing applications
  • Citrix Policies
  • Load Balancing
  • Installation Manager
  • Application Streaming
  • Client software
  • Edgesight
  • Licensing
  • Citrix Secure Gateway
  • Web Interface
  • Zones
  • Data Collectors
  • Data Store
  • Database types that can be used for the Data Store
All the various components of each Citrix product can be fair game for inclusion on a certification exam. It is your job as an Administrator/Engineer/Architect to know how the various components are used and how they can fit together in an environment. You should be familiar with the documentation for each product and component.

Study Material

There are four main types of study material available to you:
Citrix offers both Self-paced Online (SPO) and Instructor-led Training (ILT). I have taken both and prefer ILT if the instructor has real-world experience to pass on in the classroom. Not everyone can afford ILT from a cost or time perspective, so the same courseware is used for the SPO training. The Citrix Education team puts a lot of pride and effort into the official courseware so you will be well served whichever training method you use. If you take an official Citrix course, you can now purchase additional lab time for the course. Citrix Practice Labs are ideal for you Citrix certification preparation.

Brian Madden has available an e-Learning DVD of his 5-day Citrix Presentation Server advanced class. The cost has been reduced to $1,995 and is excellent material.
Shawn Bass does a 5-day class. While I have not been to the class, Shawn Bass is a premier Citrix Expert and a Citrix Technology Professional who is not afraid to tell it like it really is.

The best book ever on any version of Citrix MetaFrame/Presentation Server/XenApp is Brian Madden’s Citrix MetaFrame XP, Advanced Technical Design Guide . While the book may be outdated, the information on the internal workings of what is now XenApp is beyond compare. I am sad to say but most books that cover Citrix products and certification are not worth spending your money on. It would be better to spend your money printing out the product documentation and having it bound at your favorite office supply store.

Citrixxperience.com is the only legitimate web site I know of that offers legal study guides and exam preparation questions and answers. The team at Citrixxperience.com puts a lot of effort into producing materials that can help you on the exam prep trail. Every other web site is an illegal brain dump and using that material can get you in trouble with Citrix and you run the risk of losing your certifications.

Experience Using the Product

Once you have built your lab, know what will be covered on an exam, have the product documentation available and hopefully taken some product training, you are now ready to get the all important hands-on experience.

The best way to learn any product is to use it and try to use as many features as possible. In your lab, learn to install the product, mess it up, fix it, delete files, recover from your accidents and stretch your knowledge of the product. Go to the Citrix support forums, Brian Madden’s forums and or Experts Exchange and try to answer other people’s questions. Even if you can’t answer a question, can you try to recreate the problem and learn something from the issue?

If you use the products from Citrixxperience.com, prove the answers to the questions. Never take an answer as correct. Prove the answer either from the product documentation or from your lab.

Conclusion.

You now have the resources necessary to get started on your Citrix certification journey. In Part 2 of this series, I will give you some personal observations for your certification journey.

 

Friday, April 12, 2013

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.
 

Wednesday, April 10, 2013

OpenFlow and Software Defined Networking: Is It Routing or Switching ?

Courtesy - Ethereal mind


The answer is: NEITHER.

Short Version

Openflow works by updating entries to the FORWARDING table in your router or switch. Therefore it is not a routing or switching protocol at all.

Longer Answer

The architecture of networking equipment is often described as having three planes of operation – management, control and data planes and often represented by the following diagram:

Mgmt control forwarding planes 1
The Management Plane handles functions such device management, firmware updates, SNMP and external configuration via the CLI. The Data Plane refers to packet and frame forwarding through the device. The Control Plane is routing protocols such as BGP & OSPF and switching protocols such as STP & TRILL..

The control plane will use the routing table to build the forwarding table used by data plane. The forwarding table is delivered to the data plane by the management plane as part of the device operating system. Thus when an Ethernet frame arrives on the switch interface, the data plane then forwards it to output port.

OpenFlow is a new method of control for flows in the network. To date, networking has always focussed on managing frames and packets with routing protocols, but applications don’t use single packets to deliver services. Rather, they exchange data between server and client, they create a stream of packets from a source to destination that is commonly known as flow. As a metaphor, this flow is to packets as apples are to apple pie. A pie is what you are eating, not apples.

OpenFlow defines a standard for sending flow rules to network devices so that the Control Plane can add them to the forwarding table for the Data Plane. These flow rules contains fields for elements such as source & destination MAC, Source & destination IP, source and destination TCP, VLAN, QoS and MPLS tags and more. The flow rules are then added to the existing forwarding table in the network device.

The forwarding table is what all routers and switches use to dispatch frame and packets to their egress ports.

OpenFlow value is realised in the Controller, and the most interesting changes are because the Controller will get new capabilities and truly granular control of the traffic flows.

Therefore, OpenFlow is neither routing or switching, it’s about forwarding.

Of course, the next question is “How should I forward frames and packets ?” but that’s another day.

Monday, April 8, 2013

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.