Network Enhancers - "Delivering Beyond Boundaries" Headline Animator

Showing posts with label CCIE. Show all posts
Showing posts with label CCIE. Show all posts

Saturday, November 1, 2014

Certifications introduced for Cisco Mobility Specialists


Cisco has introduced new Service Provider Mobility Specialist certifications and updates to its Cisco Certified Internetwork Engineer (CCIE) Service Provider written and lab exams.

The new Cisco mobility certifications are the following:


  • Cisco Service Provider Mobility UMTS to LTE Specialist certification: This certification endorses a service provider network engineer has the knowledge and skills needed to understand components, technologies and architectures found in Universal Mobile Telecommunications System (UMTS) and Long-Term Evolution (LTE) packet core networks, as well as migration from UMTS to LTE evolved packet system.
  • Cisco Service Provider Mobility CDMA to LTE Specialist certification: This certification authenticates a service provider engineer network's knowledge and skills for understanding components, technologies and architectures found in Code Division Multiple Access (CDMA) and LTE packet core networks, as well as migration from CDMA to LTE evolved packet system.


Cisco also announced that key attributes from the CCNA-CCNP-CCIE Service Provider certifications will be integrated into the CCNA-CCNP-CCIE Service Provider (Network Engineer) certifications.

CCNA-CCNP-CCIE Service Provider Operations certifications will officially retire on Jan. 31, 2015, Cisco said.

As for the exam updates, Cisco said the CCIE Service Provider v4.0 exams will be available May 22, 2015. The exams will emphasize conceptual design technologies, implementation and troubleshooting, and focus less on specific hardware platform knowledge.

The format for the lab exam is now composed of three modules -- Troubleshoot, Diagnostic and Configuration -- and will be delivered using a 100% virtual or software-based platform to better simulate a Service Provider backbone environment.

The written exam number will now be 400-201 in accordance to the new prefix exam numbering structure.

Monday, May 27, 2013

Differences between Rapid STP (802.1w) and the legacy STP(802.1d)


The following table outlines the main differences between Rapid STP (802.1w) and the legacy STP(802.1d):

STP (802.1d)
Rapid STP (802.1w)
In stable topology only the root sends BPDU and relayed by others.In stable topology all
bridges generate BPDU every Hello (2 sec) : used as “keepalives” mechanism.
Port states
DisabledBlockingListeningLearningForwardingDiscarding (replaces disabled, blocking and listening)
Learning
Forwarding
To avoid flapping, it takes 3 seconds for a port to migrate from one protocol to another (STP / RSTP) in a mixed segment.
Port roles
Root (Forwarding)
Designated
(Forwarding)
Non-Designated
(Blocking)
Root (Forwarding)
Designated
(Forwarding)
Alternate
(Discarding)Backup (Discarding)
Additional configuration to make an end node port a port fast (in case a BPDU is received).- An edge port (end node port) is an integrated Link type which depends on the duplex : Point-to-point for full duplex & shared for half duplex).
Topology changes and convergence
Use timers for convergence (advertised by the root):
Hello
(2 sec)
Max Age
(20 sec = 10 missed hellos)
Forward delay timer (15 sec)
- Introduce proposal and agreement process for synchronization (< 1 sec).- Hello, Max Age and Forward delay timer used only for backward compatibility with standard STP
Only RSTP port receiving STP (802.1d) messages will behaves as standard STP.
Slow transition (50sec):
Blocking (20s) =>Listening (15s) =>Learning (15s) =>Forwarding
Faster transition on point-to-point and edge ports only:Less states – No learning state, doesn’t wait to be informed by others, instead, actively looks for possible failure by RLQ (Request Link Query) a feedback mechanism.
Use only 2 bits from the flag octet:Bit 7 : Topology Change Acknowledgment.Bit 0 : Topology ChangeUse other 6 bits of the flag octet (BPDU type 2/version 2):
Bit 1 : ProposalBit 2, 3 : Port roleBit 4 : LearningBit 5 : ForwardingBit 6 : AgreementBit 0, 7 : TCA & TCN for backward compatibility
The bridge that discover a change in the network inform the root, that in turns informs all others by sending BPDU with TCA bit set and instruct them to clear their DB entries after “short timer” (~Forward delay) expire.TC is flooded through the network, every bridge generate TC (Topology change) and inform its neighbors when it is aware of a topology change and immediately delete old DB entries.
If a non-root bridge doesn’t receive Hello for 10*Hello (advertised from the root), start claiming the root role by generating its own Hello.Wait for 3*Hello on a root port (advertised from the root) before deciding to act.
Wait until TC reach the root + short timer (~Forward delay) expires, then flash all root DB entriesDelete immediately local DB except MAC of the port receiving the topology changes (proposal)

 

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. 
 

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.
 

