Complaints when pinging

[esnet]

Complaints when pinging

[bmah888]

Have been doing some investigating with this. After dumping out some of the properties from denv-tb-of-1 (hw below) and denv-ovs (sw below) I've discovered a couple of interesting things.

>>> print hw.props                     
{'pop': denv, 'ports': {'1': Port(name=1), '2': Port(name=2), '24': Port(name=24), '23': Port(name=23)}, 'toCorePorts': {'24': Port(name=24), '23': Port(name=23)}, 'controller': org.python.proxies.layer2.odl.client$ODLClient$263@4a4d22da, 'sitePortIndex': {'lbl.gov': Port(name=24)}, 'domain': 'es.net', 'role': 'HwSwitch', 'wanPortIndex': {'amst': Port(name=23), 'aofa': Port(name=23), 'atla': Port(name=23), 'wash': Port(name=23), 'star': Port(name=23), 'cern': Port(name=23)}, 'toSwPorts': {Port(name=2): Port(name=2), Port(name=1): Port(name=1)}, 'dpid': array('B', [2, 1, 0, 100, 101, 110, 118, 1]), 'links': [denv-tb-of-1:1:denv-ovs:eth10, denv-ovs:eth10:denv-tb-of-1:1, denv-ovs:eth11:denv-tb-of-1:2, denv-tb-of-1:2:denv-ovs:eth11, denv-tb-of-1:2:denv-ovs:eth11, denv-ovs:eth11:denv-tb-of-1:2, denv-tb-of-1:24:denv-cr5:9/1/5, denv-cr5:9/1/5:denv-tb-of-1:24, denv-cr5:9/1/5:denv-tb-of-1:24, denv-tb-of-1:24:denv-cr5:9/1/5, denv-ovs:eth10:denv-tb-of-1:1, denv-tb-of-1:1:denv-ovs:eth10, denv-cr5:9/1/4:denv-tb-of-1:23, denv-tb-of-1:23:denv-cr5:9/1/4, denv-tb-of-1:23:denv-cr5:9/1/4, denv-cr5:9/1/4:denv-tb-of-1:23], 'stitchedPortIndex': {'1': Port(name=23), '2': Port(name=24), '24': Port(name=2), '23': Port(name=1)}}
>>> print hw.props['stitchedPortIndex']
{'1': Port(name=23), '2': Port(name=24), '24': Port(name=2), '23': Port(name=1)}
>>> print sw.props
{'pop': denv, 'ports': {'eth11': Port(name=eth11), 'eth10': Port(name=eth10)}, 'controller': org.python.proxies.layer2.odl.client$ODLClient$263@4a4d22da, 'toHwPorts': [Port(name=eth10), Port(name=eth11)], 'sitePortIndex': {'lbl.gov': Port(name=eth10)}, 'domain': 'es.net', 'role': 'SwSwitch', 'wanPortIndex': {'amst': Port(name=eth10), 'aofa': Port(name=eth10), 'atla': Port(name=eth10), 'wash': Port(name=eth10), 'star': Port(name=eth10), 'cern': Port(name=eth10)}, 'vmPort.WAN': None, 'dpid': array('B', [1, 2, 0, 100, 101, 110, 118, 1]), 'links': [denv-tb-of-1:1:denv-ovs:eth10, denv-ovs:eth10:denv-tb-of-1:1, denv-ovs:eth11:denv-tb-of-1:2, denv-tb-of-1:2:denv-ovs:eth11, denv-tb-of-1:2:denv-ovs:eth11, denv-ovs:eth11:denv-tb-of-1:2, denv-ovs:eth10:denv-tb-of-1:1, denv-tb-of-1:1:denv-ovs:eth10], 'vmPort': None}
>>> print sw.props['sitePortIndex']
{'lbl.gov': Port(name=eth10)}

1. The lbl.gov site is attached on denv-tb-of-1 port 24. From the stitchedPortIndex property, traffic received on port 24 that needs to go the software switch should be output on port 2. It then shows up on denv-ovs port eth11. But denv-ovs is expecting traffic from lbl.gov to arrive on port eth10. I'm wondering if denv-tb-of-1's stitchedPortIndex property is being computed correctly since it seems like the PACKET_OUT to denv-tb-of-1 port 2 is out of scope, and then when the broadcast packet arrives on denv-ovs port eth11, that's also out of scope. Like we shouldn't be putting traffic on the link between those two ports.
2. The links properties on both denv-tb-of-1 and denv-ovs are very long. I see the computation for bidirectional links, but it looks like the "add bidirectional links" part might have been done twice. For example denv-ovs has two wires between it and denv-tb-of-1, yet its links property has 8 elements in it.

[bmah888]

This issue has been overtaken by events, notably the complete rewrite of the VPN code.

Closing.