Did you know that you could do server-to-server file transfers with FTP? I didn’t; this little gem (usually known as FXP – File eXchange Protocol) was described by davro and g in comments to the FTP Butterfly Effect post.

If you’re using FXP, please write a comment; although I am well aware why it was extremely useful 25 years ago, I’m wondering how many people are actually using it today.

Do you like the solutions to the L2TP default routing problem? If you do, the ASR 1000 definitely doesn’t share your opinion; so far it’s impossible to configure a working combination of L2TP, IPSec (described in the original post) and PBR or VRFs:

PBR on virtual templates: doesn’t work.

Virtual template interface in a VRF: IPSec termination in a VRF doesn’t work.

L2TP interface in a VRF: This one was closest to working. In some software releases IPSec started, but the L2TP code was not (fully?) VRF-aware, so the LNS-to-LAC packets used global routing table. In other software releases IPSec would not start.

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).

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:

In a comment to my “Did you notice 15.1T is released?” post kcuorbax shared exciting news about the new CCIE track launched yesterday:

CCIE Numbering experts will have the outstanding ability to find if a bug fixed in release A is fixed in release B. They will understand why new features are inadvertently introduced in mainline trains and why developers forget to commit fixes in the branches where the bugs were discovered. They will master the double numbering of IOS-XE and the sudden change from 12.2XN to 15.0S.

Anyone brave enough to try to take this exam?

This looks like another April 1st RFC (but it's apparently not):

Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.

Unveiling of the Cisco IOS release 15.1(1)T was the extreme opposite of the CRS-3 and Catalyst 3750-X splashes; the next release of one of the foundations of Cisco’s core business deserved a modest two-paragraph mention in the What's New in Cisco Product Documentation page.

If you’re a voice guru, you’ll probably enjoy the list of 20+ voice-related new features, including the all-important Enhanced Music on Hold. For the rest of us, here’s what I found particularly interesting:

One of the exciting new features of the recently launched CRS-3 router enables Service Providers to implement first-ever all-optical end-to-end traffic grooming. One of the new linecards (unfortunately not compatible with CRS-1 due to increased hardware complexity) supports the SFSS protocol (defined in RFC 4824).

Using a high-quality video link and all-optical spatial separators you can easily transport more than one SFSS instance on the same wavelength, allowing you to implement a true sub-lambda traffic grooming in the optical domain. There’s just one gotcha: due to the encoding requirements of SFSS, you cannot carry it in the dense channel spacing of DWDM; you have to use CWDM or even wider optical bands depending on the receiver’s capabilities.

An MPLS Traffic Engineering (MPLS TE) tunnel is a unidirectional Label Switched Path (LSP) established between the tunnel head-end Label Switch Router (LSR) and tail-end LSR. Once the tunnel is established and operational, it’s ready to forward IPv4 data traffic. However, no traffic will enter the tunnel unless the IPv4 routing tables and CEF tables are modified. You can push the traffic into an MPLS TE tunnel with a static route or with policy-based routing (PBR) or modify the behavior of the link-state algorithm used to implement MPLS TE in your network.

The autoroute functionality configured with the tunnel mpls autoroute announce interface configuration command automatically inserts the MPLS TE tunnel in the SPF tree and ensures the tunnel is used to transport all the traffic from the head-end LSR to all destinations behind the tail-end LSR.

Disclaimer: No, this post has absolutely nothing to do with any software I regularly blog about.