This article is a work in progress and I'll keep coming back to this. Apologies if you read this and think there's not much here.
Quality of Service is a mechanism to address the following traffic flow characteristics:
Delay/Latency - time it takes for a packet to reach the destination
Jitter - Variation of the delay or a stream of data
Packet Loss - number of packets lost between the src and dest points.
Tuesday, March 29, 2011
CCNP - ENTERPRISE - Planning a Wireless Deployment
When planning for a a wireless deployment consider the following points in formulating your plan.
1) Will your solution use Standalone Access Points (AP's) or be a Controller-based solution using Lightweight Access Points (LAP's)?
Standalone AP's - Operate independently, have standalone IOS on board, are configured directly on the AP, can be managed via Wireless LAN Solution Engine (WLSE) and redundancy is offered by deploying multiple AP's.
Controller-Based AP's - Are dependent on a Wireless LAN Controller (WLC), IOS is delivered to the LAP via the WLC, configurations are applied from the WLC, management is via the WLC, and redundancy is provided by the deployment of multiple WLC's.
2) Collect information on the required switch ports to connect your AP's and WLC or WLSE
3) Check the local infrastructure to make sure the new WLAN solution can be implemented, this will include monitoring available bandwidth.
4) Set out a plan for the additional equipment required.
5) Plan your implementation, to include where you intend to locate the AP's, the configuration of the AP's/WLC, necessary configuration of the switch ports (do you require trunks for Standalone AP's or an access port for a LAP?).
6) Develop a plan to test your new WLAN solution which could include check points such as does the client get an IP address? Can the management devices reach the AP's or WLC? Can the WLC reach the RADIUS server (for authentication).
With the information gathered from the points above you should be able to formulate a suitable plan that can be deployed and verified.
1) Will your solution use Standalone Access Points (AP's) or be a Controller-based solution using Lightweight Access Points (LAP's)?
Standalone AP's - Operate independently, have standalone IOS on board, are configured directly on the AP, can be managed via Wireless LAN Solution Engine (WLSE) and redundancy is offered by deploying multiple AP's.
Controller-Based AP's - Are dependent on a Wireless LAN Controller (WLC), IOS is delivered to the LAP via the WLC, configurations are applied from the WLC, management is via the WLC, and redundancy is provided by the deployment of multiple WLC's.
2) Collect information on the required switch ports to connect your AP's and WLC or WLSE
3) Check the local infrastructure to make sure the new WLAN solution can be implemented, this will include monitoring available bandwidth.
4) Set out a plan for the additional equipment required.
5) Plan your implementation, to include where you intend to locate the AP's, the configuration of the AP's/WLC, necessary configuration of the switch ports (do you require trunks for Standalone AP's or an access port for a LAP?).
6) Develop a plan to test your new WLAN solution which could include check points such as does the client get an IP address? Can the management devices reach the AP's or WLC? Can the WLC reach the RADIUS server (for authentication).
With the information gathered from the points above you should be able to formulate a suitable plan that can be deployed and verified.
Monday, March 28, 2011
CCNP - ENTERPRISE - Create an Implementation Plan for Inter-VLAN Routing
Inter-VLAN routing can be implemented in several ways. You might wish to configure an external router, use an SVI on a Layer3 (L3) switch, or use routed ports on an L3 switch.
Which ever way you choose to implement your configuration you'll need an implementation plan.
The following steps outline the considerations you need to make with regards to using an external router:
1) Know how many VLANs need routing, their ID number, name, and which ports will connect to the router
2) On the router, work out your sub-interface requirements. You'll have a single link running from the router to the switch configured as a trunk. On the router side you'll then need a sub interface for each VLAN you're wishing to provide inter-VLAN routing for. Number each sub-interface logically i.e. - the same as the VLAN it represents. Ensure the encapsulation method is the same across each sub-interface and across the link to the switch. (usually Dot1q all round).
3) Decide on the Native VLAN and ensure it is the same on either end of the link.
use the command - #int f0/0.[id]
#encapsulation dot1q [vlan-id] native*
4) Finally use the interface command - #encapsulation dot1q [vlan-id] - to associate a VLAN to a sub-interface
*Remember that traffic on the Native VLAN is not tagged
The following steps outline the considerations you need to make with regards to using an SVI:
1) On your L3 switch identify the VLANs that require a default gateway.
2) For any SVI's not already present on your L3 switch you will need to create then. As such you will need to decide on suitable numbering for the SVI (should be the VLAN ID number) plus an IP address to associate with it. Don't forget to No Shutdown the interface.
3) To perform L3 routing functions you need to set the L3 switch to be able to perform the routing. To achieve this use the global command - #ip routing - this will enable to switch to route between your VLANs
4) Define any appropriate dynamic routing protocols. Typically required if you are configuring a larger enterprise network that may be subject to change. You can deploy RIP, EIGRP, OSPF which ever you feel is appropriate.
5) Finally with the information above gathered consider if you require any given SVI to be excluded from contributing to the SVI state Up-Down calculation. Do this using the 'Autostate' feature
The following steps outline the considerations you need to make with regards to using an Routed port:
1) Plan your addressing for each VLAN and which port is going to be a routed port.
2) The remaining steps are much like the SVI. Configure your routed port using the command #no switchport - which removes L2 capability. Apply an IP address and enable the port via the #no shutdown command.
REMEMBER - when you are under pressure and your links are not up use the command - #sh ip int brief - to make sure you have enable the port concerned. If you see 'Administratively Down' against your problem port go back and do a #'no shutdown - Obvious I know but you wouldn't believe how many times I've seen students scratching their heads in a lab because of this.
3) To allow inter-VLAN routing use the global command - #ip routing - then apply any dynamic routing protocols as required.
Which ever way you choose to implement your configuration you'll need an implementation plan.
The following steps outline the considerations you need to make with regards to using an external router:
1) Know how many VLANs need routing, their ID number, name, and which ports will connect to the router
2) On the router, work out your sub-interface requirements. You'll have a single link running from the router to the switch configured as a trunk. On the router side you'll then need a sub interface for each VLAN you're wishing to provide inter-VLAN routing for. Number each sub-interface logically i.e. - the same as the VLAN it represents. Ensure the encapsulation method is the same across each sub-interface and across the link to the switch. (usually Dot1q all round).
3) Decide on the Native VLAN and ensure it is the same on either end of the link.
use the command - #int f0/0.[id]
#encapsulation dot1q [vlan-id] native*
4) Finally use the interface command - #encapsulation dot1q [vlan-id] - to associate a VLAN to a sub-interface
*Remember that traffic on the Native VLAN is not tagged
The following steps outline the considerations you need to make with regards to using an SVI:
1) On your L3 switch identify the VLANs that require a default gateway.
2) For any SVI's not already present on your L3 switch you will need to create then. As such you will need to decide on suitable numbering for the SVI (should be the VLAN ID number) plus an IP address to associate with it. Don't forget to No Shutdown the interface.
3) To perform L3 routing functions you need to set the L3 switch to be able to perform the routing. To achieve this use the global command - #ip routing - this will enable to switch to route between your VLANs
4) Define any appropriate dynamic routing protocols. Typically required if you are configuring a larger enterprise network that may be subject to change. You can deploy RIP, EIGRP, OSPF which ever you feel is appropriate.
5) Finally with the information above gathered consider if you require any given SVI to be excluded from contributing to the SVI state Up-Down calculation. Do this using the 'Autostate' feature
The following steps outline the considerations you need to make with regards to using an Routed port:
1) Plan your addressing for each VLAN and which port is going to be a routed port.
2) The remaining steps are much like the SVI. Configure your routed port using the command #no switchport - which removes L2 capability. Apply an IP address and enable the port via the #no shutdown command.
REMEMBER - when you are under pressure and your links are not up use the command - #sh ip int brief - to make sure you have enable the port concerned. If you see 'Administratively Down' against your problem port go back and do a #'no shutdown - Obvious I know but you wouldn't believe how many times I've seen students scratching their heads in a lab because of this.
3) To allow inter-VLAN routing use the global command - #ip routing - then apply any dynamic routing protocols as required.
Sunday, March 27, 2011
CCNP - ENTERPRISE - VLAN Best Practices
When deploying VLANs consider the following points for best practice. Sometimes limitations may occur such as budget or physical locations (lack of space in your racks) however where possible try to deploy the configuration points.
- For local VLANs try to limit access modules to 1-3 VLANs. Limit these local VLANs to the Access and Distribution switches in your switching block
- Avoid using VLAN 1 as the 'black hole' for unused ports.
- Have separate Data, Voice, Management, Native, 'Black Hole' or 'Parked' VLANs
- Avoid VTP for local VLAN deployments (you're not intending on populating the local VLANs across the campus therefore you don't want VTP to inadvertently advertise these VLANs across your switching infrastructure)
- For Trunk ports - hard set your ports to trunks - don't rely on DTP. (#switchport mode trunk NOT #switchport mode desirable)
- Use Dot1q not ISL - this has better support for QoS.
- Manually configure access ports - #switchport mode access
- Prevent data traffic from VLAN 1, only use it for management protocols that default to using VLAN 1 such as DTP, VTP, STP BPDU's, PAgP, LACP, CDP et al
- Use SSH for management access not telnet.
CCNP - ENTERPRISE - Create a VLAN based implementation plan
The first in a series of posts relating to planning is on VLAN implementation.
The steps you should cover when planning a new deployment of VLANs should be as follows:
1) Understand your network. Define the purpose of your VLANs and assign suitable numbers, names, and allocate suitable subnets for each VLAN
2) Document which VLAN should be allocated to which part of the campus. In doing so you need to determine the traffic flow between switches and so which VLANs need to be available across which switches.
3) determine how you allocate unused ports on your switch. Will you leave them as default setting, assign them to a 'Parked' VLAN, assign them to the default or native VLAN?
4) Consider you trunking configuration. Where will they be placed? which VLANs will traverse them? which is your Native VLAN?
5) Determine your VTP stance. Will it be used? if so which switch is your Server? which switches can be Clients? will you need any Transparent switches?
6) Create a plan to test the implementation. Verify the VLANs traverse the network as expected, confirm there is capacity for future growth.
With the information gathered from the steps above you can move to the design stage of the PPDIOO and set out your deployment. From there you can implement your plan and verify it prior to making the deployment operational.
The steps you should cover when planning a new deployment of VLANs should be as follows:
1) Understand your network. Define the purpose of your VLANs and assign suitable numbers, names, and allocate suitable subnets for each VLAN
2) Document which VLAN should be allocated to which part of the campus. In doing so you need to determine the traffic flow between switches and so which VLANs need to be available across which switches.
3) determine how you allocate unused ports on your switch. Will you leave them as default setting, assign them to a 'Parked' VLAN, assign them to the default or native VLAN?
4) Consider you trunking configuration. Where will they be placed? which VLANs will traverse them? which is your Native VLAN?
5) Determine your VTP stance. Will it be used? if so which switch is your Server? which switches can be Clients? will you need any Transparent switches?
6) Create a plan to test the implementation. Verify the VLANs traverse the network as expected, confirm there is capacity for future growth.
With the information gathered from the steps above you can move to the design stage of the PPDIOO and set out your deployment. From there you can implement your plan and verify it prior to making the deployment operational.
Subscribe to:
Posts (Atom)