Exactly, this version is what would make sense to me too :> (And I also doubt NOX currently does what the page claims)
On Thu, Jul 14, 2011 at 5:50 PM, Murphy McCauley <jam...@nau.edu> wrote: > Okay, I just read that page, and... you're right, that's definitely what it > says. It seems to indicate that what it's talking about there is what is > "currently implemented in Nox's discovery.py". I think this is false. I > won't completely swear to this, but I did just rewrite discovery like two > weeks ago, so I was all through that code and I am pretty sure there's > nothing in there that forwards LLDP. And pyswitch and authenticator both > bail as soon as they see that the ethertype is 88cc, so neither pyswitch nor > routing should be forwarding them either. And, you know, I have never > actually observed this in Wireshark (not that I have been looking for it!). > > I don't immediately see why this would be a good idea anyway. 1) NOX > doesn't need to forward advertisements to spread its info since it already > gets it all centrally, 2) OFDP-style advertisements for non-neighbor > switches would probably be either meaningless or confusing to non-OF > switches, and 3) doing this would make it much harder to actually figure out > the direct-neighbor relationships anyway. > > So, yeah. I don't think NOX works exactly how that page describes. If it > SHOULD be working that way, hopefully someone will explain why. > > What I think that document should actually say to describe how NOX > presently works is along the lines of: > > Switch O (Openflow-enabled) OFDP advertisements out all ports. > Switch A (not OpenFlow-enabled) will forward the received OFDP > advertisements out all other ports. > Switch B (OpenFlow-enabled) will update it's internal connectivity > information. Switch B will *not* forward the OFDP advertisement. > > That is, only Switch A really changes behavior. And: > > The Take Away > All Switches in a layer-2 network receive OFDP advertisements from their > "OpenFlow neighbors" (these may be directly connected OpenFlow switches, or > they may be the closest OpenFlow switch via one or more intermediate > non-OpenFlow switches). > OFDP's EtherType is 0x88cc. > OFDP advertisements are sent to a "normal" multicast MAC > (01:23:00:00:00:01). > OFDP is Advertisement only. > Non-OpenFlow Switches will forward OFDP advertisements. > OpenFlow Switches will not forward OFDP advertisements. > > -- Murphy > > On Jul 14, 2011, at 1:56 PM, Kyriakos Zarifis wrote: > > Hm. That was my impression too, but now looking at the doc again, the > phrase "confused me. > > > 2011/7/14 Murphy McCauley <jam...@nau.edu> > >> So the normal LLDP multicast address should never be forwarded. No >> problem there except that NOX couldn't "see through" intermediate switches >> there. >> >> On the other hand, with the OFDP address... OpenFlow switches still won't >> forward such messages (NOX looks at them in discovery, but never instructs >> the switches to forward them). But non-OF switches will forward them (as >> far as I understand it, this is the entire point -- so that NOX can "see >> through" such switches). So yes, these messages may be broadcast by non-OF >> hardware on the non-OF portion of their network (always stopping when they >> hit an OF switch), but it's not actually any worse than any other broadcast >> like an ARP. The non-OF portion of the network probably already has to be >> capable of dealing with broadcasts (via STP or looplessness or whatever) or >> you have big problems anyway. Right? >> >> -- Murphy >> >> On Jul 14, 2011, at 1:29 PM, kk yap wrote: >> >> > Oops.. I read the GENI document again, and Murphy is right in that the >> > multicast address is different here. My apologies. >> > >> > This address will be forwarded by mac bridges though. Won't this be >> > risking a broadcast storm? Am I missing something again? >> > >> > Regards >> > KK >> > >> > >> > On 14 July 2011 13:23, kk yap <yap...@stanford.edu> wrote: >> >> I believe OFDP uses LLDP as Kyriakos mentioned. So, there is no real >> >> difference here. >> >> >> >> As for the question of discovering a "link" between two OpenFlow >> >> switches connected by a non-OpenFlow switch, the link will be >> >> discovered if the switch does not process LLDP and thus pass it on. >> >> Else, the intermediate switch will consume the LLDP packet. >> >> >> >> For discovery of only OpenFlow switches, it might be best to use a >> >> packet with multicast address (and possibly ethertype) that is >> >> different from LLDP (i.e., 802.11ab). The change is not hard but note >> >> the consequences. >> >> >> >> Just my two cents worth. >> >> >> >> Regards >> >> KK >> >> >> >> 2011/7/14 Murphy McCauley <jam...@nau.edu>: >> >>> Right. Someone correct me if I am wrong here, but really the only >> >>> difference between OFDP and normal LLDP is that OFDP uses a normal >> multicast >> >>> address so that it can see connectivity across non-OpenFlow switches. >> >>> The purpose being... if you have two OpenFlow switches connected via >> an >> >>> intermediate non-OpenFlow switch, using normal LLDP, you couldn't tell >> that >> >>> the two OpenFlow switches were connected because the intermediate >> switch >> >>> would not forward the LLDP packet. "OFDP" style LLDP *does* get >> forwarded >> >>> by the intermediate, so you *can* tell that the two OpenFlow switches >> are >> >>> connected. >> >>> -- Murphy >> >>> On Jul 14, 2011, at 1:45 AM, Kyriakos Zarifis wrote: >> >>> >> >>> OFDP is a made-up term used to describe how OF uses LLDP packets to >> perform >> >>> discovery. There is no such thing as an OFDP packet. The packets used >> for >> >>> discovery are LLDP packets. >> >>> On Thu, Jul 14, 2011 at 4:32 AM, wunyuan <wuny...@nchc.narl.org.tw> >> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> Thanks for your answer. >> >>>> >> >>>> We observe the information from this URL >> >>>> (http://groups.geni.net/geni/wiki/OpenFlowDiscoveryProtocol) >> >>>> >> >>>> this information is that OFDP advertisements are sent to a "normal" >> >>>> multicast MAC (01:23:00:00:00:01), and we find our openflow switch >> send the >> >>>> lldps to this mac. >> >>>> >> >>>> We guess the discovery is the OFDP first. >> >>>> >> >>>> We think our guess may be wrong after we see the discovery.py code. >> >>>> >> >>>> Therefore, we are not sure that the discovery is the LLDP or the OFDP >> now. >> >>>> >> >>>> Bests, >> >>>> >> >>>> Wun-Yuan >> >>>> >> >>>> >> >>>> >> >>>> 於 2011/7/14 下午 04:03, Kyriakos Zarifis 提到: >> >>>> >> >>>> Hi, >> >>>> I'm not sure if I understand the question, but Discovery uses LLDP >> >>>> packets. >> >>>> Short description here: >> >>>> http://noxrepo.org/noxwiki/index.php/Discovery >> >>>> >> >>>> On Thu, Jul 14, 2011 at 3:43 AM, wunyuan <wuny...@nchc.narl.org.tw> >> wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> We have a question about the nox discovery. >> >>>>> >> >>>>> Our NOX version is NOX 0.9.0(zaku) in our openflow enviroment. >> >>>>> >> >>>>> We monitor a port of a openflow by wireshark, and we observe that >> the >> >>>>> lldp packets are sent to a multicast MAC (01:23:00:00:00:01). >> >>>>> >> >>>>> However we see the discovery.py code and find that it isn't like >> the >> >>>>> OFDP. >> >>>>> >> >>>>> We also monitor the ports of the other OF switch not >> directly-connected >> >>>>> above openflow switches, but we only see the lldp packets sent by >> itself and >> >>>>> the lldp packets receviced from neighbor. >> >>>>> >> >>>>> The discovery seem the LLDP. >> >>>>> >> >>>>> Which one is the discovery, the LLDP or OFDP? >> >>>>> >> >>>>> Thanks. >> >>>>> >> >>>>> Wun-Yuan >> >>>>> _______________________________________________ >> >>>>> nox-dev mailing list >> >>>>> nox-dev@noxrepo.org >> >>>>> http://noxrepo.org/mailman/listinfo/nox-dev >> >>>> >> >>>> >> >>> >> >>> _______________________________________________ >> >>> nox-dev mailing list >> >>> nox-dev@noxrepo.org >> >>> http://noxrepo.org/mailman/listinfo/nox-dev >> >>> >> >>> >> >>> _______________________________________________ >> >>> nox-dev mailing list >> >>> nox-dev@noxrepo.org >> >>> http://noxrepo.org/mailman/listinfo/nox-dev >> >>> >> >>> >> >> >> >> > >
_______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