Thursday, March 28, 2013

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…

image
 
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..
 
image
 
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 CostNew IEEE port Cost
10 Mbps100100
100 Mbps1019
1000 Mbps14
10000 Mbps12

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.
 

Sunday, December 23, 2012

This story is how the Cisco CCIE program was born

Courtesy - Stuart Biggs


I'm Stuart Biggs, a Tech Lead for Cisco voice, video and software development. On July 19, 1993 I became the first human on the planet to become a Cisco Certified Internetwork Expert by being awarded CCIE #1025 Routing and Switching.


Once upon a time... that's how a lot of stories start out - right? Well, this story is how the CCIE program was born:   On or about August of 1992, I went to Ford Motor Company in Dearborn, Michigan to train them on the AGS, AGS+ and MGS devices as well as IP and X.25. They were rolling out X.25 in a major way. I believe it was called the 'Compass' project. In any case, they wanted a bit more 'hands on' with the hardware as well as a better understanding of IP and X.25. So I flew to Dearborn. We had a week long session where I would draw a network architecture on a whiteboard, break a few cables (before they came in), mess with jumpers on some or all of the AGS+ boards - then give those folks all day to get things going so it matched the diagram on the whiteboard.  They apparently loved it - and I guess word filtered to upper management that they really liked this experience.


Previously, I had been involved in a 'high end' course at 3Com called '3-Wizard'. It was a good course. It dealt with protocol level details that basically related to their '3+Share' file/printer sharing software - somewhat like Novell did in those days. It was based on the Xerox set of protocols - not IP. The problem with that course was that everything they asked on the written could be gleaned from the course materials - and there was no lab. So in my opinion, it was a bit 'lightweight' in terms of content.
  So after my trip to Ford - probably around October of 1992, we put together a team with the sole goal of creating a 'base' of expertise on Cisco products who generally could maintain their own networks - or at least help us maintain them. Back in those days, we may have had up to 100 support engineers - but probably more like 60-80 or so. This was before any of the Cisco buildings along Tasman Drive were built - and even before the light-rail along that same road.  One of the goals of this team was to create a course that would focus on expertise on Cisco products in a real live environment. We wanted to fill in the gaps that the 3Com course left out. The written exam was an afterthought - just to set a bar for admission to the lab exam. Before I forget to mention this fact, the original name of the program was going to be 'Cisco Top Gun' - but as that famous Tom Cruise movie with the same name had recently come out, we figured there may be some legal issues in using that name - so we chose 'Cisco Certified Internet Expert'

 We created a lab - it was a bit adhoc - but matched the technology of the early 90's - FDDI, Ethernet, maybe a bit of X.25 as well as IBM SNA and 1 or 2 routing protocols, oh and I can't forget - Token ring. Those were the ingredients of the day.  So we created a written exam and used that as the 'filter' to folks going to the lab. The first person outside of Cisco to take the written was a guy named Terry Slattery. He's a very nice guy who till this day still holds his CCIE certification (#1026). I was the first lab proctor and messed with the cables, jumpers and all manner of things in order to break the lab setup for Terry. Back in those days, it was pretty easy to mess with a cable or fiddle with jumpers on the various boards or interface cards. So I drew a network on a whiteboard - much like the earlier days with Ford - as to how the network should work and walked out of the room. Terry quite handily sorted things out thus becoming the 2nd CCIE in the world - 1st outside of Cisco. I am amazed as to how well this program has grown. Next year - 2013 will be the 20th year of this program - and people still take notice when someone says they're a CCIE!
  Oh, and what is really amazing is that by some random chance, my employee ID # is the same as my CCIE # - 1025. Totally unplanned by the way. We decided to start CCIE numbers at 1024 (2 to the power of 10) and awarded that to the original lab - so I got 1025.  Team members:I did not do this myself. There were loads of other members that helped out. Some are still at Cisco, some are not - but here are the ones I can remember: John Bashinski, Joe Pinto, Brad Wright, Scott Edwards, Agnes Moran, Matt Burns and Lembit Marder. And others I apologize to for not mentioning...
 

Thursday, November 29, 2012

Cisco announces new job-role focused data center certifications

 
Today, Cisco is announcing a new comprehensive, job-role-focused training and certification program for its datacenter architecture. It includes a comprehensive Career Certification portfolio consisting of the Cisco CCNA Data Center, CCNP DataCenter and CCIE Data Center, as well as a robust product training portfolio.
 
