Category: WAN

In the pre-DSL days, you had two options to get a short-haul high-speed link (at least in Europe): take E1 (or fractional E1) from a telecom (which was more expensive than a highway robbery, as the cost was recurring) or use baseband modems with proprietary encoding techniques on physical copper wires (assuming you could get them). As it turned out, some of these encoding techniques were not as good as the others (but the equipment was relatively cheap, so the budget limits usually forced the decision). We had our own share of modem-related problems, but they were never as bad as what I've heard from one of my students: his modems would lose synchronization when transmitting a long string of zeroes over a regular synchronous serial interface; ping ip 1.2.3.4 size 1000 data 0000 would be enough to bring down the link.

And now two questions for you:

• What could you do on the router to fix this problem?
• Why was the synchronization retained when transmitting a long string of ones?

Some fifteen years ago we were building a router-based network using primarily baseband modems (that's how the DSL boxes with symmetrical speeds were called back then). Everything worked great, we even had DECnet running between a few sites. However, after a few weeks, a mystery phenomena crept up: when the users were copying files between two VAX computers, the link between the sites went down … always when copying the same file.

To make the long story short: every modem uses a predefined sequence that enables remote loopback. These sequences are standardized and have been chosen so that the chance of hitting them with real traffic is close to zero (but obviously not zero). The file that the users were trying to copy contained just the correct sequence to trigger the remote loopback in one of the modems and the link went down (most probably changed state to looped) as the routers started to receive their own packets. Disabling remote loopback on the modem (a jumper in those days) solved the problem.

The moral of the story: whenever you use pattern matching to identify something (be it a specific application that you're trying to identify or a virus in your workstation), there is a non-zero chance of false positives, usually in the most unusual places.

Let's conclude this post with what seems to me a ludicrous “invention”: someone patented the flashing of LEDs when performing loopback tests on a modem. If anyone can survive reading the whole patent application, understand it and recognize its true added value, please let me know … I got completely lost.

In the “good old days” we've been teaching our students that although a router can act as a Frame Relay switch, it supports only the rudimentary functionality of switching the packets, but not the policing/marking features available in Frame Relay switches. That hasn't been true for a while - in IOS release 12.1T, Cisco has introduced the congestion management features. You can specify the congestion management per-interface (with the frame-relay congestion-management interface configuration command) and set the DE drop/ECN mark percentages for all PVCs on the interface or you can set the parameters within a map-class.

I don't know how useful this feature is to you; I was fond of finding it because it solves some interesting problems I had a (long) while ago. If you need more in-depth description or actual configurations, post a comment or send me a message.

I've always wanted a short summary display of DLCIs configured on my Frame Relay boxes (or whatever your favorite WAN technology is), but the only printout I would get from the router would be the lengthy show frame pvc printout. Fortunately, a judicious use of output filters can get you a summary printout from almost anything Cisco IOS produces.

Cisco IOS supported Frame Relay switching (emulation of a Frame Relay switch) for a very long time. First they've implemented local switching, then remote switching over a GRE tunnel. With the introduction of generic Layer 2 transport across a layer-3 backbone (L2TPv3 or AToM), Frame Relay switching got integrated into the new infrastructure, but never implemented completely ... that is, until release 12.0(27)S and 12.4(11)T which finally supports local switching in the new architecture. We've also got a few extra goodies: now you can do DTE-to-DTE switching (interconnecting two Frame Relay switches with a router) or same-port switching (switching two DLCIs terminating on the same router port).