Category:  IP routing

uRPF Violation Logging Is Not Working on 12.4T

One of the scenarios I’m discussing in the DMVPN webinar is redundant DMVPN network with two ISPs. It’s not a particularly complex setup, unless the ISPs decide to deploy anti-spoofing filters (more precisely: unicast RPF checks) in which case it becomes crucially important which outbound interface you use for your DMVPN tunnel.

Anyhow, I was trying to make the whole thing work in a lab and it was repeatedly failing, so I decided to log uRPF violations. According to the documentation, it’s a piece of cake:

read more add comment

BFD Has Reached RFC Status

Bidirectional Forwarding Detection (BFD) protocol has finally been published as a series of RFCs. BFD gives you quick failure detection between L3 hops (routers) regardless of the underlying technology and equipment (modems, media converters, bridges). It’s been gradually introduced in Cisco IOS during the last few years; release 15.0M and 12.2SRE contain almost everything you’ll ever need (missing: multihop BGP support and MPLS LSP support).

I wrote about BFD in Improve the Convergence of Mission-Critical Networks with Bidirectional Forwarding Detection (BFD) article (you’ll find it somewhere in this list). To learn more, read the RFCs in this order:

read more add comment

Fast static route convergence

A few days ago I’ve received a cryptic e-mail with exactly this content: “I am having a issue "static routes not flushed when next hop is unreachable" please advice.” I suspected that the sender actually wanted to ask me what to do if a static route pointing to an IP next-hop does not disappear when the next hop becomes unreachable and told him to adjust the ip route static adjust-time parameter while monitoring the CPU usage.

read more see 7 comments

ICMP extensions RFC

Recently-published RFC 5837 describes additions to ICMP messages that would allow you to gather more information (including interface ifIndex, IP address and name). Two obvious applications are enhanced traceroute and path MTU discovery where the new ICMP extensions could indicate which interface is the MTU bottleneck.

The RFC authors come from BT, Juniper and Cisco, so there’s a non-zero chance it will actually get implemented where it’s most needed.

see 2 comments

L2TP default routing: solutions

There are three tools that can (according to a CCIE friend of mine) solve any networking-related problems: GRE tunnels, PBR and VRFs. The solutions to the L2TP default routing challenge nicely prove this hypothesis; most of them use at least one of those tools.

Policy-based routing on virtual template interface. Use the default route toward the Internet and configure PBR with set default next-hop on the virtual template interface. The PBR is inherited by all virtual access interfaces, ensuring that the traffic from remote sites always passes the network core (and the firewall, if needed).

read more add comment

Small Steps to Large Complexity

Imagine you have a large retail network: your remote offices use ISDN to dial into the central site and upload/download whatever periodic reports they have. Having a core router connected to an ISDN PRI interface is the perfect solution:

A few years later, ISDN is becoming too slow for your increased traffic needs and you want to replace it with DSL or VPN-over-Internet solution. Your Service Provider offers you PPPoE forwarding with L2TP. This is a perfect solution as it allows you to minimize the changes:

read more see 8 comments

IP Multicast is like Banyan Vines

Every now and then I stumble upon an elegy lamenting the need to study IP Multicast to pass one or the other certification exam. The history obviously repeats itself; we’ve been dealing with similar problems in the past and one of my favorite examples is Banyan VINES.

If you’ve been working with Cisco routers for more than 15 years, you might still have fond memories of Router Software Configuration (RSC) course, at its time one of the best networking courses. In those prehistoric days, the networks were multi-protocol, running all sorts of things in parallel with IPv4. The week-long RSC course thus covered (at least) the following protocols: IPv4, AppleTalk, Novell IPX, DecNET, XNS, Banyan VINES, CLNP and SNA (I probably forgot one or two). By the third day, everyone (including the instructor) was sick-and-tired of the endless stream of lookalike protocols and ready to skip a section or two.

read more see 9 comments

My Stupid Moments: Interface Default Route

Years ago I was faced with an interesting challenge: an Internet customer was connected to our PE router with an Ethernet link and I did not want to include the PE router’s IP address in the default route on the CE router.

The latest IOS release in those days was probably somewhere around 11.x; none of the DHCP goodies were available.

After pondering the problem for a while, I got a “brilliant” idea: if I would use an interface default route, proxy-ARP would solve all my problems. This is the configuration I’ve deployed on the CE-router:

read more see 20 comments

The tunneling Kool-Aid

My friend Ronald sent me this comment:

I don't drink this Cisco Kool Aid about interconnecting data centres using an IP backbone. Rather use FC directly over DWDM instead of FCIP on MPLS.

This time I could agree with him wholeheartedly ... assuming you already have DWDM gear (or infinite budget to buy some) and you can get dark fiber when and where you need it. Unfortunately not everyone is so lucky and/or rich, so we have to compromise.

read more see 7 comments

Followup: VLAN interface status

Thanks to my readers, I often learn something completely new about the intricacies of Cisco IOS. The “VLAN Interface Status post resulted in a comment about the SVI autostate concept, which is (not surprisingly) a somewhat muddy topic:

  • In most cases, the SVI interface tracks the state of access and trunk ports using the VLAN. The details are well explained in the Understanding SVI Autostate section of the Cisco IOS documentation.

The important part of the SVI autostate calculation is the “port is in STP forwarding state for the VLAN” requirement. If a VLAN is not carried in a trunk port (for example, due to switchport trunk allowed configuration command), the trunk port’s status does not influence the autostate.

  • In some IOS releases, you can exclude the individual physical ports from the autostate calculation with the switchport autostate exclude interface configuration command. Most commonly you’d want to exclude uplink ports on access switches.
  • In some unspecified IOS releases (including 12.4T), you can use the (currently undocumented according to Command Lookup Tool) no autostate VLAN interface configuration command, which disables the autostate algorithm and makes the SVI interface permanently active.
see 5 comments

Quick tip: VLAN interface status

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.

A VLAN interface is always up, but its line protocol state tracks the state of attached ports: if at least one port is operational, the line protocol of the VLAN interface is up, otherwise it’s down. With no ports assigned to a VLAN, the line protocol of the VLAN interface is down, its IP address is not in the IP routing table and thus you cannot ping it.

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

see 18 comments

Quick tip: Matching default route in a standard ACL

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.

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

see 4 comments

Multihomed IP Hosts

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.

A host having a routable IP address on an external interface and on or more IP addresses on internal interfaces like the loopback interface is not considered multihomed.
read more see 5 comments

Small Site Multihoming Tutorial

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.

read more see 1 comments
Sidebar