Extend your LAN across multiple sites using L2TPv3 Tunnels

We have a situation where we want to move a number of servers from our office to our data centre. In order for our networking monitoring to remain active we need to be able to present the same subnet at both locations as though they were on a local LAN.

To achieve this we've implemented L2TPv3 Tunnels (L2 tunnel) using Pseudo-wires on routers at each location.

This article is to document the steps taken to implement the solution so I have record it should I want to do this again.

First off a few definitions courtesy of Wikipedia.org:
L2TPv3 -Layer 2 Tunneling Protocol Version 3 is an IETF standard related to L2TP that can be used as an alternative protocol to Multiprotocol Label Switching (MPLS) for encapsulation of multiprotocol Layer 2 communications traffic over IP networks. Like L2TP, L2TPv3 provides a ‘pseudo-wire’ service, but scaled to fit carrier requirements.

Pseudo-wire - a pseudowire (or pseudo-wire) is an emulation of a point-to-point connection over a packet-switching network. The service being carried over the "wire" may be Asynchronous Transfer Mode (ATM), Frame Relay, Ethernet or Time-division multiplexing (TDM) while the packet network may be Multi-protocol label switching (MPLS), Internet Protocol (IPv4 or IPv6), or Layer 2 Tunneling Protocol Version 3 (L2TPv3).

You will need:

• 2 routers capable of configuring L2tpv3 and Pseudo-wires, in our case we used Cisco 1841 routers running IOS:c1841-spservicesk9-mz.124-17b.bin

• Loopback interfaces on each router configured with an IP address (/32) that is routable to. These are the source IP's in your config so make sure you can ping them from each side before you start with the L2TPv3 tunnel config.

The network will look like this:

You are going to configure the tunnel on routers R3 and R4 with the tunnel configuration applied to the LAN side port on each router. The source of the tunnel will be a loopback interface on each router, so this needs to be routable.

Step 1 - Configure your routers for general connectivity. Apply a /32 address to Lo0, apply a public IP to your WAN side interface and leave the LAN side interface with out an IP.

Step 2 - Configure your routing. How ever you choose to configure your routing (EIGRP, OSPF, Static) you need to ensure R3 can ping Lo0 on R4 and visa versa.

Step 3 - Define your L2TPv3 'class' - used to configure connection parameters such as authentication and hello timers. Configure it on each router as follow:
R3#conf t
R3(config)# l2tp-class networkstV3class
R3(config)#authentication
R3(config)#password N3tw0rkStud1es
+++
R4#conf t
R4(config)# l2tp-class networkstV3class
R4(config)#authentication
R4(config)#password N3tw0rkStud1es


Step 4 - Next apply this to a Pseudo-Wire and define your Lo0 interface as the source of the L2TPv3 tunnel:
R3(config)#pseudowire-class NETWORKST-PW
R3(config-pw-class)#encapsulation l2tpv3
R3(config-pw-class)#protocol l2tpv3 networkstV3class
R3(config-pw-class)#ip local interface loopback0
+++

R4(config)#pseudowire-class NETWORKST-PW
R4(config-pw-class)#encapsulation l2tpv3
R4(config-pw-class)#protocol l2tpv3 networkstV3class
R4(config-pw-class)#ip local interface loopback0


Step 5 - Finally apply the pseudo-wire to the interface that connects to your LAN:
R3(config)#int f0/1
R3(config-if)#xconnect 40.40.40.40 1 pw-class NETWORKST-PW
   - the xconnect cmd associates the interface f0/1 to the remote peer's pseudo-wire located at 40.40.40.40
 - the figure 1 is a virtual circuit ID and needs to match at both ends.


R4(config)#int f0/1
R4(config-if)#xconnect 30.30.30.30 1 pw-class NETWORKST-PW

Step 6 - Verify the configuration, use the following command to verify the tunnel is up:
R3#sh l2tun tunnel all
%No active L2F tunnels
L2TP Tunnel Information Total tunnels 1 sessions 1