"The key message here is that our career certifications now fully embrace the unified datacenter architecture -- unified computing, unified fabric and unified management," said Antonella Corno, product manager for Data Center virtualization and cloud product portfolio at Cisco. "These announcements focus on the first two unified computing and unified fabric. Unified management is cloud-focused and isn't as mature as the others, and so is not ready to receive a full career certification yet."
 
Corno said that as technology has been evolving to more intelligence in the networks, the industry has discovered that a knowledge gap is growing.
 
"Those tech trends were responding to specific business challenges, and IT organizations had to rethink the way they leverage the infrastructure, which was leading the industry into new roles and skillsets, and we had to address the gaps that were forming in training," she said.
 
"Moving to more complex infrastructures needs better trained people to lower the cost of operations, increase the functional excellence of staff and ensure the network evolves with business," Corno added.
 
The new specialist certifications cover every data center product. Joining CCIE Data Center, which was announced in February 2012, are CCNA Data Center and CCNP Data Center. All see two key pillars of the Unified Cisco Data Center architecture -- Cisco Unified Computing and Cisco Unified Fabric -- addressed across the job roles of design, implementation and troubleshooting.
 
CCNA Data Center lays the foundation for basic level job roles such as Data Center Networking Administrators that require competence in areas including network and server virtualization and storage and IP networking convergence. Good for three years, the certification requires two exams, one on routing and switching (DCICN), the other on data center technologies (DCICT).
 
The CCNP Data Center certification is a more advanced certification, aligned specifically to the job role of Data Center Network Designers and professional-level Data Center networking practitioners. It consists of six exams, in Troubleshooting, Implementation and Design, for both Unified Computing Support and Unified Fabric Support. The candidate needs to complete four of them, depending on their specialization.
 
The certification validates an individual's capabilities, including troubleshooting a virtualized computing environment based on the Cisco Unified Computing System platform focusing on storage and network connectivity, installation, memory, adapter connectivity and booting issues, drivers, BIOS and deploying a virtualized environment.
 
"The CCNP prerequisites are the CCNA and 3-5 years of experience," Corno said.
 
While the CCIE exam was announced earlier this year, Cisco is announcing that its written exam is now available, and the lab exam will be available December 10, 2012.
 
Cisco also announced an expanded product training portfolio for the Cisco Nexus 1000V, 2000/5000, 7000, the Cisco MDS 9000 series and the and Cisco Unified Computing System (Cisco UCS) B and C-Series.
 
CCNA Data Center and CCNP Data Center exams are now available through Pearson VUE. Training courses are available through Cisco Authorized Learning Partners.
 

Saturday, September 22, 2012

Free Cisco Labs for Certification

 
Looking for some practical experience with Cisco routers and switches for little to no cost? There's no shortage of free Cisco labs on the Web.
 
These sites are designed to assist network operators and Cisco certification students with common problems or challenges that crop up in configuring Cisco networks. In some instances, they may serve as teasers to get students to pay for more elaborate and comprehensive testing services.
 
Here's a sample of six free Cisco labs available either online or in person:
 
PacketLife Community Lab - Currently offline until November, the PacketLife community Lab provides free access to "modern" Cisco networking equipment for training purposes. Lab equipment and other costs are provided or sponsored by the site's owner, commercial sponsors, and voluntary contributions by community members.
 
Free Cisco Catalyst Switch Lab - This non-commercial effort provides free 24x7 access to Cisco Catalyst switches to learn networking, Cisco IOS, and prepare for certification exams. It requires no reservation or registration. Users telnet in to get 80-90 minutes per session on each console line, a one hour waiting period, and a two hour reset period. Users have many logins and sessions per day on each console, and can login to as many devices as they want that are available. Each line is timed separately.
 
Free Cisco Lab -- Free Cisco Lab is dedicated to providing educational help for students pursuing Cisco certifications. It provides exam preps, practice exams and free lab scenarios for routing, switching, security, wireless, and VOIP. It is operated by Barry Burdette, a 15-year network industry veteran who has designed, installed and maintained network infrastructure during his career.
 
Free Cisco Lab Simulators - The Ciscoconsole site has a link to free Cisco lab simulators available for download. One is the GNS3 simulator, an open source program that allows users to design complex network topologies. The program enables emulation of many Cisco IOS router platforms, IPS, PIX and ASA firewalls, and Juniper's Junos. It also simulates simple Ethernet, ATM and frame relay switches, and enables connection of the simulated network to production networks. GNS3 also performs packet capture using Wireshark. It can be run on multiple operating systems, including Windows, Linux, and MacOS X.
 
