On Apr 17, 2013, at 8:20 PM, 靳明双 wrote:
>
> I've been doing some work on Mininet but still confused on some issues below:
>
> 1. As we know,a controller, say POX, can set up a connection to a switch
> based
> on TCP,and then communicate with it using Openflow messages. Must the
> contrller connect to one or more switches directly? Is it able to control
> a switch
> via another switch?
Controlling a switch though another switch can be done. It's often referred to
as "in-band control". This doesn't generally apply to Mininet, though...
Mininet basically has a separate control network.
> 2.When the switches form a loop, how will the controller handle the
> connections
> and links?I create a topo in mininet:
Loops are only a problem if you make them a problem (that is to say if you
write or use control logic that forwards packets along loops). It most often
becomes a problem in systems that simply broadcast packets with unknown
destinations regardless of the topology. For the most part, fixing it requires
adding some topology awareness to your control logic.
POX has an openflow.spanning_tree component (inspired by Glen Gibb's one for
NOX) which tries to fix loops in a way that's agnostic to other components.
For example, you can use it along with l2_multi or l2_pairs.
> mininet> net
> c0
> s1 lo: s1-eth1:h1-eth0 s1-eth2:s2-eth2 s1-eth3:s3-eth3
> s2 lo: s2-eth1:h2-eth0 s2-eth2:s1-eth2 s2-eth3:s3-eth2
> s3 lo: s3-eth1:h3-eth0 s3-eth2:s2-eth3 s3-eth3:s1-eth3
> h1 h1-eth0:s1-eth1
> h2 h2-eth0:s2-eth1
> h3 h3-eth0:s3-eth1
>
> And then startup the POX controller,using the l2_multi component which will
> detect
> the links and calculate the shortest path between the nodes,here are the
> link detect
> INFOS, all correct:
>
> INFO:openflow.discovery:link detected: 00-00-00-00-00-02.3 ->
> 00-00-00-00-00-03.2
> DEBUG:openflow.discovery:Dropping LLDP packet 10915
> INFO:openflow.discovery:link detected: 00-00-00-00-00-02.2 ->
> 00-00-00-00-00-01.2
> INFO:openflow.discovery:link detected: 00-00-00-00-00-03.3 ->
> 00-00-00-00-00-01.3
> INFO:openflow.discovery:link detected: 00-00-00-00-00-03.2 ->
> 00-00-00-00-00-02.3
> INFO:openflow.discovery:link detected: 00-00-00-00-00-01.3 ->
> 00-00-00-00-00-03.3
> INFO:openflow.discovery:link detected: 00-00-00-00-00-01.2 ->
> 00-00-00-00-00-02.2
>
> and there exist many errors:
>
> ERROR:openflow.of_01:[Con 2/1] OpenFlow Error:
> [Con 2/1] Error: header:
> [Con 2/1] Error: version: 1
> [Con 2/1] Error: type: 1 (OFPT_ERROR)
> [Con 2/1] Error: length: 28
> [Con 2/1] Error: xid: 61
> [Con 2/1] Error: type: OFPET_BAD_REQUEST (1)
> [Con 2/1] Error: code: OFPBRC_BUFFER_EMPTY (7)
>
> I can't make it where the error come from.
Looped packets are running the switch out of buffers for packet_ins.
> and then,another problem is the path installed:
>
>
> DEBUG:forwarding.l2_multi:Installing path for 00:00:00:00:00:02 ->
> 00:00:00:00:00:01 0800 (2 hops)
>
> if the l2_multi component has calculated the shortest path ,shouldn't
> it just have 1 hop?
It's pretty common that links and the control channel become totally saturated
with looped packets causing discovery to decide the links are dead. That's
probably what you're seeing here.
> Any idea or comment would be highly appreciated.
Try again with the spanning_tree component.
-- Murphy
_______________________________________________
openflow-discuss mailing list
openflow-discuss@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