Tunnel id 60290 is up, remote id is 28046, 1 active sessions
  Tunnel state is established, time since change 20:14:20
  Tunnel transport is IP (115)
  Remote tunnel name is R4
    Internet Address 40.40.40.40, port 0
  Local tunnel name is R3
    Internet Address 30.30.30.30, port 0
  Tunnel domain unknown
  VPDN group for tunnel is not available
  L2TP class for tunnel is l2tp_default_class
  271913 packets sent, 31678 received
  36256510 bytes sent, 2837214 received
  Last clearing of "show vpdn" counters never
  Control Ns 1216, Nr 1218
  Local RWS 1200 (default), Remote RWS 1200 (max)
  Tunnel PMTU checking disabled
  Retransmission time 1, max 1 seconds
  Unsent queuesize 0, max 0
  Resend queuesize 0, max 1
  Total resends 0, ZLB ACKs sent 1217
  Current nosession queue check 0 of 5
  Retransmit time distribution: 0 0 0 0 0 0 0 0 0
  Sessions disconnected due to lack of resources 0

%No active PPTP tunnels

- here you are really looking at Packet sent and received. Should you find that either is zero then trouble shoot accordingly. Look at physical connectivity and routing.

Once you have active tunnels connect the LAN side interface to a switch on the same VLAN as your office LAN then connect your servers.

CCNP - Job Done.

Yesterday I passed the TSHOOT exam and thus completed my CCNP. I had a tense afternoon as I eagerly waited for my certification tracking account to sync to with Pearson Vue but late last night the e-mail came through from Cisco Training telling me I had achieved the CCNP and I could claim my logos.

My experience sitting the TSHOOT exam was a much improved one from the previous test centre I used to go to. I was advised that my usual company had actually gone out of business. So here I was at a strange test centre hoping to claim my prize.

I'm not going to test the NDA but I will say that the experience of the exam was like none I've ever encountered. It's on record that you can dip in and out of the tickets as you see fit. If you get stuck on one question you can select Abort and check the config in another ticket so see if you're right. I found I needed to do this on 2 occasions to confirm my line of thinking and but it felt like I was cheating some how. In all other Cisco exams once you move on to the next question you can't go back.

If I'm honest I'd have to say they could probably do that on this exam. You have to answer all the questions any way and I submitted them in order so that I could manage my time correctly.

