Channel consolidation, or solution of one telecommunication problem
I am an employee of one small operator. I have never written an article, but one task arose that prompted me to write this review.
We were faced with the task that in one of the areas in which we deployed a channel to present services to our clients, we had a client who needed to connect the newly installed PBX, and to connect without fail via the E1 stream. Between our central node and the remote point of presence of the client, only Gigabit Ethernet was transmitted via leased fiber from us, respectively, we needed to transfer an additional E1 channel. The situation was complicated by the large attenuation in the optical fiber between the communication centers, and therefore in our switches there were 30 dB (120 km) SFP modules for working on one leased fiber. After analyzing possible solutions to the problem, several possible approaches were proposed:
1) Rent another optical fiber and install an E1 optical modem on it;
2) Condense the optical line between the nodes of the CWDM system.
3) Install a pseudowire transfer device (TDM over IP, ru.wikipedia.org/wiki/TDMoIP ) on a working data transmission network and convert E1 to Ethernet, then transfer between objects in a converted form, and perform a reverse conversion on the central node;
4) Find a device that combines Gigabit Ethernet transmission with E1 transmission and supports operation with high attenuation on the optical line.
The first solution was immediately dropped as it required a periodic subscription fee for additional fiber. The second option seemed quite suitable, but required the installation of several additional components: a CWDM multiplexer and a media converter (multiplexer) with an E1 port and an uplink port in the form of an SFP to connect to the CWDM multiplexer. If there is a fixed E1 port on the E1 modem, it would be necessary to additionally install an active wavelength converter to connect the modem to the CWDM to the system. The decision was somewhat cumbersome, and for this reason it was also dropped.
The third solution turned out to be quite real, but the client demanded the conclusion of a contract with one obligatory item “E1 G.703 stream should be transmitted without converting and changing the structure, and also without using pseudowire data transfer technologies”. Therefore, they also decided to refuse this decision. There was the last option.
The requirements for the device were formulated: the presence of a Gigabit Ethernet port, an E1 port (at least 2x for possible expansion purposes), an integrated long-range optical port, or an SFP port for installing optical modules. The last criterion was the support of long-range optical modules, since in my experience not all devices support them.
After a brief search on the Internet, we found the necessary device and took it to the test in our laboratory to solve our problem. We received the appropriate equipment: RCMS2912-4 / 8T1E1GE multiplexer 2 pcs. ( http://www.raisecom.su/equipment/e1ethopt/multiservpdh/rcms2912/ ), the chassis for the installation of multiplexers - RC001-1D-WP 2 pcs. ( http://www.raisecom.su/equipment/chassis/rc0011d/ ). In the configuration to the devices were also discs with instructions in English.
')
The RCMS2912 multiplexer onboard had a copper Gigabit Ethernet port, four E1 ports, and two SFP ports for installing optical modules. The front panel also displays several indicators that are responsible for displaying alarms on E1 ports, the status of the Ethernet port, and the status of optical ports.
One of the first doubts that we had then was whether the device would work with the existing long-range SFP modules that were installed in the working switch at the communications center. Since we had the same spare SFPs in reserve, we managed to carry out a test “on the table” without installing the equipment on the network. Was collected scheme.
From switch 1 to switch 2, packets were sent using the ping utility. The test was successful, our SFPs began to work safely in the new equipment.
ping 172.10.2.165 count 100 waittime 1
Type CTRL + C to abort.
Sending 100, 8-byte ICMP Echos to 172.10.2.165, timeout is 1 seconds:
!!!
- PING Statistics ----
100 packets transmitted,
100 packets received, Success rate is 100 percent (100/100)
round-trip (ms) min / avg / max = 0/0/0
Further, it was required to check the operation of devices for the transmission of E1. Unfortunately, at that time, there was no E1 tester in our “mini-laboratory”, to test the E1, we used two CISCO 2610 routers. The following scheme was assembled.
The only difficulty in preparing for the test was to prepare the E1 cable for connecting the CISCO 2610 and RCMS-2912. For this, we had to raise the pinout of the CISCO module on the Internet + to watch the pinout of the Raisecom multiplexer. After connecting the devices according to the above scheme, the channel rose, and the packets began to walk successfully between routers. The test has been passed.
It was decided to test the bandwidth of the Gigabit Ethernet. Only 3 computers with Gigabit Ethernet network cards were available. Iperf was used as software. Pre-assembled scheme
Between two PCs. The result was
Next was collected scheme.
And the result is obtained
Thus, the device completely coped with the load and the test was subsequently repeated on a working channel at a speed of ~ 450 Mbps.
One of the additional features of the device was support for SFP port redundancy. This feature allows the device to switch to the second optical port if the link on the first optical port is dropped.
It was decided to test the operation of this function as well. We did not have an additional pair of long-range modules, and SFP for 20 km was used and the scheme was assembled.
For the test, PC_A enabled iperf in server mode, PC_B enabled iperf test over UDP with the following settings.
On PC_B, iperf ( http://sourceforge.net/projects/iperf/ ) was launched in client mode to perform a test using the UDP protocol.
The goal was to determine whether packet loss would occur when switching between two optical channels. In turn, we pulled out and installed optical patch cords. The result was as follows:
The test showed that during verification no UDP packet was lost. The device successfully coped with the task.
After all the tests, it was decided to install the device on a working network. The 48-hour test showed that the device worked without failures, after which we completed the client connection.
This solution turned out to be quite profitable - about 60,000 rubles, when compared with other options for solving the problem.
We were faced with the task that in one of the areas in which we deployed a channel to present services to our clients, we had a client who needed to connect the newly installed PBX, and to connect without fail via the E1 stream. Between our central node and the remote point of presence of the client, only Gigabit Ethernet was transmitted via leased fiber from us, respectively, we needed to transfer an additional E1 channel. The situation was complicated by the large attenuation in the optical fiber between the communication centers, and therefore in our switches there were 30 dB (120 km) SFP modules for working on one leased fiber. After analyzing possible solutions to the problem, several possible approaches were proposed:
1) Rent another optical fiber and install an E1 optical modem on it;
2) Condense the optical line between the nodes of the CWDM system.
3) Install a pseudowire transfer device (TDM over IP, ru.wikipedia.org/wiki/TDMoIP ) on a working data transmission network and convert E1 to Ethernet, then transfer between objects in a converted form, and perform a reverse conversion on the central node;
4) Find a device that combines Gigabit Ethernet transmission with E1 transmission and supports operation with high attenuation on the optical line.
The first solution was immediately dropped as it required a periodic subscription fee for additional fiber. The second option seemed quite suitable, but required the installation of several additional components: a CWDM multiplexer and a media converter (multiplexer) with an E1 port and an uplink port in the form of an SFP to connect to the CWDM multiplexer. If there is a fixed E1 port on the E1 modem, it would be necessary to additionally install an active wavelength converter to connect the modem to the CWDM to the system. The decision was somewhat cumbersome, and for this reason it was also dropped.
The third solution turned out to be quite real, but the client demanded the conclusion of a contract with one obligatory item “E1 G.703 stream should be transmitted without converting and changing the structure, and also without using pseudowire data transfer technologies”. Therefore, they also decided to refuse this decision. There was the last option.
The requirements for the device were formulated: the presence of a Gigabit Ethernet port, an E1 port (at least 2x for possible expansion purposes), an integrated long-range optical port, or an SFP port for installing optical modules. The last criterion was the support of long-range optical modules, since in my experience not all devices support them.
After a brief search on the Internet, we found the necessary device and took it to the test in our laboratory to solve our problem. We received the appropriate equipment: RCMS2912-4 / 8T1E1GE multiplexer 2 pcs. ( http://www.raisecom.su/equipment/e1ethopt/multiservpdh/rcms2912/ ), the chassis for the installation of multiplexers - RC001-1D-WP 2 pcs. ( http://www.raisecom.su/equipment/chassis/rc0011d/ ). In the configuration to the devices were also discs with instructions in English.
')
The RCMS2912 multiplexer onboard had a copper Gigabit Ethernet port, four E1 ports, and two SFP ports for installing optical modules. The front panel also displays several indicators that are responsible for displaying alarms on E1 ports, the status of the Ethernet port, and the status of optical ports.
One of the first doubts that we had then was whether the device would work with the existing long-range SFP modules that were installed in the working switch at the communications center. Since we had the same spare SFPs in reserve, we managed to carry out a test “on the table” without installing the equipment on the network. Was collected scheme.
From switch 1 to switch 2, packets were sent using the ping utility. The test was successful, our SFPs began to work safely in the new equipment.
ping 172.10.2.165 count 100 waittime 1
Type CTRL + C to abort.
Sending 100, 8-byte ICMP Echos to 172.10.2.165, timeout is 1 seconds:
!!!
- PING Statistics ----
100 packets transmitted,
100 packets received, Success rate is 100 percent (100/100)
round-trip (ms) min / avg / max = 0/0/0
Further, it was required to check the operation of devices for the transmission of E1. Unfortunately, at that time, there was no E1 tester in our “mini-laboratory”, to test the E1, we used two CISCO 2610 routers. The following scheme was assembled.
The only difficulty in preparing for the test was to prepare the E1 cable for connecting the CISCO 2610 and RCMS-2912. For this, we had to raise the pinout of the CISCO module on the Internet + to watch the pinout of the Raisecom multiplexer. After connecting the devices according to the above scheme, the channel rose, and the packets began to walk successfully between routers. The test has been passed.
It was decided to test the bandwidth of the Gigabit Ethernet. Only 3 computers with Gigabit Ethernet network cards were available. Iperf was used as software. Pre-assembled scheme
Between two PCs. The result was
Next was collected scheme.
And the result is obtained
Thus, the device completely coped with the load and the test was subsequently repeated on a working channel at a speed of ~ 450 Mbps.
One of the additional features of the device was support for SFP port redundancy. This feature allows the device to switch to the second optical port if the link on the first optical port is dropped.
It was decided to test the operation of this function as well. We did not have an additional pair of long-range modules, and SFP for 20 km was used and the scheme was assembled.
For the test, PC_A enabled iperf in server mode, PC_B enabled iperf test over UDP with the following settings.
On PC_B, iperf ( http://sourceforge.net/projects/iperf/ ) was launched in client mode to perform a test using the UDP protocol.
The goal was to determine whether packet loss would occur when switching between two optical channels. In turn, we pulled out and installed optical patch cords. The result was as follows:
The test showed that during verification no UDP packet was lost. The device successfully coped with the task.
After all the tests, it was decided to install the device on a working network. The 48-hour test showed that the device worked without failures, after which we completed the client connection.
This solution turned out to be quite profitable - about 60,000 rubles, when compared with other options for solving the problem.
Source: https://habr.com/ru/post/189070/
All Articles