For the oldtimers: swamped with zeroes

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?

11 comments:

  1. I would do a ping with one's and the link would stay up and response.
    like this;
    ip 1.2.3.4 size 1000 data 1111
  2. :)) And how would you ensure that an accidental user data packet wouldn't bring the link down?
  3. might depend on the link in question, but assuming that this e.g. might be an PPP link or a hdlc link, using a compression technique might solve the issue, because the long string of zeroes would not be transmitted as such.
    Of course, compression might be infeasible because of some reason, but just a thought...
    /bernhard
  4. From what I recall you would have this problem on earlier line codes such as NRZ. If you're transmitting the same bit the system would loose sync as there are no state changes. Later encodings addressed this problem in various ways, for example Manchester does a transition at mid-bit.

    Using encryption such as IPSEC would ensure that long sequencues of zero bits is a very rare condition. :)
  5. will LFI solve this issue?
  6. The real solution is bit stuffing. But hey, considering we have to make do with what we have on the router already . . .

    Bunch of answers so far - IPSec and compression look to "hide" the repeating sequence of 0x00s in the data stream. Too bad both of them are relatively "new" features to IOS - 11.x

    I specially liked LFI - a cheap way to perform some kind of stuffing :)

    Yours is an incomplete scenario - we don't know how many bits/bytes of 0x00 would trigger the issue . . .

    Anyway - I had two solutions to propose. GRE tunnels was the first - been around for a long time (10.x). But I will go with a lower overhead one - change the interface MTU to the minimum of 64 bytes for Ethernet. With a 20-bytes IP header and a 20-bytes TCP header (if using TCP), that leaves about 24 bytes for data - as long as your "trigger pattern" is > 24 bytes, you should be OK.

    Sadly, it might break applications that set DF and don't do PMTU. In that case, go GRE :)
  7. @Vladimir: Manchester encoding requires twice the frequency spectrum of NRZ/NRZI encoding, so it's not widely used where you have frequency limitations (like telephone wires).

    As a side note, it has an interesting property: assuming zero and one have opposing polarities (like +12 and -12V), there's no DC component (the average voltage is zero).
  8. Instead of using this poor buggy hardware the student should switch to RFC1149 or (better) RFC2549. It solves both issues: the link-down and the recurring cost!
  9. GRE has option to garble data with 32bit key. Using

    interface tunnel0
    tunnel mode gre
    tunnel key 3735928559

    should solve the problem on old IOS too.
  10. The simplest and harmless solution should be using "invert data" in configuration of the serial interface. Doing that changes HDLC algorithm from insert zeroes to insert ones. This should be enought to solve the problem.
  11. That's a dangerous misconception there - GRE never used the key to encrypt nor "garble" data in any way. It was thought as a very simple check method to prevent insertion of bogus traffic by a 3rd party - you either know the key or you don't.
    But they key travels in the clear on the GRE header, and it isn't used in any way to perform any kind of processing on the payload.
    Check RFC-1701 and RFC-2890 - quoting:

    "2.1. Key Field (4 octets)

    The Key field contains a four octet number which was inserted by the
    encapsulator. The actual method by which this Key is obtained is
    beyond the scope of the document. The Key field is intended to be
    used for identifying an individual traffic flow within a tunnel. For
    example, packets may need to be routed based on context information
    not present in the encapsulated data. The Key field provides this
    context and defines a logical traffic flow between encapsulator and
    decapsulator. Packets belonging to a traffic flow are encapsulated
    using the same Key value and the decapsulating tunnel endpoint
    identifies packets belonging to a traffic flow based on the Key Field
    value."
Add comment
Sidebar