In previous posts I've mentioned approaches to tackle the exam, Kevin Wallace recommended the Abort method above, one other method I used was to let the question guide me. On more that one question I had narrowed the problem to a particular device (so that's Q1) and could tell that a particular technology was the issue (so that's Q2 sorted) but I struggled to pin point the cause. I simply reviewed the answers available to me in Q3. Once you eliminate the ridiculous answers you're left with 2 or 3 plausible answers that you can work with.

My final point is about time management. I found this exam very enjoyable and once you pinpoint the cause a problem you rattle through the 3 part trouble ticket quickly. If you know your show commands and can comfortably recall the correct command to display the most helpful information then I genuinely think you shouldn't worry about the time.

Right. Time for a rest then I'm going to put some serious consideration as to whether the CCIE is worth my effort...

CCNP - ENTERPRISE - EIGRP Troubleshooting Targets

For EIGRP issues look to the following:

- If Adjacencies are not forming check:
Timers match, AS number matches
In Frame-Relay topologies check that you have included the 'broadcast' option to allow the multicast packets that are sent to 224.0.0.10 to be forwarded.
Check for any ACL's blocking EIGRP specifically or the subnets in general
Check that the router interfaces are up, you can ping the neighbour ( if it isn't up then troubleshoot the interface config as appropriate)

- If Static/Dynamic routes are not being redistributed in to EIGRP check:
Routes learned by EIGRP are in the Routing Table
Check the EIGRP topology table to see if the route was learned at all
Check the EIGRP config to ensure you are advertising the correct networks
Are there any Distribution Lists filtering your network?
For discontiguous networks check that no auto-summary is applied.

- For the Error 'Not on common Subnet' check:
IP addressing the interfaces that should be forming an adjacency.
Remember EIGRP packets are sourced from the Primary IP address on the interface. As such you can't use a Secondary IP to form the adjacency.

- If Load Balancing does not operate as expected check:
Ensure you have correctly used the Variance command in the Router process (not at the interface)

- Do you get 'Stuck in Active' (SIA) errors?
Check that the router has enough resources to respond to EIGRP updates (#sh processes cpu)
Check the bandwidth parameter on the interface is set correctly
Check #sh interfaces for interface resets, input/output errors.
If you do observe these issues look at hardware upgrades.

CCNP - ENTERPRISE - OSPF Troubleshooting targets

When troubleshooting OSPF look for the following:

1. What routes are present in the routing table
2. Check the status of OSPF adjacencies
3. Check the networks are advertised properly (in subnets)
4. Check your virtual-links are configured correctly
5. Check your timers match at each end of your links
6. Check you have OSPF configured to use the correct network type for your media

CCNP - ENTERPRISE - Troubleshooting Methodology...

Regardless of the particular issue at hand trouble shooting generally flows as follows:

Problem Reported ---------> Diagnosis ---------> Resolution

You'll find the bulk of your time concentrating around the Diagnosis part of the process.

For the CCNP TSHOOT exam you need to know process of troubleshooting an issue, which is:
START

1. Collect information - from users/reports/monitoring
2. Examine the information - such as comparing your gathered information with that of a baseline measurement
3. Eliminate potential causes - this is where you'll use your knowledge about your local network
4. Hypothesise a cause - Consider the most likely cause based on the information you have gathered
5. Verify the hypothesis - Test/reject the theory regarding the cause

END

It's important to note that your should always be methodical. Do not jump about the steps otherwise you'll lose track of what you've done and cause further delay.

Experience engineers may proceed straight to step 4 if they have a good hunch about what is causing the issue however such action (known as 'Shoot from the Hip') can cause time delays if the hypothesis is wrong.

CCNP - ENTERPRISE - notes on Archive cmd features

A useful tool to automatically back up your running-config is the Archive tool set.

Part of Cisco's Archive and Restore features it allows you to take the running-config and archive on to either that  device or to a remote device such as a tftp server.

Set up an Archive using the following:
R1#conf t
R1(config)#archive
R1(config-archive)#path tftp://10.10.10.10/$h.txt
R1(config-archive)#write-memory
R1(config-archive)#time period 10080

In the above you set the destination server, the $h indicates that the archive will automatically be called [the host name of the router]-1.txt. The next archive will be [host name]-2 and so on...

Write-memory prompts the archive process to run every time write-mem is executed and the time period is set in minutes to automatically execute an archive backup.

So you now have your archive running. Next you decide you need an archived config to be restored.

You 'could' perform a #copy tftp run but remember that this will only merge the saved copy into the running config not totally over write it.

You 'could' perform a #copy tftp start but that would require a reload to restart the system and boot using the startup-config.

To immediately install an archived config perform a replace:
R1#configure replace tftp://10.10.10.10/r1-1.txt

What then occurs is the router compares the archive to the running config and compiles the commands needed to apply the archive to the running-config. It then executes them and the configuration the takes immediate effect.

CCNP - ENTERPRISE - IPv6 - Some thoughts...

In no particular order, notes that I took following from my day on a RIPE NCC training course about deploying IPv6:

1) Considering the IPv6 address is 128 bits long when you request an allocation from RIPE NCC (or who ever your RIR is) you get a minimum /32. That's 429,496,796 /64 subnets available for you to assign to your customers as you see fit! which is 18,446,744,073,709,551,616 host addresses! so you've got room to manoeuvre.
2) Best practice states that for a network assignment assign a subnet no longer than a single /64 subnet. The first 64-bits will be the network portion of your host address so the remaining 64 bits use as the host portion of the address.
Which is to say just as you would assign a single /24 , for example, to each VLAN on your network do likewise with an IPv6 /64 subnet. Now, you might only have a single mail server on a VLAN so you think that    having one system using up a /64 subnet is a bit of a waste but consider that there already applications out there that expect you to be using a /64 subnet as the smallest network. If you start allocating random, non-best practice subnets, e.g. a /127, then you might potentially cause problems for your self in the future. Don't do it.
3) Don't fear the waste. Look at the numbers above, give your self plenty of addresses to play with on each VLAN and then when systems come along that have separate IPv6 addresses for individual procedure calls you're well equipped to handle it.
4) When subnetting an IPv6 address, best practice states you should allocate subnets from a 4 bit boundary. Remember that an IPv6 group is made up of 4 hexadecimal figures each of which represents a 4 bit binary figure. keeping the subnetting to nice 4bit boundaries basically stops your head imploding. The network subnets can be as follows- /32, /36, /40, /44, /48, /52, /56, /60, /64.
In our examples on the course we allocated a /48 for a single data centre, then subnetted that in to /60's for your routers/firewall/switches then within the switch infrastructure subnet your switch's /60 into /64's for each VLAN. Nice and tidy.
5) Within your business do not have an IPv6 specialist! you don't have an IPv4 specialist do you? if you avoid looking at IPv6 all that will happen is that you personally will be left behind and then when you're made redundant with no IPv6 experience/knowledge to speak of you'll be screwed.
6) Don't delay. Look at the figures in the widget provided by Hurricane Electric --> IPv6 is coming and fast. Emerging economies in Asia and Africa already have to use IPv6 natively because the IPv4 address have been exhausted. The last thing you want is a new market unable to access your website because you haven't got round to provisioning your website for IPv6.
7) My final thought is that within your organisation you should agree a policy on how to write IPv6 address and stick to it. You can choose to stick with typing out the full 128-bit address (8 groups of 4 Hexadecimal figures), You can choose to simply drop leading zero's, or agree to drop all leading zero's and replace contiguous groups of 4 zeros with a ::. Which ever method of representing an IPv6 address you choose make sure everyone sticks to it because it will make things easier when trouble shooting if the address format appears the same throughout your network.

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.

CCNP - ENTERPRISE - Spanning-tree Protocol - Tools to Prevent Loops

There are a number of tools that can be employed to make the STP topology more stable.

1) Root Guard - prevents an unexpected switch from becoming the Root Bridge. Enable RootGuard on all non-root ports on all switches expect the Root bridge.

If a designated port receives a superior BPDU that could cause the bridge to accept a different switch as the Root Bridge the port enters a 'root-inconsistent' state (instead of transitioning to a Root Port and therefore changing the STP topology).

The 'root-inconsistent' state will remain for as long as there are superior BPDU's being received on the port. Once the BPDU's stop the port cycles through the STP states to return to it's usual function.

Enabled on a per-port basis only:
sw1(config-if)#spanning-tree guard root

2) BPDU Guard - loop prevention mechanism applied to ports using PortFast so that if a BPDU is recieved on the port the port is placed in to an error-disabled state instead of allowing the traffic to be forwarded and potentially creating a loop.

If a BPDU is being received on the port there must, by definition, be another switch on the other end of the link. PortFast enable ports transition to a forwarding state instantly which is a benefit for end-station devices such as PC's which would be requiring a DHCP address as part of it's start up process. If you had a switch connected to a PortFast enable port packets could be forwarded and a loop created. BPDU Guard helps prevent this.

Enabled globally via:
sw1(config)#spanning-tree portfast bpduguard default

Or on per-interface basis via;
sw1(config-if)#spanning-tree bpduguard enable

3) BPDU Filtering - If a BPDU is received on a PortFast Port BPDU Filtering detects this and removes the PortFast status on the port. The port then transitions through the STP stages and the port then takes it place in the STP topology.

It works slightly differently depending on how the command is executed. When applied globally:
sw1(config)#spanning-tree portfast bpdufilter default

