If you decide to set old updates or non-required updates to Not Approved

… the updates in the WSUSContent folder will not automatically be cleaned up for you.

The only way to clean up your WSUSContent folder in the fewest amount of steps is to RESET the WSUS server and re-download the content for all approved updates.

How to Do a Reset:

Note: You may want to execute the procedure below during off hours as your WSUS server will be downloading quite a bit of data.

1) Correct any settings above or disapprove any unneeded updates.

2) Close any open WSUS consoles.

3) Go to Administrative Tools – Services and STOP the Update Services service.

4) In Windows Explorer browse to the WSUSContent folder (typically D:WSUSWSUSContent or C:WSUSWSUSContent)

5) Delete ALL the files and folders in the WSUSContent folder.

6) Go to Administrative Tools – Services and START the Update Services service.

7) Open a command prompt and navigate to the folder: C:Program FilesUpdate ServicesTools.

8) Run the command WSUSUtil.exe RESET

-This command tells WSUS to check each update in the database, and verify that the content is present in the WSUSContent folder. As it finds that the content is not present in the folder, it executes a BITS job to download the content from Microsoft. This process takes quite a bit of time and runs in the background.

How do you tell when the process is complete?

Other than noticing that the WSUSContent folder is no longer growing you can also check the SoftwareDistribution.log:

C:Program FilesUpdate ServicesLogFilesSoftwareDistribution.log

When you start the reset process, you should see a line towards the bottom of the log which looks like this:

WsusService.13  ExecutionContext.runTryCode     State Machine Reset Agent Starting

After waiting for some time, check the log again and search for the text “State Machine Reset Agent Finished”

WsusService.13  ExecutionContext.runTryCode     State Machine Reset Agent Finished


21. July 2012 · Write a comment · Categories: Cisco · Tags: , ,

Anyone who has ever used SecureCRT as their ssh client knows how easy, powerful and convenient it is to use.  However one of the biggest problems with SecureCRT is keeping your saved sessions in sync across multiple desktops, laptops, etc.  If you change jobs, switch between a laptop and desktop, or between a work computer and a home computer you have to copy the config folder or manually recreate every saved session on each computer. It can be a big hassle.

Well today we have a great solution for instantly syncing all of your session information across as many computers as you need and even will sync with any new computers you buy in the future.

The trick to solving this issue is to store your VanDyke config folder in a
Dropbox folder!

What is Dropbox?  Dropbox is a free cloud storage system that allow you to privately store and access any files you want, up to 2 Gig.

So here’s how it works. More »

18. July 2012 · Write a comment · Categories: Cisco · Tags: , , ,

As a CCNA / CCNP candidate you are expected to understand how to set and interpret the OSPF cost function on your Cisco devices

During your career as a Cisco network engineer you will have to deal with setting and manipulating the OSPF costs on an interface.

OSPF uses a metric called “Cost” to calculate the metric of path. The cost is a cumulative value which is an incremental metric.

The cost is as a default based on the bandwidth of the interface. The Higher the interface bandwidth the lower the cost that is associated to that interface, to see the cost that is assigned to any given interface which is participating in OSPF issue the following command:

Router# show ip ospf interface

The output of this command will show the current cost given to this interface. The costs of the interface is calculated by taking the bandwidth of the interface and dividing this number by a value known as the “auto-cost reference-bandwidth”. This auto-cost reference-bandwidth is an integer used to calculate a standard metric across OSPF and is set to 100,000,000. The cost is calculated as follows:

100,000,000/BW More »

18. July 2012 · Write a comment · Categories: Cisco · Tags: , ,

IGRP metric for a path to destination is calculated by the following rather complex mathematical formula:

IGRP Metric for the path =
[K1 * (B) + (K2 * (B))/(256-(Load)) + K3*(D)] * [K5/((Reliability) + K4)]


K1, K2, K3, K4, K5: all are constants. Default values are: K1=K3=1, K2=K4=K5=0
(B) = 10,000,000 / (Smallest bandwidth in kilobits, along the path)
(Load): Outgoing interface load at this router, measured from integer 1 (0%) to 255 (100%)
(D) = Sum of outgoing interface delays along the path, starting from this router, in micro seconds, then divide by 10
(Reliability): Outgoing interface reliability at this router, measured from integer 1 (0%) to 255 (100%)

When we fill K1 to K5 constants with default values into the formula, it becomes very simple:

IGRP Metric for the path = (B) + (D)

Wait, what about EIGRP metric? EIGRP metric is just equal to the calculated IGRP metric value multiplied by 256.

EIGRP Metric for the path = 256 * (IGRP Metric for the path)

Of course, after the router calculates metric values of all candidate paths to the destination, it choose the path with the smallest metric value, to put in its routing table.

OSPF Stub Areas

