IOU layer 1 keepalive are not working properly, interfaces are always down-down about gns3-server HOT 14 OPEN

Any hope of having this work one day? L1 keepalives have been working consistently in IOU images for many years. Since in GNS3 frame "piping" is done through ubridge, only keepalives through unix sockets are relevant. The socket naming scheme is simple and consistent. If you configure the switches to use L1-keepalives (thus, making al interfaces down-down) it is very easy to bring them up using netcat to send correctly formatted messages to the appropriate sockets (e.g, nc -U /tmp/netl1XXXX/LYY -u < packet where XXXX is the UID of the user running GNS3, YY is the IOU instance number and packet is a file hexedited to contain the appropriate message).
The message contains:

• u16 with destination instance (in network byte order)
• u16 with source instance (in network byte order); this will be the ubridge end (can be seen in NETMAP)
• u8 with destination interface (0xYX for Ethernet X/Y)
• u8 with source interface
• u8 with message type (seems to be always 0x03)
• u8 apparently for channel (seems to be always 0x00)

from gns3-server.

i just tested a serial link IOU - IOU , same problem there.

from gns3-server.

It is supposed to be down - down. The L1 feature (in IOU) is used to overcome the always-up Ethernet interfaces (seems to be supported only by recent L2 IOU images, this is the -l option).

from gns3-server.

i don't have my laptop with me right now, so i can't check my image directly as we speak (it will have to wait tomorrow). In any case i am running a 15.4 L3 image, and a 15.0 L2 image.

What i am trying to report is that even if the link is connected in all the flavours i reported before, and the link should be up , if L1 keepalive are enabled, the interface is down down.

with keepalive enabled, the interface should go down if nothing is connected on the other side, but if the link is there, it has to be up

from gns3-server.

here i am, both my images support L1 keepalives:

[root@localhost bin]# ./ADVk9-154 -h

IOS On Unix - Cisco Systems confidential, internal use only
Under no circumstances is this software to be provided to any
non Cisco staff or customers. To do so is likely to result
in disciplinary action. Please refer to the IOU Usage policy at
wwwin-iou.cisco.com for more information.

Usage: [options]
: unix-js-m | unix-is-m | unix-i-m | ...
: instance identifier (0 < id <= 1024)
Options:
-e Number of Ethernet interfaces (default 2)
-s Number of Serial interfaces (default 2)
-n Size of nvram in Kb (default 64KB)
-b IOS debug string
-c Configuration file name
-d Generate debug information
-t Netio message trace
-q Suppress informational messages
-h Display this help
-C Turn off use of host clock
-m Megabytes of router memory (default 256MB)
-L Disable local console, use remote console
-l Enable Layer 1 keepalive messages
-u UDP port base for distributed networks
-R Ignore options from the IOURC file
-U Disable unix: file system location
-W Disable watchdog timer
-N Ignore the NETMAP file
[root@localhost bin]# ./L2K9-15 -h
IOS On Unix - Cisco Systems confidential, internal use only

Usage: [options]
: unix-js-m | unix-is-m | unix-i-m | ...
: instance identifier (0 < id <= 1023)
Options:
-e Number of Ethernet interfaces (default 2)
-s Number of Serial interfaces (default 2)
-n Size of nvram in Kb (default 16KB)
-b IOS debug string
-c Configuration file name
-d Generate debug information
-t Netio message trace
-q Suppress informational messages
-h Display this help
-C Turn off use of host clock
-m Megabytes of router memory (default 256MB)
-L Disable local console, use remote console
-l Enable Layer 1 keepalive messages
-u UDP port base for distributed networks
-R Ignore options from the IOURC file
-U Disable unix: file system location
-W Disable watchdog timer
-N Ignore the NETMAP file

i have connected 3 iou devices as follow:

1:0/0 2:0/0
1:0/1 3:0/0
2:0/1 3:0/1

i basically made a triangle. device with ID 3 is a L3 image in particular:

Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version 15.4(1)T,

device with ID 2 and 1 are L2 images:

Cisco IOS Software, Linux Software (I86BI_LINUX-L2-UPK9-M), Experimental version 15.0

in all cases, cables are supposed to be connected, interface is unshut and link should be up, but, if L1 keepalive are on, they are always down

from gns3-server.

also, i verified using "regular" iou (regular netmap, not iouyap, using iouwrapper) , basically running the same topology by hand, and i confirm that L1 keepalive in this case works as expected.

I'm suspecting that the problem here might be primarily related to iouyap somehow. i am not sure how, but this "stinks" like iouyap playaround with netmaps and so forth...

from gns3-server.

Yep, that's a bummer, I was just expecting it to work. Well I will just leave the option in GNS3 for testing purposes only until we can figure it out and maybe have a workaround.

Thanks again.

from gns3-server.

FYI, here is the analysis of James, the iouyap's author. I don't think we can do much more, as I said I will leave the option for experimentation purpose only.

It looks like the IOU L1 keepalive mechanism is a Cisco work-in-progress. It uses valid IOU messages but it uses completely separate channels to transmit/receive them. When using domain sockets it not only uses different sockets but stores them in a completely separate directory! (Fire it up and take a peek in /tmp.) When using UDP it uses separate ports based above 50,000. It makes no sense to do it this way unless they are experimenting and want to make sure they didn't break anything else.

And this obviously is still a Cisco experimentation. I used anubisg1's NETMAP and the same exact IOU images. At first, it wasn't working and then for some reason it started to work fine and I couldn't break it. (I also didn't test very long.) But when I moved from domain sockets to UDP, it was a mess. The L2 images seemed to play nice together but the L3 was a disaster. It was only transmitting keepalive messages for e0/1 port and it was transmitting them to a UDP port without a listener. No good.

