Blog Posts in July 2007
After I've published the Tcl script that displays the interface IP parameters in a formatted table, cos quickly pointed out a bug: I've expected the IP addresses in the address mask format. In the meantime, I've figured out the root cause of the problem (our remote labs are set to display IP masks in decimal format for compatibility reasons) and fixed the Tcl script. It temporarily sets the terminal ip netmask-format to bit-count before executing the show command. The new script recognizes three parameters:
- active: display only interfaces that are up/up;
- configured: display only interfaces with configured IP addresses (unnumbered interfaces using IP address of an interface without one count as configured since IOS reports their IP address as 0.0.0.0).
- address: displays IP address of the unnumbered interface, not the interface that it's borrowing the address from.
And the funniest part of the whole story is that I was utterly impressed with the feature when it was introduced ... and now almost started to reinvent the wheel and implement the same functionality in Tcl
Following my post about the relationship between the MPLS and VPN architectures books and CCIP MPLS exam, Peter Dob had an excellent idea: combine the MPLS and VPN architectures (Volume I, CCIP edition would be even better) with the MPLS fundamentals from Luc de Ghein. By reading Luc's book, you'll also get exposure to other MPLS-related topics (for example, AToM) on top of MPLS TE overview that you need for the exam.
Once you start thinking about what's really going on, it all becomes obvious: as the router has no IP address when it sends the DHCP request, and it sends the DHCP request to a broadcast address (as it doesn't know the IP address of the upstream DHCP server), there is no session that could be entered into the CBAC session table. So you still have to allow all DHCP traffic to your router with an access-list similar to this one:
ip access-list extended Internet
permit udp any eq bootps any eq bootpc
deny ip any any
Note: Replace the highlighted any keyword with the actual DHCP server's IP adress if you have it available and you want to have an even more secure IP access-list.
However, IOS has an interesting feature when you use a router as a DHCP server: you can tell it to ignore the BOOTP requests with the ip dhcp bootp ignore global configuration command (introduced in 12.2T and 12.3). Even more, the router can respond to DHCP requests and forward BOOTP requests to a non-local BOOTP server configured with the ip helper-address interface configuration command.
In response to the post detailing router response to port scans, one of my readers asked an interesting question:
“I was wondering if there was a way to prevent the router from sending those TCP RST packets administratively prohibited ICMP messages back to scanners for TCP and UDP respectively. I basically want my router to drop all packets period without replying back in any way, shape, form, or fashion.”
Here's how you do it:
For whatever reason, a lot of people have the impression that the wildcard bits in the OSPF network statement have to be the inverse of the interface subnet mask. For example, if you have configured ip address 192.168.1.2 255.255.255.240 on an interface, they would enter network 192.168.1.2 0.0.0.15 in the OSPF configuration ... and obviously use one network statement per interface.
In reality, the network statements work like simple IP access-list: whenever an interface IP address matches the network statement, the interface is put into the selected area. The IOS is also pretty helpful recently: the network statements are automatically sorted from most-specific to least-specific and (like with the access lists) the first match stops the search.
In my network implementations, I use the network statements in three different ways:
- If I have to assign a specific interface into an area, I would always use network x.y.z.w 0.0.0.0 area n;
- If the area address ranges are nicely assigned (which also helps immensely when you have to start summarizing), you can use a single network statement to cover the whole area. If, for example, area 3 has address range 10.1.16.0/20, use network 10.1.16.0 0.0.15.255 area 3;
- If the router has all interfaces in a single area, I would almost always use network 0.0.0.0 255.255.255.255 area area-id (unless there is an extremely good reason that some interfaces should not be seen by the OSPF process).
Furthermore, if you use any protocols that have separate control and data sessions (for example, FTP, H.323 or SIP), you have to list them before tcp or udp keywords, otherwise their control streams will not be inspected and there will be no provision for data sessions.
ip inspect name Internet ftp
ip inspect name Internet h.323 router-traffic
ip inspect name Internet sip router-traffic
ip inspect name Internet tcp router-traffic
ip inspect name Internet udp router-traffic
ip inspect name Internet icmp router-traffic
ip access-group Internet in
ip inspect Internet out
ip access-list extended Internet
deny ip any any
If the address space assigned to a LAN is at least twice as large as the number of LAN-attached devices, you can use the ip dhcp excluded-addresses command to exclude half of the address pool on each router, for example:
ip dhcp pool LANAlternatively, you can rely on the ip dhcp ping packets command; the router will ping an IP address to check whether it's live before assigning it (by default, the router sends two pings with 500 millisecond timeout).
network 192.168.1.0 192.168.0.0 255.255.255.0
! Exclude router addresses
ip dhcp excluded-addresses 192.168.0.1 192.168.0.10
! Exclude half of the pool
ip dhcp excluded-addresses 192.168.0.128 192.168.0.255
Note: You can also inspect the conflicting IP addresses the router found with the show ip dhcp conflict command.
In IOS release 12.3(11)T (integrated in 12.4), Cisco finally implemented OSPF the way it should have been implemented 20 years ago - you configure the OSPF area on individual interfaces with the ip ospf process area area-id interface configuration command.
The network statements still work as expected and the per-interface command overrides whatever the network statement would do, so you have an extremely nice combination that allows you to assign all interfaces into a particular area (for example, network 0.0.0.0 255.255.255.255 area 2) and change the area for only a few interfaces (for example, uplinks into the backbone area).