OSPF stub areas limit the parts of the network where specific LSAs are allowed. The idea being that if an OSPF router receives an LSA it must process it, which takes a certain amount of processor and memory resources. By limiting the types of LSAs that can reach specific networks, the devices within these stub areas do not have to be as powerful but still retain reachability to the rest of the OSPF network.

There are three main types of OSPF stub areas:

  • Stub Areas
  • Totally Stubby Areas
  • Not So Stubby Areas

Stub Areas

An area that is configured as a stub is able to receive all types (as discussed above) of LSA except an LSA Type 5. Any routes that are destined for external networks are forwarded using a default route that is injected into the network in place of the LSA Type 5.

Totally Stubby Areas

Like a stub area, a totally stubby area is unable to receive LSA Type 5 packets. Along with this, the area is also unable to receive LSA Type 3 packets that include network advertisements (Not External) from other areas. Again, like a stub area, all traffic that is destined for these networks (both internal and external networks outside the area) is destined for a default router that is injected in place of both the LSA Type 3 and Type 5.

Not So Stubby Areas (NSSA)

A NSSA is almost exactly the same as a normal stub area but allows an ASBR (Autonomous System Boundary Router) to exist within the area. With a typical stub area, it is not possible to locate an ASBR inside the area as LSA type 5 packets are not allowed. A NSSA gets around this by using an LSA Type 7 packet in place of the LSA Type 5 packet within the NSSA; once this traffic from the ASBR exits the NSSA it is converted to an LSA Type 5 for transmission to the rest of the OSPF network.

18. July 2012 · Write a comment · Categories: Cisco · Tags: , ,

The LSA types defined in OSPF are as follows:

  • Type 1 – Router LSA – the router announces its presence and lists the links to other routers or networks in the same area, together with the metrics to them. Type 1 LSAs are flooded across their own area only. The link-state ID of the type 1 LSA is the originating router ID.
  • Type 2 – Network LSA – the designated router (DR) on a broadcast segment (e.g. Ethernet) lists which routers are joined together by the segment. Type 2 LSAs are flooded across their own area only. The link-state ID of the type 2 LSA is the IP interface address of the DR.
  • Type 3 – Summary LSA – an Area Border Router (ABR) takes information it has learned on one of its attached areas and it can summarize it (but not by default) before sending it out on other areas it is connected to. This summarization helps provide scalability by removing detailed topology information for other areas, because their routing information is summarized into just an address prefix and metric. The summarization process can also be configured to remove a lot of detailed address prefixes and replace them with a single summary prefix, also helping scalability. The link-state ID is the destination network number for type 3 LSAs.
  • Type 4 – ASBR-Summary LSA – this is needed because Type 5 External LSAs are flooded to all areas and the detailed next-hop information may not be available in those other areas. This is solved by an Area Border Router flooding the information for the router (i.e. the Autonomous System Boundary Router) where the type 5 originated. The link-state ID is the router ID of the described ASBR for type 4 LSAs.
  • Type 5 – External LSA – these LSAs contain information imported into OSPF from other routing processes. They are flooded to all areas (except stub areas). For “External Type 1” LSAs routing decisions are made by adding the OSPF metric to get to the ASBR and the external metric from there on, while for “External Type 2” LSAs only the external metric is used. The link-state ID of the type 5 LSA is the external network number.
  • Type 6 – Group Membership LSA(Only supported on a few routers) – this was defined for Multicast extensions to OSPF (MOSPF)[1], a multicast OSPF routing protocol which was not in general use. MOSPF has been deprecated since OSPFv3[2] and is not currently used. It may be reassigned in the future.
  • Type 7 – Routers in a Not-so-stubby-area (NSSA) do not receive external LSAs from Area Border Routers, but are allowed to send external routing information for redistribution. They use type 7 LSAs to tell the ABRs about these external routes, which the Area Border Router then translates to type 5 external LSAs and floods as normal to the rest of the OSPF network.
  • Type 8 – A link-local only LSA for OSPFv3. A Type 8 LSA is used to give information about link-local addresses and a list of IPv6 addresses on the link. In OSPFv2, however, the Type 8 was originally intended to be used as a so-called External-Attributes-LSA for transit autonomous systems where OSPFv2 could replace the internal Border Gateway Protocol (iBGP). In these networks, the BGP destinations would be carried in LSA Type 5 while their BGP attributes would be inserted into LSA Type 8. Most OSPFv2 implementations never supported this feature.
  • Type 9 – a link-local “opaque” LSA (defined by RFC2370) in OSPFv2 and the Intra-Area-Prefix LSA in OSPFv3. It is the OSPFv3 LSA that contains prefixes for stub and transit networks in the link-state ID.
  • Type 10 – an area-local “opaque” LSA as defined by RFC2370. Opaque LSAs contain information which should be flooded by other routers even if the router is not able to understand the extended information itself. Typically type 10 LSAs are used for traffic engineering extensions to OSPF, flooding extra information about links beyond just their metric, such as link bandwidth and color.
  • Type 11 – an AS “opaque” LSA defined by RFC 5250, which is flooded everywhere except stub areas. This is the opaque equivalent of the type 5 external LSA.[3]

