On Nov 27, 2012, at 9:55 PM, shashaankar reddy wrote: > Consider port_grouping policy set for any of the switch (with ten ports) in > the network: > ---If the policy for port_groups is defined: [1,2,3,4,5], [6,7,8,9,10] > <<Before config.update()>> > port_groups [[1,2,3,4,5,6,7,8,9,10]] > <<After config.update()>> > port_groups = [[1,2,3,4,5],[6,7,8,9,10]] > > --if the policy for port_groups is defined: [[]] # blank > <<Before config.update()>> > port_groups [[1,2,3,4,5,6,7,8,9,10]] > <<After config.update()>> > port_groups = [[]] > > The second case is what happened in my case.
Right, this was as intended -- it fills in a default group if you hadn't specified anything. If you explicitly specified something, it uses what you specified (even if that was explicitly specifying no groups). > But somehow the only issue I could not understand is, sometimes I receive the > packet_in message from the openVswitch with the switch physical port as > 65534, this I have seen in the log messages when printed the even.port which > leads to the packet being dropped as it doesn't belong to any of the switch > groups from the config file. I could see this issue frequently but sometimes > it doesn't show up!! strange ? > http://openvswitch.org/cgi-bin/ovsman.cgi?page=vswitchd%2Fovs-vswitchd.8 > this link provides some info regarding the 65534 which is used as a local > port in openVswitch. This is the OFPP_LOCAL port, which is defined in the spec. It's connected to the interface that the vswitch adds (e.g., dp0). What you are seeing coming from that port is probably IPv6 neighbor discovery (rfc4861) coming from the host Linux environment. Dropping it shouldn't be problematic -- you probably don't really WANT that stuff leaking on to the other ports. I have actually wondered if this is a bug in Linux, because this happens even when the local interface is down. At any rate, glad you got it working. -- Murphy
