CCNP - TSHOOT - The Plan of Attack

For my final CCNP exam I've fore gone the Cisco Networking Academy and I've decided to self study. The main reason for this was a that I've moved jobs and the costs associated with attending the course are no longer being met by my employer.

Feed back I've had from fellow students who I was with on the CCNP SWITCH course has been that the TSHOOT academy course has not really been up to much. One student reported that he felt that he could have just bought the course manual and studied at home.

I find that disappointing as I had such a positive experience of the Cisco Networking Academy doing my CCNA, ISCW, BSCI and SWITCH Courses. In general I'd recommend that if you get a chance to attend a Cisco Networking Academy do it.

Moving on I think I'm about half way through my CCNP TSHOOT studies. At the present time I'm using the following materials to self-study:

CCNP TSHOOT Official Certification Guide by Kevin Wallace CCIE #7945
CCNP TSHOOT Cert kit by Kevin Wallace CCIE #7945, Brent Stewart, Eric Rivard
Troubleshooting and Maintaining Cisco IP Networks (TSHOOT) - Foundation Learning Guide by Amir Ranjbar CCIE #8669

Also I've taken a look at the TSHOOT demo questions - here - which are a great example to give you an idea of the test environment.

Finally, on the Cisco Learning Network you can obtain the actual L3, L2 and IPv6 topologies use for the TSHOOT Trouble Ticket Questions. You can find them  - here.

Use these topologies well. Inspect the lay out and inspect the notes. Can you see any Video Conferencing (therefore Multicast)? can you see any L3 redundancy? Which? Which VLAN's are in use? what do you think should be present in any trunk configs? Which routing protocols are in use? what would you expect the config to look like using these protocols? can you see any redistribution? can you type up any associated config?

This is where I'm at so far. Next stop my plan for approaching the TT questions in the exam.

CCNP - ENTERPRISE - Practical Application of Route-Maps

Imagine you are migrating from one ISP provider to another. The current provider not only offers your web filtering but also your DNS, web mail, and other hosted services so you can't simply cut them off. You need to be able to split out the Web filtering to your new provider whilst maintaining access to the old ISP for the hosted services.

As part of this move you are migrating the internet access of 300 sites. Each site is getting a new firewall as well and the move to the new ISP is taking place as each site gets it's new hardware.

Due to this hardware change you will end up with some sites on the old hardware pointing to the old ISP and some sites on new hardware pointing to the new ISP.

My question is this, with the minimum of in put by your self how do you run both ISP's at the same time and have the new sites point to the new ISP for the web filtering whilst maintaining access to the old ISP for everything else?

Here is the solution, on the router that provides the connection to both the Old ISP and the New ISP:

1) ip route 0.0.0.0 0.0.0.0 10.10.10.254
!
!
!
2) access-list 111 deny ip any 10.10.10.0 0.0.0.255
3) access-list 111 permit ip 192.168.10.0 0.0.0.255 any
!
4) route-map new-isp permit 10
5) match ip address 111
6) set ip next-hop 172.16.1.1
!
!
7) interface GigabitEthernet0/0
    description ***Inbound Interface towards the ISP's***
    ip policy route-map new-isp

Breaking it down line by line the config is as follows:
1) This is the default route to the old ISP. This required for all sites that have not migrated, also your hosted services are located in this direction. DNS, web mail, Anti-virus are located on servers on the 10.10.10.0/24 subnet.
2) Extended ACL denies packets from any Host going to the old ISP for hosted services, this stops that packet being processed by the route map and therefore prevents the next hop from being changed. The denied packet will be processed as usual by the routing engine and as such you maintain access to your hosted services.
3) This permits the packet from this subnet, to any destination, to be processed by the Route-map. As each site is kitted out with it's new hardware you add the site's IP range ( a /24) to this ACL. This in turn is permitted to be processed by your route-map and the next hope for web filtering is changed.

Remember that if your newly migrated site still needs access to DNS, web mail etc, this will be caught in the first line, the DENY any statement and will not proceed to the route-map for processing.

4) This is the entry for your route-map
5) The match statement catches permitted IP's in ACL 111
6) Any matched IP's in ACL 111 are then directed to the new ISP at 172.16.1.1, the New ISP will provide your web filtering only.
7) Apply your route-map to the inbound interface that receives the traffic from all the sites that are being migrated. The route-map is porcessed at this point and the next-hop defined.

So what happens next?
Each time you want to cut over a new site you simply add a permit statement to ACL111.
Straight away the route-map will pick it up and web traffic will be diverted from the old ISP to the New ISP.

Ultimately you will end up with up to 300 sites listed in ACL111. Once all sites have been migrated you can change your default route, remove the route-map and run access to the internet as normal.

CCNP - ENTERPRISE - Switch Security Features - IP Source Guard

IP Source is used to prevent IP Spoofing where an attacker impersonates another host by using it's IP address.

IPSG provide per-port filtering of the assigned source IP, it dynamically maintains per port VLAN ACL's based on the IP-to-MAC bindings set out in the DHCP Snooping database.

IPSG is applied on Untrusted ports and can filter a Source IP or a combination of Source IP and MAC address.

