Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

reserve a seat

Using MPLS VPN books to study for the CCIP exam

Every now and then I'm getting questions from my readers regarding the suitability of my MPLS books for the CCIP exam, for example:

I'm pursuing my CCIP and have a hard time finding the right MPLS study guide. I know you have the CCIP edition that was written in 2002, but I think the exam topics have changed. Can you recommend what book or books are best for the CCIP MPLS exam?
Are MPLS VPN Architectures Volume 1 & 2 two completely separate books or is Volume 2 a newer release. I was thinking of going for the CCIP and wanted to know if I should get both books or just the more recent one.

Here is the full story: MPLS and VPN Architectures Volume I and II are completely separate books with only slight overlap. Volume I was written when MPLS and MPLS VPNs were an emerging technology, thus the coverage of some solutions (like Carrier's Carrier architecture) was scarce (as they were mostly on the drawing board at that time). We've later released CCIP edition of Volume I, which includes a few bug fixes and two chapters on troubleshooting to match the requirements of the early version of Cisco's MPLS course.

The Volume II covers advanced MPLS topics, including remote access, inter-AS MPLS VPN, Carrier's carrier architecture, IP Multicast in MPLS VPN etc. It also contains the MPLS and MPLS VPN troubleshooting information (similar to the CCIP edition of Volume I). Reading Volume II without having sound foundations from Volume I does not make sense.

The current MPLS course that's part of the CCIP curriculum has been significantly redesigned from the original one (primarily shifting the focus from baseline MPLS + MPLS VPN to “a bit about everything MPLS has become”), but at the moment Cisco Press has no plans to release another CCIP edition book to cover the changes. The new course (Implementing Cisco MPLS 2.2) has dropped any ATM-specific information (finally) and includes a chapter on MPLS TE. While Cisco's web site claims MPLS TE is included, it's not listed in their Course Outline section. The information on our web is more accurate, as we build the course outline from student materials, not from supplementary documents.

I would definitely recommend CCIP edition of Volume I (you can still get it as an on-line book) as the basis of your learning efforts, with a few topics from Volume II (EIGRP as PE-CE routing protocol, more in-depth troubleshooting information) also being applicable. MPLS TE is not covered in any of my books, but as Peter Dob suggested, you can get enough information from the MPLS Fundamentals book.

Add comment

OSPF default route: design scenarios

In his comment, Maher has asked an interesting question:
“Which one is better: default-information originate or default-information originate always?”

As always, the answer is it depends. If your OSPF edge routers have external default routes (for example, static default routes toward the Internet, see the next diagram), you'd want them to announce the default route only when they have a default themselves (otherwise they would attract the traffic and then blackhole it). In this case, you'd use default-information originate.

If you use something else than OSPF as the core routing protocol of your network (as shown in the next diagram), then you'd want the core routers to announce the default route into OSPF to attract the traffic from the edges regardless of whether they have the default route themselves or not. In this scenario, you'd use default-information originate always.

BGP is almost always the core routing protocol of Service Provider networks. You can also use it to make a large enterprise network scalable.

Last but not least, in OSPF+BGP scenario, you might want a core router to announce a default route only if it has at least some non-OSPF routes (to prevent an isolated core router from attracting and blackholing the traffic). The command to use is default-information originate always route-map name, which would generate a default route into OSPF only if at least one prefix from the IP routing table matches the specified route map.

This article is part of You've asked for it series.

see 3 comments

Inserting default route into OSPF

This should be a well-known fact (and it's obliquely described in IOS documentation) - if you're redistributing a default route into OSPF (for example, you have a static default route configured with ip route 0.0.0.0 0.0.0.0 ... and you use redistribute static subnets within the OSPF process), the default route will not be entered into the OSPF database unless you configure default-information originate within the router ospf configuration.

Similarly, if you configure default-information originate always, the router will inject the type 5 LSA for the default route into the OSPF topology database even if the router itself does not have a default route (or gateway of last resort).
see 7 comments

Display per-process memory usage

Similar to the show processes cpu sorted command, the show processes memory sorted printout displays the top memory consumers (see example below).
router#show processes memory sorted

Total: 13734272, Used: 6372068, Free: 7362204

PID TTY Allocated Freed Holding Getbufs Retbufs Process

0 0 135340 1864 4734916 0 0 *Init*

55 0 242388 188 249076 0 0 URL filter proc

69 0 317996 143308 182184 0 0 IPSEC key engine

62 2 277048 124752 165172 0 0 Virtual Exec

68 0 762828 657056 109896 0 0 Crypto IKMP

80 0 74556 1100 73772 0 0 CEF process

91 0 25704 188 28776 0 0 NTP

67 0 3116 51368 27904 0 0 Crypto ACL

83 0 184 0 25060 0 0 traffic_shape

30 0 89900 0 24700 0 0 IP Input

46 0 32248 1776 23596 0 0 DHCPD Receive

35 0 10236 540 16572 0 0 PPPOE discovery

48 0 95344 51488 14724 0 0 HTTP CORE
Usually the top entry is the *Init* process, which allocates all shared buffers, but routing processes could also exhibit significant memory utilization in large networks.
see 3 comments

The “show ip interface” command I've always wanted to have

Recently I was investigating MTU-related problems and got mightily upset when I had to search for the interface IP MTU size in the long printout produced by the show ip interface command. Obviously I could display the IP MTU size of a single interface with the show ip interface name | include MTU filter, but I wanted to have a nice tabular printout. Obviously it was time for another Tcl script.

To use it, download it and store it into the flash memory of your router. Configure alias exec ipconfig tclsh flash:ipInterfaces.tcl and you can use ipconfig or ipconfig active to display interface IP addresses.Included below are sample printouts:
ro#ifconfig
Interface IP Address Mask MTU State
=================================================================
FastEthernet0/0 172.18.25.1 255.255.255.0 1500 up
FastEthernet0/1 no address admin down
Serial0/0/0 no address up
Serial0/0/0.101 192.168.201.2 255.255.255.252 1500 up
Serial0/1/0 no address up/down
Serial0/1/1 no address down
Tunnel0 FastEthernet0/0 1476 up

ro#ifconfig active
Interface IP Address Mask MTU State
=================================================================
FastEthernet0/0 172.18.25.1 255.255.255.0 1500 up
Serial0/0/0.101 192.168.201.2 255.255.255.252 1500 up
Tunnel0 FastEthernet0/0 1476 up
see 5 comments

Get hands-on IPv6 experience

In one of his recent articles, Scott Morris provided an excellent summary why IPv6 is still on the horizon. The point I like most (as it's often forgotten by the techies) is this:

“After all of the pieces (network, applications, OS, etc.) are done, do you have enough people with enough knowledge to manage and design things? Now may be a good time for some training!”

Cisco has already included IPv6 in its mainstream BSCI course (so IPv6 is now officially part of CCNP certification). Apart from visiting the BSCI classroom course, you also have a few other options to get your hands on IPv6 training material:

Add comment

MPLS ping and traceroute

One of the hardest troubleshooting problems within an MPLS VPN network has always been finding a broken LSP. While you could (in theory) use the IP ping or traceroute (assuming all hops support ICMP extensions for MPLS), the results are not always reliable ... and interpreting them is not so easy. For example, after I've disabled LDP on an interface with the no mpls ip configuration command, the routers in the LSP path still reported outgoing MPLS labels in ICMP replies for a few seconds (until the LDP holddown timer expired on both ends of the link). As a side note, would you deduce from the printout that the break in the LSP path happened on the router with the IP address 192.168.201.1?
ro#trace ip 1.0.0.1
Tracing the route to 1.0.0.1

1 192.168.201.1 [MPLS: Label 22 Exp 0] 204 msec 200 msec 212 msec
2 192.168.201.6 [MPLS: Label 16 Exp 0] 112 msec 112 msec 116 msec
3 192.168.0.6 56 msec * 60 msec
ro#trace ip 1.0.0.1
Tracing the route to 1.0.0.1

1 192.168.201.1 [MPLS: Label 22 Exp 0] 56 msec 60 msec 56 msec
2 192.168.201.6 56 msec 56 msec 56 msec
3 192.168.0.6 56 msec * 56 msec
The MPLS ping and traceroute commands, introduced in IOS release 12.0(27)S and integrated in mainstream IOS release 12.4(6)T (at least five years too late in my humble opinion) address this problem: they both use IP packets that are not capable of being IP-switched and thus report the exact failure spot.In our scenario, MPLS ping and traceroute correctly identified the problem (unlabeled output interface) and the MPLS traceroute also provides the correct IP address of the offending router.
ro#ping mpls ip 1.0.0.1 255.255.255.255
Sending 5, 100-byte MPLS Echos to 1.0.0.1/32,
timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
BBBBB
Success rate is 0 percent (0/5)
ro#trace mpls ip 1.0.0.1 255.255.255.255
Tracing MPLS Label Switched Path to 1.0.0.1/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
0 192.168.201.2 MRU 1500 [Labels: 22 Exp: 0]
B 1 192.168.201.1 MRU 1504 [No Label] 64 ms
After the problem has been fixed, both commands report successful tests:
ro#trace mpls ip 1.0.0.1 255.255.255.255
Tracing MPLS Label Switched Path to 1.0.0.1/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
0 192.168.201.2 MRU 1500 [Labels: 22 Exp: 0]
I 1 192.168.201.1 MRU 1500 [Labels: 16 Exp: 0] 68 ms
I 2 192.168.201.6 MRU 1504 [Labels: implicit-null Exp: 0] 140 ms
! 3 192.168.0.6 112 ms
ro#ping mpls ip 1.0.0.1 255.255.255.255
Sending 5, 100-byte MPLS Echos to 1.0.0.1/32,
timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/103/104 ms
see 3 comments

Closed versus Filtered ports

Due to the way Cisco routers behave when dropping packets with an inbound access list, whenever you use access lists to protect the router from the outside attacks (or port scans), the protected ports (even though they're not active on the router) will appear filtered (some scanners might use the term stealth), which is almost an invitation to a determined hacker.

Sometimes (it depends on the application you're protecting) you can configure application-layer protection in Cisco IOS. For example, you can protect HTTP server with ip http access-class global configuration command or the Telnet server with the access-class in line configuration command (and BGP will not accept incoming TCP SYN packets unless you've configured a BGP neighbor). The access-class configuration causes the incoming request to be rejected within application (in control plane after the TCP stack), resulting in TCP RST packet being sent back. The port scanner thus reports the protected TCP port as closed.
Add comment

ARP timeout resolution is implemented in minutes

Under some circumstances, you might want to tune the ARP timers on the router (for example, when using ARP as a keepalive mechanism to detect whether the host is up). Unfortunately, although you can set the per-interface arp timeout in seconds, the actual timer resolution is in minutes. For example, if you set the ARP timeout to 10 seconds, the router will age the ARP entries once per minute.Here's a sample debugging output produced on a router running IOS release 12.4(9)T with the arp timeout 10 interface configuration command. As you can see from the timestamps, the ARP entry is aged and refreshed exactly once per minute.
Jun 7 16:34:49: IP ARP: sent req src 192.168.0.1 0016.c7fe.f150, dst 192.168.0.2 000c.293a.b455 FastEthernet0/0.100
Jun 7 16:34:49: IP ARP: rcvd rep src 192.168.0.2 000c.293a.b455, dst 192.168.0.1 FastEthernet0/0.100
Jun 7 16:34:49: IP ARP: creating entry for IP address: 192.168.0.2, hw: 000c.293a.b455
Jun 7 16:35:49: IP ARP: sent req src 192.168.0.1 0016.c7fe.f150, dst 192.168.0.2 000c.293a.b455 FastEthernet0/0.100
Jun 7 16:35:49: IP ARP: rcvd rep src 192.168.0.2 000c.293a.b455, dst 192.168.0.1 FastEthernet0/0.100
Jun 7 16:35:49: IP ARP: creating entry for IP address: 192.168.0.2, hw: 000c.293a.b455
Jun 7 16:36:49: IP ARP: sent req src 192.168.0.1 0016.c7fe.f150, dst 192.168.0.2 000c.293a.b455 FastEthernet0/0.100
Jun 7 16:36:49: IP ARP: rcvd rep src 192.168.0.2 000c.293a.b455, dst 192.168.0.1 FastEthernet0/0.100
Jun 7 16:36:49: IP ARP: creating entry for IP address: 192.168.0.2, hw: 000c.293a.b455
see 3 comments

Tcl script to display Frame Relay DLCI status

In my IP Corner article, Enhance the IOS User Interface, I've included a short Tcl script that displays the list of all DLCIs on the router in a nice tabular format. If you'd like to have them grouped by interface, you can use this Tcl script. To use it, download it and store it into your router's flash. Define an alias: alias exec dlci tclsh flash:dlci.tcl. Now you can use the new dlci command to display nicely formatted list of DLCI's.Here is a sample printout:
rtr#dlci

Interface Serial0/0/0

DLCI Status Usage Interface
=============================================
100 ACTIVE LOCAL Serial0/0/0.100
200 ACTIVE UNUSED
301 ACTIVE UNUSED
401 ACTIVE UNUSED

Interface Serial0/1/0 (DCE)

DLCI Status Usage Interface
=============================================
213 ACTIVE LOCAL
214 ACTIVE LOCAL
301 INACTIVE SWITCHED

Interface Tunnel0

DLCI Status Usage Interface
=============================================
301 ACTIVE SWITCHED
Add comment

Kill browser ads with Cisco router's DNS server

As you might already know, you can use the /etc/hosts file (or its Windows equivalent) to kill unwanted browser ads - just list all the banner-serving sites in you hosts file and set their IP addresses to 127.0.0.1. In my June IP Corner article, Cisco Router: the Swiss Army Knife of Network Services (section Stop the browser ads and banners), I'm describing how you can do the same thing network-wide with a router acting as a DNS server.

read more Add comment

Port number not shown in access-list log output

When I was testing the inspection of router-generated traffic, I wanted to block and log all incoming traffic (apart from inspect-generated conduits, obviously) with a simple access-list:
access-list 102 deny ip any any log
Unfortunately, the port numbers in the logging printout were always zero:
%SEC-6-IPACCESSLOGP: list 102 denied udp 10.0.0.1(0) -> 192.168.1.3(0), 1 packet
The reason for this behavior is very simple: unless a line in the IP ACL matches on the layer-4 port numbers, the router does not inspect them; the log action thus has no port number to show in the syslog printout.

To fix the printout, you have to force the router to inspect the layer-4 port numbers. If you still want to block-and-log all traffic, the minimum access-list achieving this goal is the following:
access-list 102 deny   udp any gt 0 any gt 0 log
access-list 102 deny tcp any gt 0 any gt 0 log
access-list 102 deny ip any any
see 4 comments

ARP entries are periodically refreshed if you use CEF switching

In a previous post I've been writing about the inability to clean the ARP cache due to cached CEF adjacencies. As it turns out, this behavior has another side effect: the router will automatically refresh all ARP entries (and CEF adjacencies) as they expire from the ARP cache. This might become a problem on high-end devices with a lot of directly connected hosts if you set the arp timeout to a low value.

read more see 2 comments

Router's responses to port scans

Recently I was trying to figure out what the various port states reported by Nmap really mean. This is what's actually going on:
  • If a packet is intercepted by a router's access-list, the router sends back an ICMP administratively prohibited packet. This is reported as filtered port by Nmap (and probably as stealth port by some other scanners).
  • If you do a TCP SYN scan of a router and the scanned port is not active, the router sends back TCP RST packet. This is reported as closed port.
  • If you perform a UDP scan of a router, the router sends back ICMP port unreachable message if the UDP application is not active. This is reported by Nmap as filtered port (even though in most cases it should be equivalent to closed TCP port).
  • In some cases, the router simply doesn't reply to UDP scans (for example, if you scan the discard service). This is reported as Open¦Filtered (as the scanner cannot reliably determine whether the probe was dropped due to a filter or simply not replied to).

Note: In any case, UDP scans are way more unreliable than TCP scans due to connectionless nature of UDP.

Below you'll find the debugging outputs for the most common conditions:

Successful TCP scan

Debugged with debug ip tcp packet
tcp0: I LISTEN 172.16.10.34:49620 172.16.0.1:80 seq 2116160324
OPTS 4 SYN WIN 1024
tcp0: O SYNRCVD 172.16.10.34:49620 172.16.0.1:80 seq 3992162774
OPTS 4 ACK 2116160325 SYN WIN 4128
tcp0: I SYNRCVD 172.16.10.34:49620 172.16.0.1:80 seq 2116160325
RST WIN 0

TCP scan of a closed port

Debugged with debug ip tcp packet
tcp0: I LISTEN 172.16.10.34:50434 172.16.0.1:80 seq 1431055709
OPTS 4 SYN WIN 1024
TCP: sent RST to 172.16.10.34:50434 from 172.16.0.1:80

TCP scan blocked by an access-list

Debugged with debug ip icmp
ICMP: dst (172.16.0.1) administratively prohibited unreachable sent to 172.16.10.34

UDP scan of an unreachable port

Debugged with debug ip udp and debug ip icmp
UDP: rcvd src=172.16.10.34(37312), dst=172.16.0.1(8), length=8
ICMP: dst (172.16.0.1) port unreachable sent to 172.16.10.34
see 1 comments

Re-enable debugging on router reload

It's a bit embarrassing: I've posted a hint on how to execute commands after a router reload and Aamer figured out something I've wanted to have for years: the ability to automatically start debugging after the router reload.For example, to enable debugging of incoming SSH connections, use the following EEM applet:
event manager applet EnableDebugging
event syslog occurs 1 pattern "%SYS-5-RESTART"
action 1.0 cli command "enable"
action 2.0 cli command "debug ip ssh"
see 1 comments

Default interface configuration command

The easiest way to remove all settings from an interface is to use the default interface configuration command. For example, if you've configured Frame Relay interface with subinterfaces ...
interface Serial0/0/0
no ip address
encapsulation frame-relay
load-interval 60
!
interface Serial0/0/0.100 point-to-point
bandwidth 2000
ip address 172.16.1.1 255.255.255.252
ip load-sharing per-packet
ip ospf cost 50
frame-relay interface-dlci 100
... and have erase all interface-specific configuration, the ...

rtr(config)#default interface serial 0/0/0
Building configuration...

Interface Serial0/0/0 set to default configuration
... gets you there. As you can see, after the configuration change, the main interface has no IP address and the subinterface is deleted.
a1#show ip interfaces brief
Interface IP-Address OK? Method Status Protocol

... non-relevant lines deleted ...

Serial0/0/0 unassigned YES TFTP up up
Serial0/0/0.100 unassigned YES manual deleted down
see 13 comments

Inspect router-generated traffic

A while ago a reader has asked me whether you could modify an IP access-list when the interface IP address changes. While that's definitely doable with Tcl and Embedded Event Manager, it's not a trivial task, so I've tried to understand why he would need such a functionality.

The answer was quite interesting: he's running NTP on his firewall router and thus needs to accept incoming NTP responses from an external NTP server. While that could be easily achieved with the following configuration (only the relevant bits-and-pieces are shown), he didn't want to make the access-list too generic (allowing NTP from the external server to any IP address).
ip inspect name DEFAULT100 tcp
ip inspect name DEFAULT100 udp
!
interface Dialer0
description $FW_OUTSIDE$
ip access-group 102 in
ip inspect DEFAULT100 out
!
access-list 102 remark #### Dialer0 incoming ####
access-list 102 remark #### non-relevant lines deleted
access-list 102 permit udp host 1.2.3.4 eq ntp any eq ntp
This problem nicely illustrates a broader issues: the router does not inspect it's own traffic and thus does not prepare conduits for the return packets; you have to specify all the return traffic you're expecting in the incoming access list. This drawback has been fixed in IOS release 12.3(14)T with the introduction of the Inspection of Router-Generated Traffic feature. In our scenario you only need to change the inspect rules:
ip inspect name DEFAULT100 tcp router-traffic
ip inspect name DEFAULT100 udp router-traffic
... and the router synchronizes to an external NTP server:
sp#show ip inspect sessions
Established Sessions
Session 474032B4 (192.168.1.3:123)=>(10.0.0.1:123) udp SIS_OPEN
sp#
01:04:34: %NTP-5-PEERSYNC: NTP synced to peer 10.0.0.1
01:04:34: %NTP-6-PEERREACH: Peer 10.0.0.1 is reachable
Note: This article is part of You've asked for it series.
see 3 comments

DHCP response sets the default route

It makes perfect sense in hindsight, but I was nonetheless pleasantly surprised: when the router acting as a DHCP client (configured with the ip address dhcp interface configuration command) receives the DHCP reply packet containing the default gateway option (option #3), it installs a static default route toward that next-hop. Even better, the default route is installed with the administrative distance 254 (floating static route), making sure that the default route you've configured manually or the default route received via a routing protocol are not overwritten.

read more see 4 comments

Fix the IOS quiet mode for the IOS HTTP(S) server

The IOS documentation claims that the quiet mode the router enters after a series of login failures blocks all telnet (or ssh) sessions as well as HTTP requests. Unfortunately the latter is wrong; you can execute any HTTP request on the router during the quiet mode.

If you want to block HTTP requests during the quiet mode, you can use EEM applets to change the HTTP server configuration when the quiet mode is started and completed.
First you need to configure a standard numbered IP access list that will be used to block HTTP requests during the quiet mode (the ip http access-class command accepts only numbered ACLs), for example:
access-list 95 deny any log
Then you define two EEM applets: one that triggers when the router enters the quiet mode (matching the SEC_LOGIN-1-QUIET_MODE_ON syslog message) and another that runs when the quiet mode is finished (triggered with the SEC_LOGIN-5-QUIET_MODE_OFF). Both applets modify the router configuration, changing the access-list used in ip http access-class configuration command.
event manager applet EnterQuietMode
event syslog occurs 1 pattern "SEC_LOGIN-1-QUIET_MODE_ON" period 1
action 1.0 cli command "configure terminal"
action 1.1 cli command "ip http access-class 95"
action 2.0 syslog msg "Entered Quiet mode on HTTP server"
!
event manager applet ExitQuietMode
event syslog occurs 1 pattern "SEC_LOGIN-5-QUIET_MODE_OFF" period 1
action 1.0 cli command "configure terminal"
action 1.1 cli command "ip http access-class 70"
action 2.0 syslog msg "Exiting Quiet mode on HTTP server"
A sample logging printout is illustrating the operation of this solution is included below:
%SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 38 secs, [user: a] [Source: 10.0.0.2] [localport: 80] [Reason: Login Authentication Failed - BadPassword] [ACL: sl_def_acl] at 11:35:04 UTC Thu May 3 2007
%HA_EM-6-LOG: EnterQuietMode: Entered Quiet mode on HTTP server
%SYS-5-CONFIG_I: Configured from console by vty0
%SEC-6-IPACCESSLOGNP: list 95 denied 0 0.0.0.0 -> 10.0.0.2, 1 packet
%SEC_LOGIN-5-QUIET_MODE_OFF: Quiet Mode is OFF, because block period timed out at 11:36:34 UTC Thu May 3 2007
%HA_EM-6-LOG: ExitQuietMode: Exiting Quiet mode on HTTP server
%SYS-5-CONFIG_I: Configured from console by vty0
Note: the SYS-5-CONFIG_I messages are generated when the EEM applets modify router configuration.
Add comment

No more TTY-style look

I've been considering adding the Digg-it button to my blog for a while, but never found time to do it properly ... until a rainy quiet Saturday morning when I've stumbled across a great how-to article. Excellent tip, but the digg-it text was displayed on white background which clashed horrendously with the dark-blue surroundings. So I finally gave up on using white text on dark background (which I sort-of fancy as I've started on old Digital VT100 terminals), hopefully also making the blog easier to read.
see 1 comments

IP Corner article: Using DNS server on Cisco router

The regular readers of my blog might have wondered in the last few days why I'm focusing so much on the Cisco IOS embedded DNS server. The answer is very simple: I was doing research for my June IP Corner article, Cisco Router: the Swiss Army Knife of Network Services, where you'll find in-depth explanation of what Cisco IOS DNS server can and cannot do, as well as several usage scenarios (including a tip on how to stop unwanted browser ads).
see 4 comments
Sidebar