The PortFast enabled port loses it's PortFast status and transitions through the STP stages

When applied at interface level:
sw1(config-if)#spanning-tree bpdufilter enable

The PortFast enabled port is prevent from sending and receiving BPDU's entirely.

4) Unidirectional Link Detection - UDLD - A unidirectional link occurs when a physical fault on a link is such that electrical keepalives can pass across the link but can't pass data in both directions. UDLD detects this state by sending periodic hellos across the link which must be acknowledged.

There are 2 modes -
i) Normal - Link state turns to Undetermined State, port is allowed to continue working and UDLD marks the port and generates a syslog message

ii) Aggressive - The port is set to 'error-disabled', manual intervention is then required.

When enabled Globally it ONLY applied to Fibre ports:
sw1(config)#udld {enable | aggressive}

When configured on a per-port basis use the same command however you now have the option to disable it entirely if you are using a fibre optic port.
sw1(config-if)#udld {enable | aggressive | disable}

Re-enable a port shut down due to UDLD:
sw1(config-if)#udld reset

Verifiy UDLD:
sw1#sh udld interface

5) Loop Guard - Prevents loops forming on ports that transition from Blocking to Forwarding due to suddenly not receiving BPDU's from the switch on the other end of the link. If BPDU's stop being received on a blocking port the max-age timer eventually expires (as there haven't been any further BPDU's to refresh the timer) and the port then cycles through the STP states as it thinks there is no longer another switch on the other end of the link.

If the port transitions to a forwarding state then a loop can occur. Loop Guard helps prevent this sequence of events by tracking BPDU activity on non-designated ports.

If BPDU's are suddenly no longer received Loop Guard puts the port in to a 'Loop Inconsistent' blocking state. The port then remains in a blocking state and a loop can be avoided.

Loop Guard automatically enables the port again once BPDU's start being received again.

Enable globally via the command:
sw1(config)#spanning-tree loopguard default

Enable on specific ports using:
sw1(config-if)#spanning-tree guard loop

Loop Guard works on a per VLAN basis so doesn't block the entire port simply the VLAN is blocked.

CCNP - ENTERPRISE - Spanning-tree Protocol Link Convergence Tools

The following tools allow for faster link convergence in relation to STP:
1) Portfast - Applied on access switch ports linked to host devices (not other switches). Transitions the port to a forwarding state straight away instead of transition through the STP states Listening (15 secs), then Learning (15 secs), and finally forwarding. Not to be used on trunk links as it could result in loops occurring.

Applied globally via:
sw1(config)#spanning-tree portfast default

Or per interface:
sw1(config-if)#spanning-tree portfast

Portfast is also applied using the macro interface command:
sw1(config-if)#switchport host

2) UplinkFast - Applied to access switches, allows fast fail-over when dual uplinks are connected to a distribution layer switch. Can incorporate multiple redundant links to an uplink switch (not just 2 links), where there are more than 2 redundant links to a given switch the link with the next lowest root path cost is unlocked  immediately.

UplinkFast bypasses the Listening and Learning stages.

Note that the command is not allowed on a Root bridge as UplinkFast ensures that the local switch does not become the Root bridge. UplinkFast raises the Bridge Priority to 49,152 therefore it is unlikely the switch would become the Root bridge.

Applied globally via:
sw1(config)#spanning-tree uplinkfast

3) BackboneFast - Enabled on ALL switches in the topology, allows for fast convergence to the network backbone or core after an STP topology change. It shortens the STP convergence times by actively determining whether an alternate path exist to the Root bridge when a link goes down. It uses Root Link Query (RLQ) protocol to detect if the upstream switches have a connection to the Root bridge.

BackboneFast shortens the Max-age timer which in turn can reduce convergence times from 50 secs to approx 30 secs.

Applied on All switches in the topolgy using:
sw2(config)# spanning-tree backbonefast

Verify using;
sw2#sh spanning-trree backbonefast

CCNP - ENTERPRISE - Inter-VLAN routing notes