When a violation occurs the packet can be dropped and/or an alert be issued.

Apply IPSG to Access Layer interfaces

Configure IP Source Guard
First enable DHCP Snooping:
  SW1(config)#ip dhcp snooping

Next, apply DHCP Snooping against a specific vlan (or vlans):
  SW1(config)#ip dhcp snooping vlan [id]

Enable IPSG on a specific interface:
  SW1(config-if)#ip verify source vlan [id] dhcp snooping*
    - use this command to verify only source IP addresses

  SW1(config-if)#ip verify source vlan [id] dhcp snooping port-security
   - use this command to verify against source IP and MAC address

Optionally, you can also rate limit and interface
  SW1(config-if)#switchport port-security limit rate [invalid-src-MAC] [rate]

You can also statically bind an IP address to a port:
  SW1(config-if)#ip source binding [ip] vlan [id] interface [id]

Verify IP Source Guard
Use the following commands to verify your configuration:
  SW1#show  ip source binding
   - Displays MAC-to-IP binding, type of binding, vlan membership, interface the binding applies to.

 SW1#sh ip verify source
   - Displays your interface, filter type and mode, IP addr, MAC addr, and VLAN

CCNP - ENTERPRISE - Switch Security Features - Dynamic ARP Inspection

DAI is used to prevent invalid or gratuitous ARP requests in the same VLAN.

When ARP is used correctly, a host sends a broadcast to locate the MAC of a destination host. The Destinations host replies with it's MAC and the originator caches that MAC address and applies it to the Dest field in it's packets.

ARP spoofing is where an attacker appears as the Destination host by supplying it's MAC address against the legitimate host's IP address. The Originating host caches the attacker's MAC and directs packets to the rogue Destination instead of the legitimate Destination.

Operation
DAI intercepts packets on Untrusted ports, packets are then validated for IP-to-MAC bindings that have been gathered from DHCP Snooping.

Denied packets are dropped and/or logged. Incoming ARP requests from Trusted ports are not inspected. Like DHCP you can also rate limit the ARP requests per second. Rate limiting can help prevent port scanning.

Configure DAI
In general configure all Access ports as Untrusted. Configure all switch trunks as Trusted so that no further inspection of packets is required as the request travels through the Access-Distribution- Core of your infrastructure.

Enable DAI on a per VLAN basis:
  SW1(config)#ip arp inspection vlan [id]

Define your trusted ports:
  SW1(config-if)#ip arp inspection trust

NOTE - default configuration for ports is Untrusted.

Verify DAI
Use the following commands to verify your config:
  SW1#show ip arp inspection interfaces
   - Displays interfaces, trust level, any rate limiting, and any bursts noted.

  SW1#show ip arp inspection vlan 10
   - Displays DAI state for the vlan (Enable/Disabled)

  SW1#show ip dhcp snooping bindings
  - Displays MAC-to-IP bindings.

CCNP - ENTERPRISE - Switch Security Features - DHCP Snooping

The following tools can be used to mitigate against Denial of Service attacks and Spoofing attacks.

DHCP Snooping
Feature found on Catalyst switches, DHCP snooping prevents attacks against DHCP servers by monitoring which ports are allowed to pass DHCP packets.

A typical attack can be where an attacker configures a rogue DHCP server and connects it to a port on your switch. When a client sends a DHCP Request out the rogue DHCP server attempts to respond quicker than legitimate DHCP servers. The rogue DHCP server offers the client IP settings (including default gateway and DNS servers) and can then direct the client to use an Attacker's client as it's own DFG. As a result the attacker can now see all of the client's traffic.

Another type of attack can be a denial of service where the attacker floods the legitimate DHCP with 1000's of DHCP Requests it over runs the server and the server is prevented from responding to legitimate DHCP requests.

How DHCP Snooping works is that once set the switch has Trusted and Untrusted ports for DHCP traffic. A trust port is for ports connected to DHCP servers or links that allow access to DHCP servers. The Trusted port is allowed to pass all DHCP Packet types (DHCP Discover, Offer, Unicast Request, Unicast ACK).

An Untrusted port is a port that shouldn't have a DHCP server on and so only be allowed to make a request to a DHCP Server.

Once configured if a rogue device connected to a DHCP Snooping Untrusted port tries to respond to a legitimate request the switch shuts down the port.

Configure DHCP Snooping
DHCP Snooping is enabled globally:
  SW1(config)#ip dhcp snooping

By default all interfaces are untrusted and you define your trusted ports:
  SW1(config-if)#ip dhcp snooping trust

Optionally, on Untrusted ports you can limit the number of DHCP packets allowed per second:
  SW1(config-if)#ip dhcp snooping limit rate [rate]
     - this command can prevent DHCP Starvation attacks where are available leases are used up.

Finally, you can configure DHCP Snooping on specific VLANs:
  SW1(config)#ip dhcp snooping vlan number [id]

Verifiy DHCP Snooping
Use the command:
  SW1#show ip dhcp snooping
    - displays state of dhcp snooping, configured VLANs, configured interfaces, any rate limiting in effect.

CCNP - ENTERPRISE - QoS pointers

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.

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.

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.

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.