Russian equipment. Part 5. Natex FlexCon
It was a bit surprising for me how often Russian devices are used in telecom. To me on the table regularly gets something new. And each time it promises a lot of interesting things.
So this time there was suddenly a need to organize a channel to a very remote point. The only possible solution was to rent an E1 stream from a cellular operator. Since we essentially needed Ethernet, and not E1, without further ado, we ordered Ethernet-E1 converters from the Russian manufacturer Natex.
Under the cut review itself, and in the next topic will be the history of installation.
So, if you looked under the cat, then you hardly need to explain what E1 is, converters, and how this very E1 is taken from the operator. Therefore, immediately to the point.
A week after the order, two heavy cardboard boxes lay on my table.
Inside
1) The converter itself, made in the form factor of a self-sufficient device without the possibility of installation in a rack. It was wrapped in relaxation material.
')
2) Huge size and very heavy power supply for 12 volts. On the contacts for something was wearing a cap. From what she had to protect remains a mystery.
3) Documentation
4) Two Ethernet patch cords.
The contents of the second box are completely identical.
The converter is made of plastic. The case is of high quality, does not creak, the gaps are small. The device is devoid of any bourgeois jewelry and ryushechek - all in a Siberian manner severely and strictly.
It is similar in size to an ADSL modem, lightweight, but on a shelf in a switching cabinet it looks alien because of its form factor.
On the front panel we can see five large indicators and model marking. The Status indicator tells us that the converter is connected to the power supply, as well as the status of the G703 port (E1). LAN indicator - the status of the Ethernet port - it is green, and when it is transmitted, it flashes orange-red. The purpose of the three other indicators is hidden behind a veil of darkness - they never caught fire.
From the bottom, above, on the sides there is nothing remarkable, except for the ventilation holes. And this is despite the fact that the manufacturer’s website states “Setup and control using an LCD monitor and four keys” .
Slightly more interesting is the back panel. Here we can find a standard power connector, a G703 port for connecting an E1 stream and an Ethernet port. Again, the site lists two ports (PC, Hub). Perhaps it is in connection with this bundled 2 patchcords.
There is also a DB9 type RS232 control port (mother)
Let's move from the appearance to the software equipment of the device.
There is some kind of own OS installed on board, which provides not a CLI, but a menu-type interface (like the one that was in Mlink )
They say it is borrowed along with the OS from the progenitor of this device.
Everything looks quite simple. Through this menu you can configure:
E1 parameters
used time slots
Ethernet settings.
Enable software loopback
And see the status of the stream and Ethernet port:
There are no shortcomings in the performance of the management console, except that the exit item in the root menu does not work. When connecting via telnet, no matter how many times you choose it, it will not work. Also, when the password is set, it is required to enter it only when entering certain menu items, while entering the console, authorization is not required.
Field work
In fact, the title will be fully disclosed in my next publication.
Here I will briefly talk about the testing process.
In fact, no settings are needed; everything works out of the box. To verify this, you need to connect two devices to each other, and computers to them.
Of course, the usual patchcord, compressed in accordance with the Ethernet standard, will not work here. The E1 cable uses two pairs: two wires for reception, two for transmission. On the connector it is 1, 2 and 4, 5 pins on one side and vice versa on the other. All pinouts are listed at the end of the manual enclosed in the box: both Ethernet and E1 and DB9.
Actually, after a physical connection and setting up IP addresses, everything worked. You can check this by pinging. Devices operate in bridge mode, respectively, the IP addresses for management can be from the same subnet as the end devices.
The next test is a bandwidth test. To do this, use the package iperf. I did not expect any trick here. Well, it was not:
Connecting two devices is one thing, and connecting them at two very distant points to the operator is a little different. There are creeping out and poorly plugged / crimped wires, and unnecessary loopbacks of the operator, and synchronization, and some other fantastic problems. But this is no longer relevant to the devices - they earned normal.
There is only one problem, the causes of which are still unknown: after a reload of the converter in the channel, hellish packet loss begins. With a packet size of 1000 bytes, the loss is up to 90%. While such situations are resolved by removing the flow on the operator’s side and creating a new one. Whether the synchronization does not work and the packages do not have time to "crawl through", or if this is some kind of software converter failure, it is unclear. Finding out the reasons is already a condition of the next task.
So this time there was suddenly a need to organize a channel to a very remote point. The only possible solution was to rent an E1 stream from a cellular operator. Since we essentially needed Ethernet, and not E1, without further ado, we ordered Ethernet-E1 converters from the Russian manufacturer Natex.
Under the cut review itself, and in the next topic will be the history of installation.
So, if you looked under the cat, then you hardly need to explain what E1 is, converters, and how this very E1 is taken from the operator. Therefore, immediately to the point.
A week after the order, two heavy cardboard boxes lay on my table.
Inside
1) The converter itself, made in the form factor of a self-sufficient device without the possibility of installation in a rack. It was wrapped in relaxation material.
')
2) Huge size and very heavy power supply for 12 volts. On the contacts for something was wearing a cap. From what she had to protect remains a mystery.
3) Documentation
4) Two Ethernet patch cords.
The contents of the second box are completely identical.
The converter is made of plastic. The case is of high quality, does not creak, the gaps are small. The device is devoid of any bourgeois jewelry and ryushechek - all in a Siberian manner severely and strictly.
It is similar in size to an ADSL modem, lightweight, but on a shelf in a switching cabinet it looks alien because of its form factor.
On the front panel we can see five large indicators and model marking. The Status indicator tells us that the converter is connected to the power supply, as well as the status of the G703 port (E1). LAN indicator - the status of the Ethernet port - it is green, and when it is transmitted, it flashes orange-red. The purpose of the three other indicators is hidden behind a veil of darkness - they never caught fire.
From the bottom, above, on the sides there is nothing remarkable, except for the ventilation holes. And this is despite the fact that the manufacturer’s website states “Setup and control using an LCD monitor and four keys” .
Slightly more interesting is the back panel. Here we can find a standard power connector, a G703 port for connecting an E1 stream and an Ethernet port. Again, the site lists two ports (PC, Hub). Perhaps it is in connection with this bundled 2 patchcords.
There is also a DB9 type RS232 control port (mother)
Let's move from the appearance to the software equipment of the device.
There is some kind of own OS installed on board, which provides not a CLI, but a menu-type interface (like the one that was in Mlink )
They say it is borrowed along with the OS from the progenitor of this device.
Everything looks quite simple. Through this menu you can configure:
E1 parameters
used time slots
Ethernet settings.
Enable software loopback
And see the status of the stream and Ethernet port:
There are no shortcomings in the performance of the management console, except that the exit item in the root menu does not work. When connecting via telnet, no matter how many times you choose it, it will not work. Also, when the password is set, it is required to enter it only when entering certain menu items, while entering the console, authorization is not required.
Field work
In fact, the title will be fully disclosed in my next publication.
Here I will briefly talk about the testing process.
In fact, no settings are needed; everything works out of the box. To verify this, you need to connect two devices to each other, and computers to them.
Of course, the usual patchcord, compressed in accordance with the Ethernet standard, will not work here. The E1 cable uses two pairs: two wires for reception, two for transmission. On the connector it is 1, 2 and 4, 5 pins on one side and vice versa on the other. All pinouts are listed at the end of the manual enclosed in the box: both Ethernet and E1 and DB9.
Actually, after a physical connection and setting up IP addresses, everything worked. You can check this by pinging. Devices operate in bridge mode, respectively, the IP addresses for management can be from the same subnet as the end devices.
The next test is a bandwidth test. To do this, use the package iperf. I did not expect any trick here. Well, it was not:
iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.61 port 5001 connected with 192.168.1.2 port 53138
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-101.2 sec 23.4 MBytes 1.94 Mbits/sec
Connecting two devices is one thing, and connecting them at two very distant points to the operator is a little different. There are creeping out and poorly plugged / crimped wires, and unnecessary loopbacks of the operator, and synchronization, and some other fantastic problems. But this is no longer relevant to the devices - they earned normal.
There is only one problem, the causes of which are still unknown: after a reload of the converter in the channel, hellish packet loss begins. With a packet size of 1000 bytes, the loss is up to 90%. While such situations are resolved by removing the flow on the operator’s side and creating a new one. Whether the synchronization does not work and the packages do not have time to "crawl through", or if this is some kind of software converter failure, it is unclear. Finding out the reasons is already a condition of the next task.
Source: https://habr.com/ru/post/98656/
All Articles