- The Forward Information Base will be updated when:
i) An ARP entry for a dest next hp changes, or is removed
ii) The RT entry for the next hop changes
iii) The RT entry for a prefix changes

CCNP - ENTERPRISE - Spanning-tree Protocol notes

- Once a root bridge is elected, Configuration BPDU's are sent only by the Root Bridge. All the other switches must forward the BPDU's (or relay them) adding their own send Bridge ID to the Message.

- On a config output if you see 'Spanning tree enabled protocol ieee' it indicates ieee 802.1d (Common SPanning-Tree) is in use REGARDLESS of the ROLES listed.
- Enable Loop Guard on root ports and alternate ports
- If a BPDU is received on a Loop Guard port that is in an inconsistant state the port will transition to the appropriate state as determined by the normal function of the spanning tree verion/type in place
- Root Guard is enabled on a per-port basis, it re-enables a switch port once it stops receiving superior BPDU's
- When you have a link that is configured as Half-duplex on one end and Full on the other the following situations could arise:
 i) The switch with the Full Duplex setting could unblock it's port potentially creating a loop
 ii) The switch with the Full Duplex port will not be performing CSMA/CD
 iii) BPDU's amy not successfully negotiate port states on the link between the two switches.
- A switch running 802.1d (cst) will use the Forward delay timer to age out entries in the MAC address table when a tology change is received.
- MST extends 802.1w to multiple spanning trees.

CCNP - ENTERPRISE - VLANs notes

- When configuring a Trunk link, be sure to configure the same native VLAN at the each end. If you leave a trunk with default settings, VLAN 1 will be used by default.
  If you see the cmd #switchport trunk natvie vlan [id] on one end and not on the other you will get a mismatch error
- On an ISL enabled trunk if it received an unencapsulated frame it will be dropped.

CCNP - ENTERPRISE - Implementing IP Switching notes

- GAP analysis should be conducted at the Plan phase of the Lifecycle Services approach
- NAT can consistantly increase the load on a CPU on a MLS switch.
- TTL decrementing and rewrite of Src and Dest MAC Addresses do not occur on a L2 switch
- L3 switching provides the ability to circumvent CPU processing

CCNP - ENTERPRISE - Preparing the Campus for Advanced Services notes

- With regards to Multicast, IGMP snooping is enabled by default on catalyst switches
- When traffic from a multicast source is received on a port that it not expected the router will drop the packets.
- 224.0.1.1 is reserved for Network Time Protocol
- You might implement Voice services on a network to reduce costs and increase productivity.

CCNP - ENTERPRISE - Port Security notes

- An attacker would launch an MAC Flood Attack to capture data from the network and to initiate a DoS attack.
- use the cmd #sh monitor session 1 detail to observe whether data is being sent in association with that session.

CCNP - ENTERPRISE - First Hop Redundancy notes

- A standby router configured with HSRP will take 9 seconds to detect the loss of an active router (based on default timers)
- With GLBP there is no limit to the number of routers you can implement in a group, however only a maximum of 4 active routers will be forwarding at any given time (due to a limit of 4 virtual MAC addresses that can be used with a group).
- Default GLBP priority is 100, when a router is the Active Virtual Gateway or an Active Virtual forwarder either the priority has been increased from the default on the AVG OR the Priority has been reduced from the default on the AVF

CCNP - ENTERPRISE - Inter-vlan Routing Notes

- Router interfaces on a Router-on-a-stick setup are configured as L3 subinterfaces

- Reasons you wouldn't need to implement an SVI;
i) Provide failover for a failed primary SVI
ii) Provide connectivity to an external router for inter-vlan routing

- The cmd 'Autostate Exclude' could be implemented on a port that is used for monitoring and is connected to an IDS

- A Glean adjacency is when a MLS connects directly to several hosts and the FIB table maintains a prefix for the subnet rather than individual host prefixes

- If you get 'incomplete' or 'drop' adjacencies check the switch hasn't been configured with unsupported software features.