Opened 8 years ago

Closed 8 years ago

#14 closed (fixed)

Four node ring topology results in all interface having 1 address

Reported by: lnevers@bbn.com Owned by: somebody
Priority: major Milestone:
Component: AM Version: SPIRAL4
Keywords: AM API Cc:
Dependencies:

Description

Created a sliver with a 4 node ring to topology without problem. The Rspec, which is attached, requests the following: VM<-lan1->VM1<-lan0-> VM2 <-lan2-> VM0 <-lan3 -> VM

The sliver manifest seems to shows the expected topology, but logging into each of the 4 hosts shows that all node have to dataplane interface (eth1& eth2) configured with the same address 172.16.1.1. Following is a capture of the interface configured on each node.

root@192.1.242.31:

eth0      Link encap:Ethernet  HWaddr 02:16:3e:4e:ad:82  
          inet addr:10.103.0.19  Bcast:10.103.0.255  Mask:255.255.255.0
          inet6 addr: fe80::16:3eff:fe4e:ad82/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:162 errors:0 dropped:0 overruns:0 frame:0
          TX packets:145 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:24867 (24.2 KiB)  TX bytes:19286 (18.8 KiB)

eth1      Link encap:Ethernet  HWaddr 52:54:00:99:25:74  
          inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe99:2574/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:514 (514.0 B)  TX bytes:398 (398.0 B)

eth2      Link encap:Ethernet  HWaddr 52:54:00:bf:7d:ef  
          inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:febf:7def/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:762 (762.0 B)  TX bytes:398 (398.0 B)

root@192.1.242.32:

eth0      Link encap:Ethernet  HWaddr 02:16:3e:23:5f:20  
          inet addr:10.103.0.20  Bcast:10.103.0.255  Mask:255.255.255.0
          inet6 addr: fe80::16:3eff:fe23:5f20/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:448 errors:0 dropped:0 overruns:0 frame:0
          TX packets:397 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:47565 (46.4 KiB)  TX bytes:43042 (42.0 KiB)

eth1      Link encap:Ethernet  HWaddr 52:54:00:73:43:83  
          inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe73:4383/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1858 (1.8 KiB)  TX bytes:398 (398.0 B)

eth2      Link encap:Ethernet  HWaddr 52:54:00:fc:99:34  
          inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fefc:9934/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1022 (1022.0 B)  TX bytes:398 (398.0 B)

ssh root@192.1.242.30:

eth0      Link encap:Ethernet  HWaddr 02:16:3e:14:f6:cf  
          inet addr:10.103.0.18  Bcast:10.103.0.255  Mask:255.255.255.0
          inet6 addr: fe80::16:3eff:fe14:f6cf/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:213 errors:0 dropped:0 overruns:0 frame:0
          TX packets:194 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:32623 (31.8 KiB)  TX bytes:27052 (26.4 KiB)

eth1      Link encap:Ethernet  HWaddr 52:54:00:a5:a9:b6  
          inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fea5:a9b6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1858 (1.8 KiB)  TX bytes:398 (398.0 B)

eth2      Link encap:Ethernet  HWaddr 52:54:00:3f:bd:ed  
          inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe3f:bded/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:16 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:952 (952.0 B)  TX bytes:398 (398.0 B)

root@192.1.242.33:

eth0      Link encap:Ethernet  HWaddr 02:16:3e:3b:62:60  
          inet addr:10.103.0.21  Bcast:10.103.0.255  Mask:255.255.255.0
          inet6 addr: fe80::16:3eff:fe3b:6260/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:240 errors:0 dropped:0 overruns:0 frame:0
          TX packets:209 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:35576 (34.7 KiB)  TX bytes:29206 (28.5 KiB)

eth1      Link encap:Ethernet  HWaddr 52:54:00:25:71:1b  
          inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe25:711b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1726 (1.6 KiB)  TX bytes:378 (378.0 B)

eth2      Link encap:Ethernet  HWaddr 52:54:00:14:ef:34  
          inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe14:ef34/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1726 (1.6 KiB)  TX bytes:398 (398.0 B)

Attachments (3)

exo-4vm-ring.rspec (3.4 KB) - added by lnevers@bbn.com 8 years ago.
exoa-rspec-bbn-hn-exogeni-net-11443-orca.xml (6.6 KB) - added by lnevers@bbn.com 8 years ago.
exo-4vm-ring-wIP.rspec (3.9 KB) - added by lnevers@bbn.com 8 years ago.

Download all attachments as: .zip

Change History (17)

Changed 8 years ago by lnevers@bbn.com

Attachment: exo-4vm-ring.rspec added

Changed 8 years ago by lnevers@bbn.com

comment:1 Changed 8 years ago by ibaldin@renci.org

You probably did not configure any IP address for those interfaces in the RSpec...

This is a known bug though - they should've been left unconfigured (present, but unconfigured).

comment:2 Changed 8 years ago by lnevers@bbn.com

Right! I had not specified the IP addresses in the request Rspec. I am trying to use the RSpecs as used in PG.

I did not realize this is a know issue. Is there a list that I can check out to know what the known issues are?

Agree. Unconfigured is better than misconfigured! :-)

comment:3 Changed 8 years ago by lnevers@bbn.com

