virtual interface names too long

[GoogleCodeExporter]

Linux seems to only support up to 
16 bytes long names (possibly including null byte), but the vif code 
often generates longer names:

Error: argument "peer" is wrong: "name" too long

Exception in thread Thread-10:
Traceback (most recent call last):
   File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
     self.run()
   File "/usr/lib/python2.7/threading.py", line 763, in run
     self.__target(*self.__args, **self.__kwargs)
   File "/home/netemul/core-scripts/test-grund.py", line 41, in <module>
     n3.newnetif(link1, addrlist=["172.20.0.54/16"], ifindex=0)
   File "/usr/lib/python2.7/dist-packages/core/netns/vnode.py", line 
275, in newnetif
     net = net)
   File "/usr/lib/python2.7/dist-packages/core/netns/vnode.py", line 
177, in newveth
     mtu = 1500, net = net, start = self.up)
   File "/usr/lib/python2.7/dist-packages/core/netns/vif.py", line 32, 
in __init__
     self.startup()
   File "/usr/lib/python2.7/dist-packages/core/netns/vif.py", line 36, 
in startup
     "type", "veth", "peer", "name", self.name])
   File "/usr/lib/python2.7/dist-packages/core/misc/utils.py", line 73, 
in check_call
     return subprocess.check_call(*args, **kwds)
   File "/usr/lib/python2.7/subprocess.py", line 540, in check_call
     raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '['/sbin/ip', 'link', 'add', 'name', 
'veth25653.0.248', 'type', 'veth', 'peer', 'name', 'veth25653.0.1.248']' 
returned non-zero exit status 255

I worked around this by limiting session and object IDs to three digits 
each. See the attached session_ids.diff

Original issue reported on code.google.com by ahrenh...@gmail.com on 21 Aug 2014 at 2:37

Attachments:

• session_ids.diff

[GoogleCodeExporter]

Thread is here:
http://pf.itd.nrl.navy.mil/pipermail/core-users/2014-August/001641.html

Another workaround is to specify node numbers when creating nodes, so their 
object IDs are not longer random numbers.

Original comment by ahrenh...@gmail.com on 25 Aug 2014 at 10:09

[GoogleCodeExporter]

Thanks for the fix. I had thought that we could get more by using the id as Hex 
by format(id, '03x').

This works and gives potential for 4096 nodes. However it seems that vnoded has 
a limit anyway. I ran the howmanynodes.py script to see how far I got and with 
using hex id I only get to 1012 nodes anyway as vnoded is running in to kernel 
limits on the number of open files.

Does vnoded have to keep all the files open or could it open or close when 
needed? I had plenty of memory left when I hit 1012 so I think my system would 
handle more.

Original comment by stuartma...@gmail.com on 5 Sep 2014 at 10:06

[GoogleCodeExporter]

I have found if you change the ulimit for root that I can create at least 4000 
nodes. I used howmanynodes.py after setting the ulimit to 4096 and managed to 
create 4000 nodes. I also had to limit the number of nodes per bridge.

Attached is a slight variation on the patch which uses hex id's so that 3 
digits allows up to 4096. In theory could use base 36 and get 46656 nodes in 3 
digits but would have to write a helper function for that as base 36 is not in 
Python by default.

Original comment by stuartma...@gmail.com on 5 Sep 2014 at 10:57

Attachments:

• session_ids.diff

[GoogleCodeExporter]

fixed in r601

use interface names "vethOOOOO.ii.ss" and "vethOOOOO.iipss" for veth pairs

(where OOOOO = object id, ii = interface index, ss = hex short session ID)

1 byte shorter by using hex value for the short session ID used in naming 
interfaces (e.g. "fa" vs "250").

2 bytes shorter by using "p" (for "peer") between interface index and short 
session ID instead of ".1."

this should allow for up to 65535 nodes with up to 100 interfaces

Original comment by ahrenh...@gmail.com on 28 Oct 2014 at 9:24

• Changed state: Fixed