Hi
I have been trying to backhaul an E1 over canopy mux. I had done a back to back test, ie have a ethernet cable between two canopy mux and was able to get E1 on the other side.
However, when I try it in real situation, it didn’t work. I have a repeater in between. Has anyone used canopy mux with a wireless repeater in between. The distance covered is 90 km. The latency from one end to the next end is 18 ms.
I invoked loopbacks from the mux and the errors go away,ie, the cabling from mux to E1/T1 device is okay.
The ping times are okay. The link is running at 64QAM 7/8/
Can someone shed some light into this mux thing?
Thanks
I called canopy support and they say these mux work only in single hop and do not work with a repeater in between.
Would it be possible at the repeater site to bridge it as E1 instead of ethernet.
How do I bridge it as E1/T1. There is a ethernet port in BH30 PIDU. How can I bridge both the ethernet ports of PIDU as T1/E1 bridge. Can it be done by having crossover T1/E1 cable between the ethernet ports of the canopy PIDU?
Draw out your current setup for me. What I am gathering is that you have a 2-hop shot, but where do you have the mux boxes? At the remote ends? You may be able to get this to work, but you would need a total of (4) Mux boxes. One at each of the ends, and two at the repeater site. The boxes at the repeater site would have a T1/E1 crossover cable connecting their T1/E1 ports.
This is how carrier class microwave is done with repeater sites, but carrier class multiplexers would have their T1 DS0 channel mappings programmed/mapped to route certain DS0’s out certain interfaces/hops.
Do these Canopy MUX boxes simply contain unframed T1/E1 ports? Do you have external Mux which actually multiplexes the T1, then passes it to the Canopy Mux?
E1—>Mux—BH30------BH30+BH30------BH30—Mux—>E1
The muxes are at the both ends and not at the repeater sites. I think this canopy mux is tdm over ethernet so does not work with switched network.
The canopy mux contains unframed T1/E1 port. The device that E1 is terminated to says loss of frames.
I think instead of two more muxes at repeater site, wouldn’t it be better to have some external mux that work over switched network.
Can anyone recommend me a good mux that works over switched network?
I am slightly confused. The Canopy MUX that you are using is only multiplexing existing T1 frames along with any Ethernet traffic, into Ethernet Frames, to transport across the Canopy BH link. Once the packets reach the other side, they come in as Ethernet packets and it is the job of the Canopy MUX to demultiplex them back into their original T1/E1 form, pass through the output of the Canopy MUX, then to the external equipment.
Since the Canopy MUX has unframed ports, it is really not doing anything to the T1 or E1 with the exception of transforming them into Ethernet Frames. So any inputs to your T1/E1 ports on the Canopy MUX must already be in a T1/E1 frame format prior to coming into the Canopy MUX. Is this the case?
To answer your question, yes this is really a TDP over IP application. Since your BH links are Layer-2 Ethernet based, and Ethernet frames are all that Canopy accepts, you need the TDM over IP MUX boxes.
I think the only way that this can be done is if you put 2 additional MUX boxes at the repeater site.
E1—>Mux—BH30----BH30–Mux<->Mux–BH30----BH30—Mux—>E1
I would think that you would set one of your MUX to generate and be the master clock, and then set the rest of the MUX to receive their clock from the network.
I have no experience with these boxes so these are just suggestions.
An alternate MUX that works good would be something from RAD. I have not personally used them, but I have heard they are good units. We have some systems that run RAD mux’s for other purposes (MUX’ing T’s into DS3’s).
Yes, RAD makes a good product. I have used the VMUX-110 and MP2100 platforms.
I tried it over two switches, cascading switches and it works, but it doesnt work over a 2 pairs of backhauls. Is it because of latency of the backhauls or some other reason.
More update,
It worked in 2 hops of backhauls as well in lab. I simulated double hops in the lab and it works. The simulation was using BH10s. It did not work over BH30. I will test more post the results
I am not quite sure I am following you…
msmith,
Earlier I had tried to make it work over a 2 hops in real world and it did not. I called canopy support and they told me it only works in single hop.
I was under the impression that the canopy support was right. But I decided to give a try and tested in lab as follows
1. I cascaded 3 switches. One switch connected to next and so on. I put one mux in first switch and next mux on last switch it worked.
2. I used 2 pairs of BH 30 to simulate the link I had (on which it hadnt worked) and it worked over the simulated link.
Now I am confused as why it didn’t work over the real link and why canopy support told me that it would only work over single hop.
After I put some more thought into it, I don’t see why your real link would not work, either.
I have used RAD VMUX-100’s in similar implementations. However, it was a single hop. But in theory, the configuration of the VMUX, assuming it is similar to the Moto Mux, should be straight forward and should work over multiple hops.
The RAD VMUX boxes are assigned IP Addresses. You then login to each box and configure what is called a “bundle”. The bundle is simply a “route” from an IP perspective. All you must specify is the IP address of the remote VMUX, and the Canopy handles the transport of the Ethernet frame over the link to the remote “bundle”, or VMUX box.
Is the configuration of the Canopy MUX similiar? If it is, once the T1 frame structure is transformed into the Ethernet frame and pushed over the wireless link, the ARP tables of the Canopy BH units should take care of getting that original T1 frame encapsulated into Ethernet to the remote MUX, and from there it would transform it back to its original T1 strucutre and out to your TDM equipment.
I would think that the number of hops in between the boxes would be irrelevant, as long as the Ethernet frame gets to its destination. You would obviously want to minimize the latency between hops.
Perhaps it is a configuration of your boxes on your real link that is preventing everything from working?
Msmith,
The canopy mux do not have any ip address. It has to be configured through a DB9 port. It does not have any options to specify the ip addresses at all. I opened the box and on the PCB it is written Dragonwave.
This canopy mux is TDM over ethernet and not TDM over IP. I will test the E1 links again in real world and will let you know.
Thanks for the suggestions
I tried it again in real scenario and it did not work. I called canopy_support and again they told me that they expect to work it over 1 hop. I asked him how i was able to make it work over 2 hops in lab and why it did not work in real world.
All reply I got was that it would be escalated to Tier 3 support and they would call back.
This mux is really eating my brains.
I only use RAd IPmux and have no problem going through 6 BHs with switch between each wireless link. I have to configure my jitter buffer at a big value to compensate for the jitter of that many hops.
I see two things here that could help you. LAB with cable between switches is not the same as wireless between switches. the 2nd one will have jitter and bigger latency. You have to compensate by modifying the jitter buffer in the mux if it is possible.
Finally motorola replied. They asked me to send the field diags. They said one of the cat5 wiring to BH30 must have a problem. I rechecked the wires and recrimped everything. The mux started working. I could get E1 over 2 hops.
Since the links were working fine. Enough ethernet throughput. The reason why it was not working was one of the wire must be faulty. Motorola said that this "For E1/T1, it is important that the sync signal and the
> wires are correctly done otherwise, the jitter buffer will keep resetting
> because no packets are received."
No problem with ethernet but problem with E1/T1. I learned a new thing the hard way and thought to share it here