links not shown in van sdn controller

[pman1]

Hello,

I use HP Network Simulator with gns3. I did a simple topology with 2 switches in HNS, and I put them in gns3 with 2 hosts.

Here is my configuration in HP Network Simulator:http://hpics.li/6b8e051

Here is the topology in gns3: http://hpics.li/c896895

Here is the config of the switch connected to the outside (the hp sdn controller) via the cloud: http://hpics.li/2007285 and http://hpics.li/7c47b82

My problem is that the switches are not linked in the controller : http://hpics.li/8686bf2

I can't see the hosts either, when I ping from host 1 to host 2. Pings are working between hosts and the packets are correctly sended throughout the switches.

Thanks for your help.

[ShaunWackerly]

Hi pman1,

Could you please show a few items from the VAN SDN controller? Specifically I'd like to see:

• the list of flows on each switch (OpenFlow Monitor -> Flows)
• the controller configuration (Configurations -> Basic -> com.hp.sdn.ctl.of.impl.ControllerManager)
• the link discovery configuration (Configurations -> Advanced -> com.hp.sdn.disco.of.link.impl.OpenflowLinkDiscoveryComponent)

I think the behavior you're seeing is caused by the BDDP/LLDP discovery packets either not being sent or not being stolen/received, but it will take more information to find root cause.

In addition, you may want to check the following link discovery guide to ensure your configuration matches what's recommended:

https://community.arubanetworks.com/aruba/attachments/aruba/SDN/45/1/HPN%20SDN%20Controller%20Link%20Discovery.pdf

Shaun

[pman1]

Thanks a lot for your answer.

Here is :

the list of flows on each switch  : http://hpics.li/6a07217 and http://hpics.li/94ad6c0

the controller configuration : http://hpics.li/7636f31

the link discovery configuration : http://hpics.li/2531c98

I think that the configuration matches what is recommended, but I'm not sure.

[ShaunWackerly]

Hi pman1,

From what I can tell, the data you've shown below looks correct. With the controller configuration shown, each switch should be instructed to generate a multicast BDDP packet every 10 seconds for each port. The BDDP packet should be redirected to the controller (via the default flows shown) where the controller will use the received BDDP packet to discover the link. This isn't happening, so we'll need to dig in deeper.

Would you be able to tear down the environment, start the following packet capture on the VAN SDN controller, and then initialize the simulated network while the packet capture is running? This would capture the complete control-plane conversation between the switches and controller.

tcpdump -i eth0 -w controlplane.pcap

(The above command assumes 'eth0' is the control-plane interface for your VAN SDN controller)

Also if you could attach your VAN SDN controller logs after the packet capture, that would be very helpful to identify what is happening on the VAN side. This packet capture will at least let us know whether the controller isn't generating the packets, or isn't receiving them, or isn't responding to them. I appreciate your continued patience.

Shaun

[pman1]

Hi Shawn,

I tried what you told me with tcpdump, but it doesn't give much result. I didn't know what the control-plane interface of my controller was, so I tried with loopback and eth1.

Here is tcpdump with eth1: https://ufile.io/n5et9

with loopback: https://ufile.io/vnflk

Here is a little schema for understanding: http://hpics.li/ce84b70

I've got two virtual machines that communicate with eth1. I use port forwarding to connect to localhost:8443.

I tried with mininet because it's maybe the same problem with my hp switches, it can maybe help.

If I use mininet on vm0 (controller), switches and hosts can ping. Links are shown on the controller.

But it's not working on vm1. They can't ping except if I put them on the same network as localhost (127.0.0.1). Links are not shown on the controller either way. Maybe I have to forward to 10.252.0.3 instead of localhost in my config?

As for the logs of mininet in the controller, there is one line that changes between what works and what not:

http://hpics.li/649fbd4

Here is the log of the switches on the controller: http://hpics.li/4cd7fed

I don't know how to configure snmp on the controller, I only configured snmp for Intelligent Management Center (if it can help, on IMC, links are shown between hp switches in the normal topology, but not on the openflow topology in the sdn module).

Sorry for my very long message, and thanks for the great help.

Pierre

[ShaunWackerly]

Hi Pierre,

I forgot to mention that the 'tcpdump' command I posted will log all of the captured packets into a file named controlplane.pcap. Therefore, on-screen you're seeing the summary (how many packets were captured) but the actual data is contained in the controlplane.pcap file. I think we'd need you to upload that file as an attachment, because posting a screenshot of it wouldn't give the whole picture. You can attach the file if you compress it as a .zip file, I believe.

