Category: WAN
L2TP: The revenge of hardware switching
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.
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).
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:
IP over DWDM
A while ago I was pushed (actually it was a kind nudge) into another interesting technology area: optical networks, with emphasis on IP over DWDM. I realized almost immediately that I’d encountered another huge can of worms. A few issues you can stumble across when trying to plug routers or switches directly into DWDM networks are documented in my IP over dense wave division multiplexing (DWDM): Metro and core issues article recently published by SearchTelecom.com.
Detect DoS Attacks with EEM
Someone sent me an interesting question a while ago: “is it possible to detect DOS flooding with an EEM applet?” Of course it is (assuming the DOS attack results in very high load on the Internet-facing interface) and the best option is the EEM interface event detector.
Detecting interface overload with EEM
The interface event detector is more user-friendly than the SNMP event detector. You can specify interface name and parameter name in the interface event detector; with SNMP event detector you have to specify SNMP object identifier (OID). The interface event detector stores the interface name, measured parameter name and its value in three convenient environment variables that you can use to generate syslog messages or alert the operators via e-mail.
What went wrong: end-to-end ATM
Red Pineapple was kind enough to share his 15-year-old ATM slides. They include interesting claims like:
ATM has the potential to displace all existing internetworking technologies
One single network handles all traffic types: Bursty data and Time-sensitive continuous traffic (voice/video).
All these claims are still true if you just replace »ATM« with »IP«. So what went wrong with ATM (and why did the underdog IP win)? I can see the following major issues:
- ATM is a layer-2 technology that wanted to replace all other layer-2 technologies. Sometimes it made sense (ADSL), sometimes not so much (LAN … not to mention LANE). IP is a layer-3 technology that embraced all layer-2 technologies and unified them into a single network.
- ATM is an end-to-end circuit-oriented technology, which made perfect sense in a world where a single session (voice call, terminal session to mainframes) lasted for minutes or hours and therefore the cost of session setup became negligible. In a Web 2.0 world where each host opens tens of sessions per minute to servers all across the globe, the session setup costs would be prohibitive.
- Because of its circuit-oriented nature, ATM causes per-session overhead in each node in the network. Core IP routers don’t have to keep the session state as they forward individual IP datagrams independently. IP is thus inherently more scalable than ATM.
The shift that really made ATM obsolete was the changing data networking landscape: voice and long-lived low-bandwidth data sessions which dominated the world at the time when ATM was designed were dwarfed by the short-lived bursty high-bandwidth web requests. ATM was (in the end) a perfect solution to the wrong problem.
… updated on Monday, December 7, 2020 17:17 UTC
ADSL QoS Basics
Based on the ADSL reference model, let’s try to figure out how you can influence the quality of service over your ADSL link (for example, you’d like to prioritize VoIP packets over web download). To understand the QoS issues, we need to analyze the congestion points; these are the points where a queue might form when the network is overloaded and where you can reorder the packets to give some applications a preferential treatment.
Remember: QoS is always a zero-sum game. If you prioritize some applications, you’re automatically penalizing all others.
… updated on Monday, December 7, 2020 17:01 UTC
ADSL Reference Diagram
I’m getting lots of ADSL QoS questions lately1, so it’s obviously time to cover this topic. Before going into the QoS details, I want to make sure my understanding of the implications of the baroque ADSL protocol stack is correct.
In the most complex case, a DSL service could have up to eight separate components (including the end-user’s workstation):
True or false: MPLS VPNs offer equivalent security to Frame Relay
Years ago when vendors were pushing the MPLS story to Service Providers, an “independent analyst” wrote a report claiming that MPLS-based VPNs offer security equivalent to Frame Relay networks (to find those reports, ask Google about “MPLS security equivalent to Frame Relay”). This might be true from the functional perspective (and it’s absolutely true that using IP does not make MPLS-based VPNs inherently insecure), but anyone believing these reports might become mightily upset when learning about BGP and MPLS security issues.
Before going any further, please note that exploiting the MPLS architecture as described in All your packets are belong to us presentation requires access to the core SP network, which means that the network (or network management station) has already been successfully penetrated.
Another green initiative from Cisco Systems
Cisco has unveiled numerous green solutions in the last few months, including energy-saving ASR 9000 router and GreenWise initiative. Now they went a step further and implemented some of the old energy-efficient wireless technologies, proving that you don’t always need new technologies to address the energy efficiency (see also Myth #8 in Top 10 Myths about Sustainability).
The first step in GreenWise wireless rollout are the new high-density line cards for the ASR 9000 routers. The port adapters and SFP modules in these line cards will support RFC 1149 with its low-electricity requirements, low-emission focused RFC 1926 as well as RFC 4824 addressing the needs of the health care vertical market. The first release of the line cards will not support all QoS requirements of RFC 2549 due to the limited processing power of the on-card PPU.
You can find detailed information on these revolutionary line cards and adapters among the other in-depth data sheets documenting ASR 9000 platform and line cards (snapshot of the page).
Ah, the wonderful quoting process
Network World just published an article on LISP, including a quote attributed to Geoff Huston:
LISP relies on tunneling, and tunneling is not 100% perfect. At times, the tunnel passes a packet that's too big and it disappears without a trace to the sender or the recipient…That's really bad.
We all know what can go wrong with the tunnels: a combination of:
- MTU setting on a core link that is too low to accomodate tunnel envelope+payload with
- Tunnel headend that cannot respond to Fragmentation needed ICMP message.
ADSL overhead
Yesterday I’ve described the difference between line rate and bit rate (actually physical layer gross bit rate and physical layer net bit rate). Going to the other extreme, we can measure goodput (application-level throughput), which obviously depends on multiple factors, including the TCP window sizes and end-to-end delays. There are numerous tools to test the goodput from/to various locations throughout the world (speedtest.net worked quite nicely for me) and you’ll soon discover that the goodput on your DSL line differs significantly from what the ISP is advertising.
Line rate and bit rate
Rajendra had an interesting problem:
Recently I got confused with the term line-rate. Is it the packets being switched across the switch fabric or control packets destined to the protocol tasks or both or something else?
The line rate is a physical layer term that has nothing to do with the line cards or switching fabrics. It indicates the actual speed with which the bits are sent onto the wire (and is thus also known as physical layer gross bit rate). The data transfer rate (commonly known as bit rate) is the transfer rate offered by the physical layer to the data link layer. If you want to be precise, you should call it physical layer net bit rate.
Two well-known physical layer technologies with different line rate and data transfer rate are ISDN (actually the I.430 recommendation) with 160192 kbps line rate and 144 kbps data transfer rate and Gigabit Ethernet (the 802.3z recommendation) with 1.25 Gbps line rate (due to 8b/10b encoding).
This article is part of You've asked for it series.
OSPF Breaks When Faced With Overlapping IP Addresses
A while ago cciepursuit described his problems with PPP-over-Frame Relay. Most probably his problems were caused by a static IP address assigned to the virtual template interface (this address gets cloned to all virtual access interfaces and IOS allows you to have the same IP address on multiple WAN point-to-point links). I recreated a very similar (obviously seriously broken) scenario in my lab using point-to-point subinterfaces over Frame Relay to simplify the setup.
OSPF Ignores Subnet Mask Mismatch on Point-to-Point Links
The common wisdom says that the subnet mask mismatch will stop the OSPF adjacency from forming. In reality, the subnet mask is checked only on the multi-access interfaces and is ignored on point-to-point links. The source of this seemingly weird behavior is the Section 10.5 of RFC 2328, which says:
The generic input processing of OSPF packets will have checked the validity of the IP header and the OSPF packet header. Next, the values of the Network Mask, HelloInterval, and RouterDeadInterval fields in the received Hello packet must be checked against the values configured for the receiving interface. Any mismatch causes processing to stop and the packet to be dropped. In other words, the above fields are really describing the attached network's configuration. However, there is one exception to the above rule: on point-to-point networks and on virtual links, the Network Mask in the received Hello Packet should be ignored.