Blog Posts in June 2007
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’s an interesting OSPF-related question I got::
“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.
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).
router#show processes memory sortedUsually the top entry is the *Init* process, which allocates all shared buffers, but routing processes could also exhibit significant memory utilization in large networks.
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
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.
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?
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.
access-list 102 deny ip any any logUnfortunately, 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 packetThe 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
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.
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.
interface Serial0/0/0... and have erase all interface-specific configuration, the ...
no ip address
interface Serial0/0/0.100 point-to-point
ip address 172.16.1.1 255.255.255.252
ip load-sharing per-packet
ip ospf cost 50
frame-relay interface-dlci 100
... gets you there. As you can see, after the configuration change, the main interface has no IP address and the subinterface is deleted.
rtr(config)#default interface serial 0/0/0
Interface Serial0/0/0 set to default configuration
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
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 tcpThis 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 udp
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 22.214.171.124 eq ntp any eq ntp
ip inspect name DEFAULT100 tcp router-traffic... and the router synchronizes to an external NTP server:
ip inspect name DEFAULT100 udp router-traffic
sp#show ip inspect sessionsNote: This article is part of You've asked for it series.
Session 474032B4 (192.168.1.3:123)=>(10.0.0.1:123) udp SIS_OPEN
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
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.
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 logThen 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"