Yeah. I wasn't too hopeful, but it seemed like an easy thing to rule out. The next thing I'd try is increasing the link timeout for discovery. This should reduce the amount of traffic. As you note, it doesn't seem like there really is much, but it's worth a shot. Pass something like --link-timeout=30 to openflow.discovery (the default is 10, I think).
-- Murphy On Jun 16, 2014, at 2:58 PM, Farzaneh Pakzad <f.pak...@uq.edu.au> wrote: > Hi, > > Thanks a lot for your reply. > > I changed the pox branch to dart. However, again I experienced packet_In > lost. As I mentioned before it seems the problem is on the receiver side. > According to the wireshark results, the LLDP packet is sent but not received > on the other side which is why there is no packet_In message from that switch > to the controller. > > Best regards, > Farzaneh > From: Murphy McCauley [murphy.mccau...@gmail.com] > Sent: Tuesday, 17 June 2014 5:41 AM > To: Farzaneh Pakzad > Cc: pox-dev@lists.noxrepo.org > Subject: Re: [pox-dev] loss of LLDP packets when running discovery.py > > My first answer is always to try a more recent version of POX (carp or dart) > and see if things are just magically better. > > -- Murphy > > On Jun 15, 2014, at 11:16 PM, Farzaneh Pakzad <f.pak...@uq.edu.au> wrote: > >> Hi all, >> >> I have been experiencing unexpected loss of LLDP packets when running >> discovery.py in POX, for different tree topologies in Mininet. >> The loss only starts to occur for a network size of more than ~20 switches, >> and seems to happen between a pair of switches. >> There is no other traffic on the network, and no other application running >> in POX. >> >> Below are some more details. >> >> I have made a tree topology with depth 5 and fanout 2 which means that we >> have 31 switches and 32 host. As I understand, in discovery.py the >> controller sends packet_out messages to all switches, instructing them to >> send a LLDP packet via each of its ports. When an LLDP packet is received by >> a switch at the other end of the link, the switch sends a packet_in message >> to the controller, and the controller can detect a link between these two >> switches/ports. >> >> Based on this, the controller should receive 2 packet_in messages for each >> link in the network, one for each direction. >> In my experiments, this works fine for small networks of < 20 switches. >> However, for larger networks, I’m starting to see a lower than expected >> number of packet_in messages received at the controller. >> For example in our example tree topology, the controller should receive 60 >> packet_in messages during a single topology discovery round, but >> consistently only gets 55-58. >> >> I’ve used wireshark to investigate where the packet loss occurs, and it >> looks like some LLDP packets are lost in transit between switches. >> >> An example is shown below. The first example shows a case without packet >> loss, i.e. we see the packet_out message, the corresponding LLDP packet at >> the sender side and at the receiver side, and the corresponding packet_in >> message. >> >> The case with both packet_out and In: >> OFP+LLDP 133 Packet Out (CSM) (67B) => Chassis Id = dpid:19 Port Id = >> 1 TTL = 120 >> LLDP 43 Chassis Id = dpid:19 Port Id = 2 TTL = 120 (sender side) >> LLDP 43 Chassis Id = dpid:19 Port Id = 2 TTL = 120 (reciever side) >> OFP+LLDP 127 Packet In (AM) (61B) => Chassis Id = dpid:19 Port Id = 2 >> TTL = 120 >> >> The following example shows the same thing, with the difference that the >> LLDP packet is sent but not received: >> >> The case that packet_In lost: >> OFP+LLDP 133 Packet Out (CSM) (67B) => Chassis Id = dpid:19 Port Id = >> 1 TTL = 120 >> LLDP 43 Chassis Id = dpid:19 Port Id = 2 TTL = 120 (sender side) >> >> As mentioned, there is no other traffic, and the load on each link is only 2 >> LLDP packets, one in each direction, and links are configured to be >> reliable, so as far as I understand, there should be no packet loss. >> >> I’m using the following software: >> >> Mininet version 2.0 >> POX version betta >> >> My questions is: Has anybody experienced similar problems, or does anybody >> have an idea of what the problem could be? >> Any help would be greatly appreciated. >> >> >> Best regards, >> Farzaneh
