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:
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?
like this;
ip 1.2.3.4 size 1000 data 1111
Of course, compression might be infeasible because of some reason, but just a thought...
/bernhard
Using encryption such as IPSEC would ensure that long sequencues of zero bits is a very rare condition. :)
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 :)
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).
interface tunnel0
tunnel mode gre
tunnel key 3735928559
should solve the problem on old IOS too.
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."