...It's been a while since my last post during which I have mostly been actually doing my TSHOOT studies rather than writing about them.
Over the next articles I'm going to cover off area's I'd like an on-line record of. You might think something of them are not necessary or indeed rudimentary, however I like to document things so that I have them many months/years later when I might suddenly need to use which ever technology I blogged about so long ago.
I'm going to start with my thoughts on how I will approach the TSHOOT exam. I'll then move on to specific topics and also look at things that can actually be avoided in any depth (and there are some topics).
Onwards and Upwards...
Tuesday, June 22, 2010
Friday, May 21, 2010
CCNP-ENTERPRISE - EIGRP terms
Advertised Distance = Metric reported FROM a neighbor, alos known as 'Reported Distance'
Feasible Distance = The metric of the best path
Successor = Best/Primary path assed in to the routing table
Feasible Successor = Secondary/backup path retained in the topology table, must meet the 'Feasibility Condition'
Feasibility Condition = To be considered a Feasible Successor, the Advertised Distance MUST be lower than the Feasible Distance (full path) to be considered a Feasible Successor
- If the Advertised Distance is larger than the Feasible Distance then by definition the path must longer and therefore not as good.
- The Feasible Successor means that a new path can be selected with out recalculation therefore the protocol is fast
Feasible Distance = The metric of the best path
Successor = Best/Primary path assed in to the routing table
Feasible Successor = Secondary/backup path retained in the topology table, must meet the 'Feasibility Condition'
Feasibility Condition = To be considered a Feasible Successor, the Advertised Distance MUST be lower than the Feasible Distance (full path) to be considered a Feasible Successor
- If the Advertised Distance is larger than the Feasible Distance then by definition the path must longer and therefore not as good.
- The Feasible Successor means that a new path can be selected with out recalculation therefore the protocol is fast
CCNP - ENTERPRISE - EIGRP configuration review
Configure EIGRP:
R1(config)#router eigrp 1
R1(config-router)#no auto-summary
R1(config-router)#network 172.16.30.0 0.0.0.255
Where 1 = The EIGRP AS number which must match with adjacency neighbors
no auto-summary = prevents route summarisation and advertises subnets
Network = states which network to advertise AND which interface to advertise it out of
Verify EIGRP:
#sh ip eigrp neighbors
-displays status of neighbor relationships
#sh ip eigrp topology
- displays the topology of the eigrp AS
Where - P=Passive, network is available and installed in the routing table
A = Active, network is currently unavailable and EIGRP is working to source a new route
U = Update, network is being updated
Q = Query, applied if an outstanding packet query exists for the network i.e. waiting for an ACK
R = Reply, router is generating a reply for this network or waiting on an ACK to a reply packet
SIA = Stuck-In-Active, signifies EIGRP convergence issue.
*SIA status must be reset when one or more queries to a neighbor do not return before the Active timer expires (usually 3 minutes)
R1(config)#router eigrp 1
R1(config-router)#no auto-summary
R1(config-router)#network 172.16.30.0 0.0.0.255
Where 1 = The EIGRP AS number which must match with adjacency neighbors
no auto-summary = prevents route summarisation and advertises subnets
Network = states which network to advertise AND which interface to advertise it out of
Verify EIGRP:
#sh ip eigrp neighbors
-displays status of neighbor relationships
#sh ip eigrp topology
- displays the topology of the eigrp AS
Where - P=Passive, network is available and installed in the routing table
A = Active, network is currently unavailable and EIGRP is working to source a new route
U = Update, network is being updated
Q = Query, applied if an outstanding packet query exists for the network i.e. waiting for an ACK
R = Reply, router is generating a reply for this network or waiting on an ACK to a reply packet
SIA = Stuck-In-Active, signifies EIGRP convergence issue.
*SIA status must be reset when one or more queries to a neighbor do not return before the Active timer expires (usually 3 minutes)
Wednesday, April 14, 2010
CCNP - SWITCH - I passed!
I passed the CCNP SWITCH exam on Monday morning at the second attempt :o)
With much relief I'm now having a couple of weeks off the study to catch up on jobs about the house before I crack on with TSHOOT and get my CCNP in bag.
So far as the exam was concerned I felt that it was challenging but not impossible. I believe people regard this as the hardest of the 3 exams and on measure I would say that it has been the toughest Cisco exam I've sat so far.
Without breaking the NDA, I'd say the exam tests a lot of the detail in a narrow spectrum of topics. The same areas kept cropping up in the multiple choice, multiple answer questions and also the labs/simlet questions.
For any one attending a Cisco Networking Academy, you can ignore multicast completely. If you've got the Cisco Press books you'll see that in the Foundation Learning Guide, multicast is present (chpt 7 I think) BUT in David Hucaby's Official Certification Guide it is not. I think Hucaby's book is more recent so this explains the difference. Also check the exam topics on the Cisco Learning Network and you'll note that multicast is not listed in the tested subjects either.
Other than that little bit of advice I'd recommend you watch your time very carefully. I got to question 49 of 50 and was presented with a lab! I was lucky to have sufficient time remaining and was able to calmly complete it working on the gamble that I wouldn't get a 5th lab ( yes I did get 4 labs) at question 50. I might have felt differently had I only had a few minutes remaining for the last 2 questions. So be warned.
Onwards and upwards.
With much relief I'm now having a couple of weeks off the study to catch up on jobs about the house before I crack on with TSHOOT and get my CCNP in bag.
So far as the exam was concerned I felt that it was challenging but not impossible. I believe people regard this as the hardest of the 3 exams and on measure I would say that it has been the toughest Cisco exam I've sat so far.
Without breaking the NDA, I'd say the exam tests a lot of the detail in a narrow spectrum of topics. The same areas kept cropping up in the multiple choice, multiple answer questions and also the labs/simlet questions.
For any one attending a Cisco Networking Academy, you can ignore multicast completely. If you've got the Cisco Press books you'll see that in the Foundation Learning Guide, multicast is present (chpt 7 I think) BUT in David Hucaby's Official Certification Guide it is not. I think Hucaby's book is more recent so this explains the difference. Also check the exam topics on the Cisco Learning Network and you'll note that multicast is not listed in the tested subjects either.
Other than that little bit of advice I'd recommend you watch your time very carefully. I got to question 49 of 50 and was presented with a lab! I was lucky to have sufficient time remaining and was able to calmly complete it working on the gamble that I wouldn't get a 5th lab ( yes I did get 4 labs) at question 50. I might have felt differently had I only had a few minutes remaining for the last 2 questions. So be warned.
Onwards and upwards.
Monday, March 29, 2010
CCNP - SWITCH - Planning notes
My list of Planning notes in one place:
Create a Plan to Support Video in the Campus - Here
Create a Plan to Support Voice in the Campus - Here
Create a Plan to Support Wireless in the Campus - Here
Create an Implementation Plan for Inter-VLAN routing - Here
Create a VLAN based Implementation Plan - Here
VLAN best practices notes - Here
Create a Plan to Support Video in the Campus - Here
Create a Plan to Support Voice in the Campus - Here
Create a Plan to Support Wireless in the Campus - Here
Create an Implementation Plan for Inter-VLAN routing - Here
Create a VLAN based Implementation Plan - Here
VLAN best practices notes - Here
CCNP - SWITCH - Create a Plan to Support Video in the Campus
Video applications sit at layer 7 of the OSI model. They can demand high bandwidth due to the requirement to send frames as well as audio.
Real time video applications (such as Telepresence) require minimal delay and should be prioritised in the QoS configuration.
One-way videos (such as You-Tube) are not as sensitive to delay and jitter. They can be buffered by the client then replayed to produce a high quality output.
Video traffic is generally 'bursty', groups of images sent together, whilst a pause may result in few packets being sent together.
As a result traffic flow need to be managed and planned for. Consider the following requirements for Video then plan your QoS deployment across the switch infrastructure accordingly.
Video requires High bandwidth, less than 150ms delay, low jitter, <1% packet loss, high availability, potential for PoE (such as Video Conference equipment).
Real time video applications (such as Telepresence) require minimal delay and should be prioritised in the QoS configuration.
One-way videos (such as You-Tube) are not as sensitive to delay and jitter. They can be buffered by the client then replayed to produce a high quality output.
Video traffic is generally 'bursty', groups of images sent together, whilst a pause may result in few packets being sent together.
As a result traffic flow need to be managed and planned for. Consider the following requirements for Video then plan your QoS deployment across the switch infrastructure accordingly.
Video requires High bandwidth, less than 150ms delay, low jitter, <1% packet loss, high availability, potential for PoE (such as Video Conference equipment).
CCNP - ENTERPRISE - Create a Plan to Support Voice in the Campus
Voice over IP services are pretty much standard in the enterprise. Driven by the cost-reduction benefits VoIP delivers an excellent Return on Investment. Usually expensive to first deploy they recoup their costs over the life time of the deployment.
When planning to support VoIP consider the following points;
1) Voice and Data have to co-exist on the same network infrastructure but Voice can be affected by echo, jitter, and dropped audio. Use QoS to prioritise Voice traffic over Data.
2) Define a separate VLAN carry the voice traffic (create the VLAN then apply the interface command #switchport voice vlan [id] - on the ports carrying your voice traffic )
3) Plan for Power over Ethernet. The phones you use will require power. Usually delivered over the structured cabling, cat5e or such like, you need to be clear that your switch can deliver PoE. If it can make sure it can support the required number of handsets.
4) Plan for the traffic requirements. Voice traffic is generally smooth and predictable when managed properly. Keep in mind that packets are generally small, don't tolerate latency, uses UDP (TCP is pointless as once a word is said it cannot retransmit the data. Should a packet be lost, the conversation and therefore the traffic flow has moved on). Plan for delay to be no more than 150ms across the campus, plan for no more than 1% packet loss. Correct deployment of QoS can pre-empt these issues.
When planning to support VoIP consider the following points;
1) Voice and Data have to co-exist on the same network infrastructure but Voice can be affected by echo, jitter, and dropped audio. Use QoS to prioritise Voice traffic over Data.
2) Define a separate VLAN carry the voice traffic (create the VLAN then apply the interface command #switchport voice vlan [id] - on the ports carrying your voice traffic )
3) Plan for Power over Ethernet. The phones you use will require power. Usually delivered over the structured cabling, cat5e or such like, you need to be clear that your switch can deliver PoE. If it can make sure it can support the required number of handsets.
4) Plan for the traffic requirements. Voice traffic is generally smooth and predictable when managed properly. Keep in mind that packets are generally small, don't tolerate latency, uses UDP (TCP is pointless as once a word is said it cannot retransmit the data. Should a packet be lost, the conversation and therefore the traffic flow has moved on). Plan for delay to be no more than 150ms across the campus, plan for no more than 1% packet loss. Correct deployment of QoS can pre-empt these issues.
Wednesday, March 24, 2010
CCNP - ENTERPRISE - OSPF - Default Route propagation
By default OSPF does not propagate a default route, and so you need to manually tell OSPF to distribute one from your Autonomous System Border Router (ASBR).
Depending on the type of Area you have employed in your network the way you propagate a default to all your routers will differ slightly.
In Normal Areas (OSPF areas all connected to Area 0) you can do the following:
1) On your ASBR apply a default route:
R1(config)#ip route 0.0.0.0 0.0.0.0 10.1.1.1
2) Inject the default route in to OSPF:
R1(config)#router ospf 1
R1(config-router)#default-information originate [always]
- The [always] option allows you to advertise a default route from the ASBR even when one doesn't actually exist. This can potentially result in better stability for your network. For example, if a default route is learned from a different routing protocol such as RIP and this route for what ever reason starts to flap then every time the route changes type 5 LSA's will be sent into the OSPF domain from the ASBR.
- The [always] option helps prevent actions outside of the OSPF domain from affecting the routers/routes within the OSPF domain.
For Stub and Totally Stub areas the situation is different.
On an ABR you configure an area to be a stub. This in turn prevents type 5 LSA's (external route information) from being sent in to the stub area and in return a default summary route is propagated.
In a Totally Stubby area, this goes a step further. By configuring an area as a Totally Stubby area on the ABR you prevent Type 5 LSA's (for external routes) plus Type 4 and Type 3 LSA's (for inter-area summary routes) from being propogated. A default summary route replaces these types of routes.
In both cases, as a default route is automatically generated at the ABR, you do not require the default-information originate command.
Finally you have Not-So-Stubby-Area's (NSSA)
There are 2 ways to advertise a default route. NSSA ABR can generate a default route with or without a default route in its own routing table.
1) On the ABR connecting Area 0 to the NSSA area you force the ABR to generate a default route:
R3(config)#router ospf 1
R3(config-router)#area 8 nssa default-information originate
-With this example the ABR generates Type 7 LSA's with a link state ID of 0.0.0.0 this is then advertised within the NSSA area
- NOTE - NSSA ASBR can generate a default only when it has a default route in its routing table
- The default route via the ASBR must be known through non-OSPF protocol
2) You can also use the 'no-summary' option when defining your NSSA area and create 'NSSA Totally Stub area':
R3(config)#router ospf 1
R3(config-router)#area 8 nssa no-summary
-In this example you are replacing the Type 3,4,(inter-area summary routes) and Type 5 LSA's(external summary routes) with a default summary route.This is just as you do for a Totally Stubby area.
Depending on the type of Area you have employed in your network the way you propagate a default to all your routers will differ slightly.
In Normal Areas (OSPF areas all connected to Area 0) you can do the following:
1) On your ASBR apply a default route:
R1(config)#ip route 0.0.0.0 0.0.0.0 10.1.1.1
2) Inject the default route in to OSPF:
R1(config)#router ospf 1
R1(config-router)#default-information originate [always]
- The [always] option allows you to advertise a default route from the ASBR even when one doesn't actually exist. This can potentially result in better stability for your network. For example, if a default route is learned from a different routing protocol such as RIP and this route for what ever reason starts to flap then every time the route changes type 5 LSA's will be sent into the OSPF domain from the ASBR.
- The [always] option helps prevent actions outside of the OSPF domain from affecting the routers/routes within the OSPF domain.
For Stub and Totally Stub areas the situation is different.
On an ABR you configure an area to be a stub. This in turn prevents type 5 LSA's (external route information) from being sent in to the stub area and in return a default summary route is propagated.
In a Totally Stubby area, this goes a step further. By configuring an area as a Totally Stubby area on the ABR you prevent Type 5 LSA's (for external routes) plus Type 4 and Type 3 LSA's (for inter-area summary routes) from being propogated. A default summary route replaces these types of routes.
In both cases, as a default route is automatically generated at the ABR, you do not require the default-information originate command.
Finally you have Not-So-Stubby-Area's (NSSA)
There are 2 ways to advertise a default route. NSSA ABR can generate a default route with or without a default route in its own routing table.
1) On the ABR connecting Area 0 to the NSSA area you force the ABR to generate a default route:
R3(config)#router ospf 1
R3(config-router)#area 8 nssa default-information originate
-With this example the ABR generates Type 7 LSA's with a link state ID of 0.0.0.0 this is then advertised within the NSSA area
- NOTE - NSSA ASBR can generate a default only when it has a default route in its routing table
- The default route via the ASBR must be known through non-OSPF protocol
2) You can also use the 'no-summary' option when defining your NSSA area and create 'NSSA Totally Stub area':
R3(config)#router ospf 1
R3(config-router)#area 8 nssa no-summary
-In this example you are replacing the Type 3,4,(inter-area summary routes) and Type 5 LSA's(external summary routes) with a default summary route.This is just as you do for a Totally Stubby area.
Saturday, March 13, 2010
CCNP SWITCH Exam - why I failed...
So, last Friday morning I turn up to my local test centre ready to face the 642-813 Implementing Cisco IP Switched Networks exam. I had done the labs, read the books (David Hucaby's Official Certification Guide and the Foundation Learning Guide that accompanies the Cisco Networking Academy course), I had also passed my CCNP SWITCH Networking academy course with flying colours. So passing the certification exam was going to achievable wasn't it...WASN'T IT?
After 2 hours I knew I had failed even before the screen pinged up with my score. Close but no cigar. After the initial frustration (taken out on the interior of my car) I ran through the exam result sheet which clearly showed the Simulators sticking out like a sore thumb. Trying to think back at the questions I had faced also revealed another area - 'Planning'?.
Finally, I did a Google search for 'Failed CCNP SWITCH exam' and it was then that 2 + 2 made 4. On forums and chat rooms across the web one acronym kept turning up - BCMSN.
BCMSN! after smacking my fore head for being such a dumb ass I came to the realisation that that was what had let me down. I had used the old CBT Nuggets videos on the BCMSN. I had sourced abridged notes on the BCMSN study material (publically available from your popular studying blogs) combining them with the official SWITCh material I thought I had every thing covered. But I hadn't.
The new CCNP SWITCH focuses on practical hands on tasks required in such roles as a Network Engineer, BUT and here is the crux of my failure, it also focuses on the Preparation, Planning, Design, Implementation, Operation and Optimisation of a network. Some of the area's were tested thoroughly on the BCMSN exam but Preparation, Planning, and Design certainly weren't.
And so there I had it. I had nailed the practical stuff but dropped short on the Preparation, Planning and Design.
So what I am going to do? Well between now and 3 weeks time when I sit this exam again I'll be looking back at Chapter 1 - PPDIOO and tailoring my lab work against each criteria. Goodbye BCMSN videos and material and hello harder studying.
A (£117) lesson learnt. The hard way.
After 2 hours I knew I had failed even before the screen pinged up with my score. Close but no cigar. After the initial frustration (taken out on the interior of my car) I ran through the exam result sheet which clearly showed the Simulators sticking out like a sore thumb. Trying to think back at the questions I had faced also revealed another area - 'Planning'?.
Finally, I did a Google search for 'Failed CCNP SWITCH exam' and it was then that 2 + 2 made 4. On forums and chat rooms across the web one acronym kept turning up - BCMSN.
BCMSN! after smacking my fore head for being such a dumb ass I came to the realisation that that was what had let me down. I had used the old CBT Nuggets videos on the BCMSN. I had sourced abridged notes on the BCMSN study material (publically available from your popular studying blogs) combining them with the official SWITCh material I thought I had every thing covered. But I hadn't.
The new CCNP SWITCH focuses on practical hands on tasks required in such roles as a Network Engineer, BUT and here is the crux of my failure, it also focuses on the Preparation, Planning, Design, Implementation, Operation and Optimisation of a network. Some of the area's were tested thoroughly on the BCMSN exam but Preparation, Planning, and Design certainly weren't.
And so there I had it. I had nailed the practical stuff but dropped short on the Preparation, Planning and Design.
So what I am going to do? Well between now and 3 weeks time when I sit this exam again I'll be looking back at Chapter 1 - PPDIOO and tailoring my lab work against each criteria. Goodbye BCMSN videos and material and hello harder studying.
A (£117) lesson learnt. The hard way.
Tuesday, March 9, 2010
CCNP - ENTERPRISE - EIGRP Summarisation and NULL0
EIGRP Summarisation allows you to stream line the routing table making it more efficient. Fewer Routes listed results in less EIGRP updates being sent out and there fore less resources are consumed (Bandwidth, CPU ultilisation, load etc).
By default EIGRP performs auto-summarisation, that is to say that EIGRP will automatically summarise at a major class boundary during redistribution from EIGRP into a classful routing protocol (eg RIP).
EIGRP will also summarise at the major classful boundary when a route is advertised out of an interface that is on a different major class boundary.
In order to prevent a routing loop when summarisation is in effect (whether manual or automatic) a summary is automatically assigned to the NULL0 interface to prevent routing loops. If the router with a summary route received a packet for an unknown subnet that is part of a summarised range then the longest match ends up being the summary route itself (not a subnet of it) and so this is forwarded to the NULL0 interface and is dropped.
The idea is that the router is then prevented from forwarding the packet on to a default route and potentially creating a loop.
Benefits of summarising in this way include a smaller routing table leading to faster look ups, more specific routes will be hidden so if that specific route goes down the whole network does not need to recalculate the DUAL alogrithm, routing updates will be smaller and so limit the number of EGIRP Queries.
The down side of auto summarisation is that it won't factor in discontiguous networks. As a result you could have networks behind the same 172.16.0.0/16 network advertised out of 2 different interfaces to 2 different networks resulting in 50% of traffic arriving in the wrong place.
To address this issue you can disable automatic summarisation and use manual summarisation.
Disabling automatic summarisation is as simple as this:
R1(config)#router eigrp 1
R1(config-router)#no auto-summary
Now the router will not perform summarisation and all available subnets will be advertised.
Manual summarisation is configured on a per-interface basis, when a summary route is applied a NULL0 summary route entry is immediately created in the routing table to help prevent loops.
To configure a manual summary route you do the following:
R1(config)#router eigrp 1
R1(config-router)#no auto-summary
R1(config)#int s0/0/0
R1(config-if)#ip summary-address eigrp [AS] [IP] [Subnet Mask]
e.g) R1(config)#int s0/0/0
R1(config-if)#ip summary-address eigrp 1 172.16.0.0 255.255.224.0
With a manual summary route, the summary route is advertised only if a more specific entry of the summary is present in the routing table. Otherwise it won't appear in the routing table.
By default EIGRP performs auto-summarisation, that is to say that EIGRP will automatically summarise at a major class boundary during redistribution from EIGRP into a classful routing protocol (eg RIP).
EIGRP will also summarise at the major classful boundary when a route is advertised out of an interface that is on a different major class boundary.
In order to prevent a routing loop when summarisation is in effect (whether manual or automatic) a summary is automatically assigned to the NULL0 interface to prevent routing loops. If the router with a summary route received a packet for an unknown subnet that is part of a summarised range then the longest match ends up being the summary route itself (not a subnet of it) and so this is forwarded to the NULL0 interface and is dropped.
The idea is that the router is then prevented from forwarding the packet on to a default route and potentially creating a loop.
Benefits of summarising in this way include a smaller routing table leading to faster look ups, more specific routes will be hidden so if that specific route goes down the whole network does not need to recalculate the DUAL alogrithm, routing updates will be smaller and so limit the number of EGIRP Queries.
The down side of auto summarisation is that it won't factor in discontiguous networks. As a result you could have networks behind the same 172.16.0.0/16 network advertised out of 2 different interfaces to 2 different networks resulting in 50% of traffic arriving in the wrong place.
To address this issue you can disable automatic summarisation and use manual summarisation.
Disabling automatic summarisation is as simple as this:
R1(config)#router eigrp 1
R1(config-router)#no auto-summary
Now the router will not perform summarisation and all available subnets will be advertised.
Manual summarisation is configured on a per-interface basis, when a summary route is applied a NULL0 summary route entry is immediately created in the routing table to help prevent loops.
To configure a manual summary route you do the following:
R1(config)#router eigrp 1
R1(config-router)#no auto-summary
R1(config)#int s0/0/0
R1(config-if)#ip summary-address eigrp [AS] [IP] [Subnet Mask]
e.g) R1(config)#int s0/0/0
R1(config-if)#ip summary-address eigrp 1 172.16.0.0 255.255.224.0
With a manual summary route, the summary route is advertised only if a more specific entry of the summary is present in the routing table. Otherwise it won't appear in the routing table.
Subscribe to:
Posts (Atom)