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
Monday, March 29, 2010
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)