ARGHH, I have modified the ring topology rspec to include IP addresses for each interface (file attached), but now I cannot create a sliver, I get the Other Exception: java.lang.Exception: ERROR: Unknown slice urn failure whether I use the RSpec with the IP addresses or the old one without the IP address.

Did I mess up the broker again?

comment:4 Changed 8 years ago by ibaldin@renci.org

System appears fine. Did you use this

<interface client_id="geni1:0">

<ip address="172.16.1.1" netmask="255.255.0.0" />

</interface>

under <node>?

It should work.

Changed 8 years ago by lnevers@bbn.com

Attachment: exo-4vm-ring-wIP.rspec added

comment:5 Changed 8 years ago by lnevers@bbn.com

I am attaching the RSpec with the IP addresses (http://groups.geni.net/exogeni/attachment/ticket/14/exo-4vm-ring-wIP.rspec)

I do have an IP address defined for each of the 2 interface within each node definition.

comment:6 Changed 8 years ago by ibaldin@renci.org

You're running out of resources. Let go of the other slices.

comment:7 Changed 8 years ago by ibaldin@renci.org

Next time this happens switch to using ExoSM on https://geni.renci.org:11443/orca/xmlrpc and be sure to explicitly bind the resources to BBN. Remember we only have a capacity of 36 VMs I think at this point and most of it is allocated to ExoSM (as per previous discussion with GPO the split is no longer 50/50).

There is really no reason to use the AM on the rack other than for adherence to AM API model. ExoSM will do the same thing (if resources are bound) and it has more resources at its disposal.

comment:8 Changed 8 years ago by lnevers@bbn.com

Re-ran the createsliver on the ExoSM and same failure:

$ ./src/omni.py -a exosm createsliver exoa ./exo-4vm-ring-wIP.rspec  
INFO:omni:Loading config file omni_config
INFO:omni:Using control framework pgeni
WARNING:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+exoa expires in <= 3 hours
INFO:omni:Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+exoa expires on 2012-05-02 21:17:21 UTC
INFO:omni:Substituting AM nickname exosm with URL https://geni.renci.org:11443/orca/xmlrpc, URN unspecified_AM_URN
INFO:omni:Substituting AM nickname exosm with URL https://geni.renci.org:11443/orca/xmlrpc, URN unspecified_AM_URN
INFO:omni:Creating sliver(s) from rspec file ./exo-4vm-ring-wIP.rspec for slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+exoa
INFO:omni:Asked https://geni.renci.org:11443/orca/xmlrpc to reserve resources. Result:
INFO:omni:<!-- Reserved resources for:
	Slice: exoa
	At AM:
	URL: https://geni.renci.org:11443/orca/xmlrpc
 -->
INFO:omni: ------------------------------------------------------------
INFO:omni: Completed createsliver:

  Options as run:
		aggregate: exosm
		framework: pgeni
		native: True

  Args: createsliver exoa ./exo-4vm-ring-wIP.rspec

  Result Summary: Slice urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+exoa expires in <= 3 hours on 2012-05-02 21:17:21 UTC
Asked https://geni.renci.org:11443/orca/xmlrpc to reserve resources. No manifest Rspec 
returned. Other Exception: java.lang.Exception: ERROR: Unknown slice urn urn:publicid:IDN+pgeni.gpolab.bbn.com+slice+exoa 
INFO:omni: ============================================================

The RSpec is already attached, and it passes rspeclint

comment:9 Changed 8 years ago by ibaldin@renci.org

There was still a slice open on it. I closed it and freed the resources, however something is not right - I can create a 2-node slice, but not a 4-node one. We will look into it.

comment:10 in reply to:  9 Changed 8 years ago by lnevers@bbn.com

Replying to ibaldin@renci.org:

There was still a slice open on it. I closed it and freed the resources, however something is not right - I can create a 2-node slice, but not a 4-node one. We will look into it.

Has the issue above been resolved?


Also back to the original issue for this ticket.

I again ran into the "same address on all interfaces" problem when I ran the topology:

  • 2 VM nodes on lan1
  • 2 VM nodes on lan2
  • 1 of the nodes from lan1 is connected via lan3 to 1 of the nodes on lan2.

Just noting that the configuration of interface addresses is tedious for the experimenter. Also noting that there is a difference in behaviour between InstaGENI and ExoGENI. The PG aggregate will configure the interface for the user if no address is specified, which is much more user-friendly.

comment:11 Changed 8 years ago by ibaldin@renci.org

Automatic addition of IP addresses to the request is a feature that will be available in Flukes. We assume geni tools will do similar. Simply automatically configuring an interface if the user didn't specify it is not a good option, since this would complicate non IP-based experiments.

Interfaces with unspecified IP addresses will be present but unconfigured once the bug is fixed.

comment:12 Changed 8 years ago by lnevers@bbn.com

I just happene to check on this issue so updating the ticket. No change in behavior.

It is still the case that if IP addresses are not specified for the interfaces in an rspec. All interface still get the same address.

comment:13 Changed 8 years ago by ibaldin@renci.org

THis has not been fixed. You'd think it'd be easy. We can't find the place in the pipeline where the default assignment occurs. Will get fixed at next redeploy (in 2 weeks)

comment:14 Changed 8 years ago by lnevers@bbn.com

Resolution: fixed
Status: newclosed

Checked on this issue and it is resolved. When an interface is defined in the RSpec without an IP Address, the results is the interface is available and it not configured.

Note: See TracTickets for help on using tickets.