I tried to recreate the experiment you describe, and it seems to work fine:
http://www.noxathome.org/x/Murphy/l2_multi3.png

Where am I going wrong?


Note that depending on configuration, discovery and l2_multi may require a 
little time after startup before things will work (for a complete round of 
discovery to complete, etc.).


I don't know which version of POX you're running since you haven't posted your 
log.  If you're running betta, you might consider trying carp or dart.  You 
might also try other things listed on the last entry of the FAQ (see the POX 
manual).


Other responses inline...

On Oct 24, 2013, at 3:55 PM, AMER <[email protected]> wrote:

> I have these Qs!!?:
> 1. I think l2_multi in the beging builds its table(ip,mac,port,switch), then 
> check this table for any packet_in
> 2. and I think it builds its table based on LLDP messages and it doesn't wait 
> for new connection requests like l2_learning

l2_multi doesn't do anything with LLDP.  openflow.discovery does.  But this 
only maps the connections between switches.  Using this information, it's 
possible for l2_multi to find shortest paths between any two switches.  
l2_multi tracks which switches it thinks hosts (MACs) are attached via 
packet_ins.  If it knows the destination, it will install an end-to-end 
fine-grained shortest path.

> Does the l2_multi uses Flood ALL when a packet_in is not found in its table 

https://github.com/noxrepo/pox/blob/carp/pox/forwarding/l2_multi.py#L322

> Thank you
> Best regards,
> Eng Amer Alghadhban
> COE
> SANS-GCFW
> CEH, SCNP, CCNA
> 
>  
> Subject: Re: L2.multi and discovery
> From: [email protected]
> Date: Thu, 24 Oct 2013 14:32:05 -0700
> CC: [email protected]
> To: [email protected]
> 
> Can you post your logs from a run of l2_multi that doesn't work?
> 
> -- Murphy
> 
> On Oct 24, 2013, at 2:29 PM, Amer <[email protected]> wrote:
> 
> Hello,
> 
> Thank you
> 
> I apologize, h1 and h3 are residing in different switch not subnet. h1 
> 10.0.0.1
> h3 10.0.0.3.
> Also, I tried the following statement and it is work fine:
> Pox.py forwarding.l2_learning
> I am using tree topology with fan=2
> 
> Best regards,
> Amer
> 
> On ٢٤‏/١٠‏/٢٠١٣, at ٩:٣٠ م, Murphy McCauley <[email protected]> wrote:
> 
> Hmm... as far as I remember, l2_multi and l2_learning shouldn't behave 
> differently in terms of L3.  My memory is that with either of them, you're 
> likely to run into the same problem -- it's not with POX or OpenFlow or 
> anything -- it's with the hosts.  The hosts will generally expect that they 
> need a gateway to communicate with another subnet.  If you reconfigure their 
> routing tables so that they don't, things will work fine.  IIRC, l3_learning 
> gets around this by establishing "fake" gateways.
> 
> -- Murphy
> 
> On Oct 24, 2013, at 8:44 AM, Amer <[email protected]> wrote:
> 
> Hello,
> 
> I would like to thank you for your effort in responding to our questions
> 
> I used the following command but it does not work 
> Pox.py l2.multi openflow.discovery
> 
> I could not ping between 
> h1->h3 # reside in different subnets
> 
> I tried this one, it works fine:
> Pox.py l2.learning openflow.discovery
> 
> I can ping between 
> h1->h3 # reside in different subnets
> 
> Thank you again
> Best regards,
> Amer
> 
> 
> Sent from my iPhone

Reply via email to