Dynamips - Dynamips is an emulator program for Cisco routers. It emulates Cisco router hardware by booting a Cisco IOS image into the emulator. Dynamips emulates Cisco 1700, 2600, 3600, 3700, and 7200 series routers for testing and experimenting with IOS features, and checking configuration before production deployment. GNS3 can be a graphical front-end for Dynamips; another front-end is Dynagen. Dynamips runs on Linux, Mac OS X or Windows.
 
Free CCNA Workbook - This site provides a free lab to those that prefer to use real equipment over emulated gear from Dynamips/Dynagen/GNS3. The lab consists of Cisco 3725, 3550 and 2950 hardware running 12.4 images of IOS. Each lab session is limited to total of three consecutive hours, which equates to eight sessions per day. Users are only permitted to schedule one session at any given time.
 
 

Tuesday, July 17, 2012

Cisco CCIE Security Gets Freshened Up

New (v4.0) CCIE Security exams will go live starting November 19th. Both the written and lab exams will be updated. Objectives for the v4.0 written exam and lab exam are available on Cisco's website. If you're planning to take the v3.0 lab exam and haven't already registered, you may be out of luck. Per discussion on Cisco's CCIE Security forum, there appears to be a shortage of lab exam seats available as people rush to get take the v3.0 version before the switchover.

Wednesday, December 14, 2011

CCDE Written & Practical Exam Revised

Practical Exam v2.0 Update

The last day to test using the CCDE Practical Exam v1.0 is October 21, 2011.

Candidates who are intending to take practical exams after October 22, 2011 should prepare using the CCDE Practical Exam Topics v2.0. The CCDE Practical Exam v2.0 is scheduled for its first administration at the end of March 2012.

**********************************************************

CCDE Written Exam Topics v2.0

The Cisco CCDE written exam topic areas listed are general guidelines for the type of content that is likely to appear on the exam. Please note, however, that other relevant or related topic areas may also appear on the CCDE written exam.

Exam Sections and Sub-task Objectives

1.00
Layer 2 control plane
1.01
Describe fast convergence techniques and mechanisms
1.01.1
Down detection
1.01.2
Interface dampening
1.02
Describe loop detection and mitigation protocols
1.02.1
Spanning tree types
1.02.2
Spanning tree tuning techniques
1.03
Describe mechanisms that are available for creating loop-free topologies
1.03.1
REP
1.03.2
Multipath
1.03.3
Switch clustering
1.03.4
Flex links
1.03.5
Loop detection and mitigation
1.04
Describe the impact of transport mechanisms and their interaction with routing protocols over different types of links
1.05
Describe multicast routing concepts
1.06
Describe the impact of fault isolation and resiliency on network design
1.06.1
Fault isolation
1.06.2
Fate sharing
1.06.3
Redundancy
1.06.4
Virtualization
1.06.5
Segmentation
2.00
Layer 3 control plane
2.01
Describe route aggregation concepts and techniques
2.01.1
Purpose of route aggregation
2.01.2
When to leak routes/avoid suboptimal routing
2.01.3
Determining aggregation location and techniques
2.02
Describe the theory and application of network topology layering
2.02.1
Layers and their purposes in various environments
2.03
Describe the theory and application of network topology abstraction
2.03.1
Purpose of link state topology summarization
2.03.2
Use of link state topology summarization
2.04
Describe the impact of fault isolation and resiliency on network design or network reliability
2.04.1
Fault isolation
2.04.2
Fate sharing
2.04.3
Redundancy
2.05
Describe metric-based traffic flow and modification
2.05.1
Metrics to modify traffic flow
2.05.2
Third-party next hop
2.06
Describe fast convergence techniques and mechanisms
2.06.1
Protocol timers
2.06.2
Loop-free alternates
2.07
Describe factors affecting convergence
2.07.1
Recursion
2.07.2
Microloops
2.07.3
Transport
2.08
Describe unicast routing protocol operation (OSPF, EIGRP, IS-IS, BGP, and RIP) in relation to network design
2.08.1
Neighbor relationships
2.08.2
Loop-free paths
2.08.3
Flooding domains and stubs
2.08.4
iBGP scalability
2.09
Analyze operational costs and complexity
2.09.1
Routing policy
2.09.2
Redistribution methods
2.10
Describe the interaction between routing protocols and topologies
2.11
Describe generic routing and addressing concepts
2.11.1
Policy-based routing
2.11.2
NAT
2.11.3
Subnetting
2.11.4
RIB-FIB relationships
2.12
Describe multicast routing concepts
2.12.1
General multicast concepts
2.12.2
Source specific
2.12.3
MSDP/anycast
2.12.4
PIM
2.12.5
mVPN
2.13
Describe IPv6 concepts and operation
2.13.1
General IPv6 concepts
2.13.2
IPv6 security
2.13.3
IPv6 transition techniques
3.00
Network virtualization
3.01
Describe Layer 2 and Layer 3 tunneling technologies
3.01.1
Tunneling for security
3.01.2
Tunneling for network extension
3.01.3
Tunneling for resiliency
3.01.4
Tunneling for protocol integration
3.01.5
Tunneling for traffic optimization
3.02
Analyze the implementation of tunneling
3.02.1
Tunneling technology selection
3.02.2
Tunneling endpoint selection
3.02.3
Tunneling parameter optimization of end-user applications
3.02.4
Effects of tunneling on routing
3.02.5
Routing protocol selection and tuning for tunnels
4.00
Design considerations
4.01
Analyze various Quality of Service (QoS) performance metrics
4.01.1
Application requirements
4.01.2
Performance metrics
4.02
Describe types of QoS techniques
4.02.1
Classification and marking
4.02.2
Shaping
4.02.3
Policing
4.02.4
Queuing
4.03
Identify QoS strategies based on customer requirements
4.03.1
DiffServ
4.03.2
IntServ
4.04
Identify network management requirements
4.05
Identify network application reporting requirements
4.06
Describe technologies, tools, and protocols used for network management
4.07
Describe the reference models and processes used in network management, such as FCAPS, ITIL, and TOGAF
4.08
Describe best practices for protecting network infrastructure
4.08.1
Secure administrative access
4.08.2
Control plane protection
4.09
Describe best practices for protecting network services
4.09.1
Deep packet inspection
4.09.2
Data plane protection
4.10
Describe tools and technologies for identity management
4.11
Describe tools and technologies for 802.11 wireless deployment
4.12
Describe tools and technologies for optical deployment
4.13
Describe tools and technologies for SAN fabric deployment
- end-


