Opened 12 years ago
Closed 12 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)
Change History (17)
Changed 12 years ago by
| Attachment: | exo-4vm-ring.rspec added |
|---|
Changed 12 years ago by
| Attachment: | exoa-rspec-bbn-hn-exogeni-net-11443-orca.xml added |
|---|
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
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 12 years ago by
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 12 years ago by
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 12 years ago by
| Attachment: | exo-4vm-ring-wIP.rspec added |
|---|
comment:5 Changed 12 years ago by
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:7 Changed 12 years ago by
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 12 years ago by
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 follow-up: 10 Changed 12 years ago by
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 Changed 12 years ago by
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 12 years ago by
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 12 years ago by
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 12 years ago by
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 12 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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.
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).