Ok, here's why we couldn't pass nulls:
The trouble was isolated to an ——— controlled SMX OC12 fiber mux on the ——— ——— campus that extends the circuit between campus buildings. The Option 1 circuit goes through the SMX mux that was not optioned to ignore excessive zeroes which is usually not a problem unless the customer's application is pushing excessive 0s across the circuit. In this case the customer's SAP application was padding 0s which resulted in a large string of 0s being transmitted across the connection and the fiber mux was not able to maintain synchronization when the string of 0s were detected. This resulted in the packet drops the customer was reporting.I don't know enough about the magic telco protocols to understand why this would affect synchronization.
——— actually has two different versions of fiber mux that they use when transporting connections between buildings on their fiber ring. They use what is called an Alcatel SMX mux (must be optioned to ignore excessive 0s if the customer traffic pattern generates this condition) and an Alcatel SM fiber mux which does not have the ability to be optioned to ignore excessive 0s. In ———'s case, the primary SMX fiber mux was already optioned to ignore excessive 0s when they are presented and the secondary fiber mux was not set to ignore the excessive 0s and the Engineer had to make the configuration change to correct that.
* If it's synchronous, there's clocks at either end that are synchronized. Data spews forth in predictable (clocked) chunks from one side, and the other side reassembles the chunks according to the clock.
* If it's asynchronous, the byte should be encapsulated by a bit that indicates "start of data."
I thought these protocols were all sync, but maybe they're not. Spooky.