So I think L1 keepalive can be considered broken. Perhaps in the next release they'll have it debugged and using the same channel as the data packets. I just wish they hadn't put the option in the help message. I can see the incompatibility issues now. :(

When Cisco gets it straight we'll have to figure something out. It's a nice feature. But does Dynamips have anything like L1 keepalive messages to interface with?

from gns3-server.

thanks for the follow up.. in this case, i believe that all code regarding L1 keepalives should be removed, or at least hidden since is not working and we can't fix it yet

from gns3-server.

Thanks for your message.

We plan to use Linux bridges instead of uBridge in the future, would this change how L1 keepalives work?

from gns3-server.

Thank you for the prompt reply.
It depends on how frames are captured from the IOU instance and sent to the bridge. Similarly to frames, keepalives are only sent through UDP when a connection to a remote instance of IOU is configured in NETMAP for each specific interface. This is not the case with uBridge and will not be the case with any other local mechanism that retrieves the frames from IOU's UNIX socket. In any case, the mechanism over UDP ought to be similarly simple.

from gns3-server.

Just tested with UDP, activated when the remote port is specified in NETMAP using the remote hostname or IP, e.g., 1:0/0 2:0/[email protected] to connect port 0/0 of local instance 1 to port 0/0 of remote instance 2 running at 127.0.0.1.
The UDP sockets for sending frames and for sending layer 1 keepalives are bound to the IP address that the local hostname resolves to. Regarding ports, the port for frames is 49000+instance# (i.e., base_port+instance#) and the port for layer 1 keepalives is 50023+instance# (i.e., base_port+1023+instance#). The base port can be overriden.
The message format is exactly the same as using the UNIX sockets.

from gns3-server.

Regarding ports, the port for frames is 49000+instance# (i.e., base_port+instance#) and the port for layer 1 keepalives is 50023+instance# (i.e., base_port+1023+instance#).

This Layer 1 keepalive UDP port numbering scheme (UDP port base + 1023 + instance) is for L2 image.

L3 image uses "UDP port base + 1024 + instance".

Local                Address:PortProcess
192.168.1.11:49001   users:(("iou",pid=127263,fd=7))
192.168.1.11:50025   users:(("iou",pid=127263,fd=8))

192.168.1.11:49002   users:(("iou",pid=127310,fd=7))
192.168.1.11:50026   users:(("iou",pid=127310,fd=8))

192.168.1.11:49003   users:(("iou",pid=127327,fd=7))
192.168.1.11:50027   users:(("iou",pid=127327,fd=8))

192.168.1.11:49001   users:(("iou_l2",pid=127380,fd=7))
192.168.1.11:50024   users:(("iou_l2",pid=127380,fd=8))

192.168.1.11:49002   users:(("iou_l2",pid=127402,fd=7))
192.168.1.11:50025   users:(("iou_l2",pid=127402,fd=8))

192.168.1.11:49003   users:(("iou_l2",pid=127416,fd=7))
192.168.1.11:50026   users:(("iou_l2",pid=127416,fd=8))

So, if you want to interconnect L2 and L3 images via UDP, you have to set up some sort of UDP port forwarder. For example:

socat -x -u  UDP4-LISTEN:49002,bind=192.168.1.11,fork,reuseaddr  UDP4:192.168.1.11:59002
socat -x -u  UDP4-LISTEN:50026,bind=192.168.1.11,fork,reuseaddr  UDP4:192.168.1.11:60025
socat -x -u  UDP4-LISTEN:59001,bind=192.168.1.11,fork,reuseaddr  UDP4:192.168.1.11:49001
socat -x -u  UDP4-LISTEN:60024,bind=192.168.1.11,fork,reuseaddr  UDP4:192.168.1.11:50025

./iou -e 1 -s 0 -n 128 -m 512 -l 1
./iou_l2 -e 1 -s 0 -n 128 -c initial_l2_config.txt -m 512 -l -u 59000 2

Result:

192.168.1.11:59001   users:(("socat",pid=130275,fd=5))
192.168.1.11:59002   users:(("iou_l2",pid=130003,fd=11))
192.168.1.11:60024   users:(("socat",pid=129993,fd=5))
192.168.1.11:60025   users:(("iou_l2",pid=130003,fd=8))
192.168.1.11:49001   users:(("iou",pid=129998,fd=11))
192.168.1.11:49002   users:(("socat",pid=130270,fd=5))
192.168.1.11:50025   users:(("iou",pid=129998,fd=8))
192.168.1.11:50026   users:(("socat",pid=129944,fd=5))

Really, port forwarding for network frames (UDP port base + instance) is not needed for local communication (you can see no socat output), so when both images are on the same host (and connection is configured with @hostname in NMAP), they send L1 keepalive via UDP, but data traffic still uses UNIX domain sockets.

from gns3-server.

Also, IOU stops receiving L1 keepalives via UDP in case of reload. To reboot the router I have to kill the process and start it again.

Here is ss output after reload command. Recv-Q for the second (reloaded) router is not equal to 0:

State   Recv-Q  Send-Q  Local               Address:Port  Peer        Address:PortProcess
UNCONN  0       0       192.168.1.11:49001  0.0.0.0:*     users:(("iou",pid=130834,fd=7))
UNCONN  0       0       192.168.1.11:49002  0.0.0.0:*     users:(("iou",pid=131267,fd=9))
UNCONN  0       0       192.168.1.11:50025  0.0.0.0:*     users:(("iou",pid=130834,fd=8))
UNCONN  8064    0       192.168.1.11:50026  0.0.0.0:*     users:(("iou",pid=131267,fd=8))

from gns3-server.