out

Windows CA template – web server and private key export

Creating a web server certificate request is very easy when using a Windows CA server. There is one disadvantage. The requested certificate is directly stored in the user store (by default) or the local computer store, if specified during the request. The disadvantage is that you cannot export the requested certificate including the private keys. During the request the option to Mark keys as exportable is grayed out.

There is a way to mark the keys as exportable when using a Windows CA server. You need to create a new Web Server Certificate template. You can use the existing Web Server Certificate Template as default and copy the current settings. To do so, you just:

run certtmpl.msc, which will open the Certificate Template snap-in;
click the Web Server certificate template;
choose Action – Duplicate Template;
configure a unique template name;
choose the tab Request Handling;
enable the option Allow private key to be exported;

That is all you need to do. You can now request a new certificate with the newly create certificate template. After the certificate is issued and installed on the user or local computer store, you can export the certificate including the private key.

Telnet Time-Out is killing me….

Aaarrrgggghhh, I hate it when I would like to telnet into a device and enter the wrong IP address. This means, by default, waiting for 30 seconds before being able to correct the IP address and start a new telnet session, because there is no escape sequence.

SW01#telnet 10.100.12.250
Trying 10.100.12.250 …
% Connection timed out; remote host not responding

Luckily there is a command to lessen the time for timing out the connection:

SW01(config)# ip tcp synwait-time <seconds> (Set time to wait on new TCP connections)

Hoera, tcp synwaiting saves the day….

Troubleshooting EIGRP

To troubleshoot EIGRP you should obvious have a grasp understanding of the specific routing protocol. Of course this doesn’t only apply to the EIGRP routing protocol.

Troubleshooting the EIGRP routing protocol on a Cisco devices is mainly about logging the correct information to a syslog server, the buffer or the console and know what the output of several show commands mean.

Neighbor instability on a router has mostly one of the following reasons:

Holding time expired;
Retry limit exceeded;
Manual changes like route filter changes;
Unidirectional links;
Primary / secondary IP address mismatch (EIGRP uses the primary IP address);
Routes get Stuck-in-Active aka SIA (“Active” means recovering from a change in the network, for example flapping links). Routes can get SIA by the following reasons: bad or congested links, query range is “too long”, excessive redundancy, overloaded router, router memory shortage and so one;

Many problems with EIGRP appear when using external routes, like redistributing a routing protocol like OSPF into EIGRP. The most common cause of this problem is the absence of setting the metrics. Important when using the redistribute command is specifying the metrics with the default-metric <metric> or redistribute <protocol> metric <metric> command.

Black Hole Summary Routing is also a common problem when using EIGRP. Black Hole Summary Routing is caused when manual summary routes are configured.

The picture shows a case of Black Hole Routing. Routers A and B summary the different /24 networks as one /16 network to router X. Suddenly the link between router A and router C gets lost. Because we used summarization between router A and router X, router X isn’t aware of the lost link, so router X keeps sending traffic for network 10.1.1.0/24 to router A and router B ((un)equal cost load-balancing). All traffic send to router A would get lost in the process.

A solution to this problem is connecting routers A and B by using a physical link or creating a GRE tunnel between both, if the physical links isn’t possible.

As mentioned before, troubleshooting the routing protocol can be done by using the correct show, logging and debug commands. Important commands for troubleshooting EIGRP are:

show ip eigrp neighbors: for checking neighbors, hold timers, uptime, Smooth Round Trip Timer (SRTT) and Retransmit Time Out (RTO);
show ip eigrp topology active: used for noticing if route is SIA;
show ip eigrp events: check what EIGRP events are going on;
RTR(config-router)#eigrp-log-neighbor-changes;
RTR(config-router)#logging buffered <size>;
debug eigrp packet hello: showing the processing of hello packets;
debug eigrp packet terse: shows all EIGRP packet debugging except hellos;
debug ip eigrp notifications: troubleshooting redistribution by showing what happens between EIGRP and the routing table as routes are redistributed;

Troubleshooting a routing protocol can only be done if you know what the protocol is actually doing. When troubleshooting it is necessary to know the correct way to troubleshoot and start exempting possibilities for the routing problems. Exempting possibilities narrows the scope, which can result in finding the actual problem.