************************************************

Expansion of the CCDE Practical Exam v2.0 Exam Topics



1.00 Analyze design requirements

1.01 Analyze business requirements, conflicts, and constraints

1.01.1 Op-Ex and Cap-Ex
1.01.2 Project goals
1.01.3 Lifecycle and return on investment (ROI)
1.01.4 Business environment
1.01.5 Compliance and policy

1.02 Analyze technical requirements, conflicts, and constraints

1.02.1 Application requirements
1.02.2 Compliance and policy

1.03 Analyze physical requirements

1.03.1 Topology implications
1.03.2 Operational requirements
1.03.3 Analyze business and technical risks

1.04 Analyze existing network

1.04.1 Network documentation
1.04.2 Network infrastructure and its impact on network design

2.00 Develop network designs

2.01 Identify the technology to resolve a specific design problem

2.01.1 Functional specifications
2.01.2 Network designs
2.01.3 Operational considerations

2.02 Analyze the impact on the existing network and services

2.02.1 Functional specifications
2.02.2 Network designs
2.02.3 Operational considerations

2.03 Incorporate best practices within the network design

2.03.1 Avoidance of over-engineering
2.03.2 Consistent and modularized solution sets throughout the network
2.03.3 Industry best practices

2.04 Incorporate business requirements within the network design

2.04.1 Op-Ex and Cap-Ex
2.04.2 Lifecycle and return on investment (ROI)
2.04.3 Compliance and policy

3.00 Implement network design

3.01 Analyze implementation options

3.01.1 Impact on design
3.01.2 Impact on performance, availability, and network management
3.01.3 Impact on the business
3.01.4 Risk and consequence for a given implementation plan

3.02 Design an implementation plan

3.02.1 Interdependencies between services, failure domains, and other architectural elements
3.02.2 Implementation timeline and steps
3.02.3 Contingency plans for network restoration

4.00 Validate and optimize network design

4.01 Analyze design choices based on specifications

4.01.1 Impact of implementing changes to the original design
4.01.2 Impact of different design solutions created by new drivers

4.02 Validate design

4.02.1 Test strategy
4.02.2 Performance metrics and baselines

4.03 Optimize design

4.03.1 KPI
4.03.2 Baselines

My Blog List

Networking Domain Jobs