Category: Ip Routing

Vijay sent me this question a while ago:

I have configured a L3 VLAN interface on a Cisco 3750 switch and assigned an IP address to it. I haven't assigned any ports to this VLAN. Why am I not able to ping the IP address of the VLAN interface from the switch itself?

The VLAN interface (like any other interface) has layer-1 and layer-2 state.

The layer-1 state is displayed in the Status column of the show ip interface brief command, the layer-2 state in the Protocol column.

I've got the following question from Matthew: »how would one go about matching the default route for filtering using standard ACLs?«

In all routing protocols but EIGRP (which can carry the »default candidate« flag on any IP prefix), the default route has IP address 0.0.0.0 and subnet mask 0.0.0.0.

To match the default route with a standard ACL, use access-list x permit 0.0.0.0. To match it with an extended ACL (which matches the IP address and the subnet mask portions), you have to use access-list y permit ip host 0.0.0.0 host 0.0.0.0. And finally, to match the default route in a prefix list, use ip prefix-list z permit 0.0.0.0/0.

IP host (workstations, servers or communication equipment) is multihomed if it has more than one IP address. An IP host can be multihomed in numerous ways, using one or more layer-3 interfaces for network connectivity. Some multihoming scenarios are well understood and commonly used, while others (multiple physical layer-3 interfaces in the same IP subnet) could be hard to implement on common operating systems.

In 2007 and 2008, I wrote several articles covering small-site multihoming (a site connected to two ISPs without having its own public address space or running BGP).

Basics

A multihomed site is a customer site connected with (at least) two uplinks to one or more Internet Service Providers (ISP). Traditionally, a multihomed site needs its own provider independent (PI) public IP address space, has to run BGP with the upstream ISP and thus needs its own BGP autonomous system (AS) number.

Chris sent me an interesting question:

How many secondary IPs can you put on a Vlan on a Catalyst switch?

The best way to figure out the answer to this question is to close the browser window pointing to google.com (you won’t find the answer there), generate a test configuration and try to load it into your box.

The control and management planes in a network device run numerous mission-critical processes, including routing protocols and network management services (SNMP, telnet or SSH access to the router, web access to the router), and is thus the most vulnerable part of any network device.

A determined attacker can quickly overload the CPU of any router (or switch) with a targeted denial-of-service attack, either by sending IP packets that are propagated from the switching fabric (or interrupt code on software-only platforms) to the control plane processes or by targeting individual services running on the router. The situation is becoming worse with widespread use of high-speed hardware switching platforms that are connected to an underpowered CPU over a PCI bus; getting enough traffic to a network device to saturate the ASIC-to-CPU connection, or the CPU, is becoming trivial.

BFD is one of those simple ingenious ideas that make you wonder “Why did it take them so long to figure this out?” It’s a UDP-based protocol that replaces dozens of link-level failure-detection mechanisms and routing protocol tweaks with a simple, focused solution: detect hop-by-hop layer-3 failures.

In November 2008 IP corner article I described BFD principles, its configuration on Cisco IOS and give you practical examples how you can use BFD to improve next-hop failure detection. You’ll find the link to the article somewhere in this list.

Whenever I start digging into technical details, I learn something new. A few days ago I’ve stumbled across the term anycast, which is a very interesting way to solve scalability issues:

A while ago I’ve read a post about the potential Internet meltdown by Michael Morris. He provided an amazingly accurate analysis of the facts … and ended with a wrong conclusion. To understand the whole issue, please thoroughly read his text in its entirety before proceeding.

Back? OK. As I said, his analysis was great, but the conclusions were wrong. Regardless of whether we use IPv4 (and advertise smaller and smaller prefixes) or IPv6, the problem is the same: everyone wants to have chunks of non-aggregatable provider-independent public address space (so you can freely move between Service Providers) and everyone advertises these PI prefixes to multiple service providers (because multihoming is so cheap these days). Even networks that are not multihomed today use their own PI address space and private AS numbers to connect to a single ISP, so they could get multi-homed in a second if they feel like it.

Keep in mind: Use private IP addresses, AS numbers and domain names in all technical documentation you're producing (unless, of course, you're describing an actual network). If you're forced to use public addresses or AS numbers (for example, to illustrate how the neighbor remote-private-as command works), you should clearly state that they are imaginary.

You can safely use: