|Network Testing and Emulation Solutions|
|Creating connections in the LANforgeGUI implies creating endpoints. These endpoint entities are created with predictable names and are usually created in pairs. Understanding these naming conventions and how they are created is fundamental to your proficiency with creating connections with LANforge CLI scripts.|
Most examples in our cookbooks assume a dual-ended connection, also known as a cross-connect or abbreviated as CX.
Let's follow the creation of a Connection:
Using a terminal on the LANforge machine, we look at the /home/lanforge/DB/DFLT/endps.db file and inspect the commands issued that create that connection:
That's a lot of commands. We will point out what is particularly necessary when using our Perl scripts.
The connection we created above is named tutorial-cx. Two endpoints also have names, tutorial-cx-A and tutorial-cx-B. The A-side of a connection is always managed. A B-side endpoint may be unmanaged. When you write CLI scripts that create connections, name your endpoints using a similar convention.
We can use the lf_firemod.pl script to create endpoints and a cross connect in this order:
$ ./lf_firemod.pl --action create_endp --endp_name tutorial2-cx-A \ --speed 256000 --endp_type lf_tcp --port_name sta301 $ ./lf_firemod.pl --action create_endp --endp_name tutorial2-cx-B \ --speed 256000 --endp_type lf_tcp --port_name eth1 $ ./lf_firemod.pl --action create_cx --cx_name tutorial2-cx \ --cx_endps tutorial2-cx-A,tutorial2-cx-B
We can see the results of those script commands in our Layer-3 and L3 Endps tabs:
When a connection is first created, it is STOPPED. When you start it, it becomes RUNNING. When you set a connection to STOPPED, both endpoints immediately stop sending and recieving. That can have a consequence of leaving unacknowledged packets in flight. The safest way is to QUIECE the connection, which first stops the endpoints transmitting, waits a short time, and then stops the endpoints from recieving.
Normally, if you see one endpoint, it should only be a multicast endpoint. A single endpoint can be seen in these situations:
A single endpoint is not an illegal entity, but lonely endpoints can add confusion. If you find endpoints that do not match any existing connections, we suggest deleting them.
A Cross-Connect can be one-sided, that is, have one unmanaged endpoint. The A side endpoint is a LANforge managed port transmitting to another device that's not a LANforge machine. Some connection types create this style of endpoint pairs, like File-endpoints and Layer 4-7 connections.
Multicast endpoints are created differently both in the GUI and in the CLI scripting environment. This tutorial does not focus on multicast, but see the section Creating Endpoints section of Creating Connections with FIREMod Script and the chapter on WiFi Multicast Download.