SNMP key management in the controller is performed via the REST API. You can read about it under the "Managing SNMP keys" section of the VAN SDN Controller Administrator Guide. In the 2.7 version, this is on pages 179-180.

Shaun

[pman1]

Hi Shaun,

I tried to configure snmp keys as you say, but it doesn't seem to work, is there something wrong with my config?

the config on my switches:

the config of the key in the controller:

Here is the pcap file (you can't attach zip files so I uploaded it in google drive) : https://drive.google.com/file/d/0B4o1SizkAY56WlVxdDZSdk1SN0k/view?usp=sharing

(10.252.0.6 is the ip address of IMC, 10.252.0.3 is the ip address of the controller, and 10.252.0.102 and 10.252.0.103 are the ip address of the switches' vlans)

Pierre

[ShaunWackerly]

Hi Pierre,

I'm not very familiar with Comware configuration, but looking at the data you linked in the first entry, it looks like the port you're using to connect the two switches is port 2 (GigabitEthernet1/0/2). If I'm reading the configuration correctly, this port is configured to use VLAN tags for vlans 1-2 and to use untagged packets for vlan 999. Am I reading that configuration correctly? I'm confused because the topology you showed has the switches connected on "e1/0" which isn't shown in the configuration at all.

If there's an port whose native/untagged VLAN is a member of the OpenFlow instance AND that port connects two Comware switches together, the link should be discovered. However, if the native/untagged vlan for the port is not a member of the OpenFlow instance, then you'll need to configure the link discovery vlan for the device. If that's the case, then you might need to use the solution described here (let me know if you need more detail):

http://community.arubanetworks.com/t5/Software-Defined-Networking-SDN/Can-SDN-work-with-Openflow-and-STP/td-p/299889

Essentially, you'll need to use the REST API to configure the link discovery vlan you'll use for each device. Once that is configured, the link discovery packets for that device will then include a vlan tag (normally they're untagged):

https://CONTROLLER-IP:8443/sdn/v2.0/net/devices/<00:01:2c:23:3a:34:1e:4d>/linkDiscoveryVlan/<2307>

Shaun

[pman1]

Hi Shaun,

port 2 (GigabitEthernet1/0/2). corresponds to e1/0, port 3 (GigabitEthernet1/0/3). corresponds to e2/0, etc .... so you read the configuration correctly.

Can you explain how to use link discovery vlan for my config?

Here are the ports shown in the controller for each switch:

For the first switch, I tried:

curl  --header "X-Auth-Token: 7985aa5cb5c3429f99533c7bb5fc3674 " --header "Content-Type:application/json" -ksS --request POST --url https://localhost:8443/sdn/v2.0/net/devices/<00:02:00:e0:02:00:00:00>/linkDiscoveryVlan/<1605>

but for the second switch, I don't understand because no vlan is displayed in the openflow ports.

One more thing that bothers me is that each port of the switches had the same hardware address (I discovered that recently so I didn't show it in the config) so I changed it. Is it normal?

Pierre

[ShaunWackerly]

Hi Pierre,

My apologies for the delayed response. The parameter to the linkDiscoveryVlan REST API is the actual VLAN ID itself, not the OpenFlow port number corresponding to the VLAN ID. Therefore, you'd want to specify 2 (not 1605) as the linkDiscoveryVlan, because the inter-switch link is tagged for vlan 1 and vlan 2 and untagged for vlan 999, but only vlan 2 is part of the OpenFlow instance.

I think you'd want to make the following two requests (one for each switch):

curl  --header "X-Auth-Token: 7985aa5cb5c3429f99533c7bb5fc3674 " --header "Content-Type:application/json" -ksS --request POST --url https://localhost:8443/sdn/v2.0/net/devices/<00:02:00:e0:02:00:00:00>/linkDiscoveryVlan/2

curl  --header "X-Auth-Token: 7985aa5cb5c3429f99533c7bb5fc3674 " --header "Content-Type:application/json" -ksS --request POST --url https://localhost:8443/sdn/v2.0/net/devices/<00:02:00:e0:03:00:00:00>/linkDiscoveryVlan/2

Regarding the port MAC addresses, typically the port's MAC address is different from the system base MAC address so that port-level communication (LLDP) can be distinguished from system-level communication. In this case, I don't think it would affect the link discovery outcome.

Shaun

PS: Here is a link to the VAN SDN controller REST API guide. The linkDiscoveryVlan API is discussed on pages 141-142.
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c05040230