The opaque LSAs, types 9, 10, and 11, are designated for upgrades to OSPF for application-specific purposes. For example, OSPF-TE has traffic engineering extensions to be used by RSVP-TE in Multiprotocol Label Switching (MPLS). Opaque LSAs are used to flood link color and bandwidth information. Standard LSDB flooding mechanisms are used for distribution of opaque LSAs. Each of the three types has a different flooding scope.

For all types of LSAs, there are 20-byte LSA headers. One of the fields of the LSA header is the link-state ID.

18. July 2012 · Write a comment · Categories: Cisco · Tags: , ,

IP Helper Setup to pass DHCP requests from local clients to a centralized DHCP server

BOOTP/DHCP Server – Port 67
BOOTP/DHCP Client – Port 68
The traditional role of routers in DHCP has been simply to act as a proxy device, forwarding information between the client and server. Since IOS level 12.0(1)T, Cisco routers also have DHCP server and client features. But the DHCP proxy function is still the most common for routers.
Because the initial DHCP request comes from a client that typically doesn’t have an IP address, it must find the server using a Layer 2 broadcast. So, if the router was not able to function as a proxy for these broadcasts, it would be necessary to put a DHCP server on every network segment.
IP Helper Configuration Example:
Router1#configure terminal 
Router1(config)#interface Ethernet0
Router1(config-if)#ip helper-address
Router1(config-if)#ip helper-address
Note: and is DHCP server IP Address
The DHCP server needs two critical pieces of information before it can allocate an IP address to the client. It must know the subnet that the client is connected to, and it needs the client device’s MAC address. The subnet information is needed to ensure that the address that the server allocates will actually work on client’s network segment. And the MAC address is necessary so that the server can find any information that is unique to this workstation. This is particularly true if you need to ensure that the end device always gets the same IP address every time it connects to the network.
So the DHCP proxy, which is the router itself, must convert the local broadcast from the client to a unicast packet and forward it to the server. This is what the ip helper-address command does.
When the DHCP client sends the DHCP request packet, it doesn’t have an IP address. So it uses the all-zeroes address,, as the IP source address. And it doesn’t know how to reach the DHCP server, so it uses a general broadcast address,, for the destination.
So the router must replace the source address with its own IP address, for the interface that received the request. And it replaces the destination address with the address specified in the ip helper-address command. The client device’s MAC address is included in the payload of the original DHCP request packet, so the router doesn’t need to do anything to ensure that the server receives this information.
The DHCP server now has enough information to assign an address from the correct address pool, since it now knows what the originating subnet was for the DHCP request. The server then sends a unicast response back to the proxy router, which in turn sends the request back to the correct MAC address.
The example shows two ip helper-address commands. You should include one of these commands for each of your DHCP servers. The router will forward the DHCP broadcasts to all of these addresses. Most organizations use at least two DHCP servers because although the utilization is light, the functionality is critical. In the very likely event that the client device receives several responses to a DHCP request, it will usually just select the one it received first.
It is important to note that the ip helper-address command does not just forward DHCP requests. In fact, although you can configure it to forward any UDP broadcast you want, by default it will forward UDP broadcast packets for several different UDP ports to the specified address. In some cases, this unwanted traffic can cause problems on the network or DHCP server.
The show ip interface command includes information about the helper addresses configured on an interface:
Router1#show ip interface Ethernet0
Ethernet0 is up, line protocol is up
Internet address is
 Broadcast address is
 Address determined by setup command
 MTU is 1500 bytes
 Helper addresses are
 Directed broadcast forwarding is disabled
 [removed for brevity]
Limiting the Impact of IP Helper Addresses
The ip helper-address command implicitly enables forwarding several different kinds of UDP broadcasts. You can prevent the router from forwarding the unwanted types of broadcasts with the no ip forward-protocol udp configuration command:
Router1#configure terminal
Router1(config)#no ip forward-protocol udp tftp
Router1(config)#no ip forward-protocol udp nameserver
Router1(config)#no ip forward-protocol udp domain
Router1(config)#no ip forward-protocol udp time
Router1(config)#no ip forward-protocol udp netbios-ns
Router1(config)#no ip forward-protocol udp netbios-dgm
Router1(config)#no ip forward-protocol udp tacacs

18. July 2012 · Write a comment · Categories: Cisco · Tags: , ,

SSH access on Cisco ASA

Firewall#config t
Firewall(config)# enable passwordpassword
Firewall(config)# username test password test123
Firewall(config)# aaa authentication ssh console LOCAL (LOCAL in all caps for LOCAL db)
Firewall(config)# ssh A.B.C.D inside
Firewall(config)# ssh version 2