Hi,


I tried the ping action omitting the gateways; however I got a ‘Network
unreachable’. So I modified the code to manually populate the ip-mac-port
mapping (arp table in s2 and s3) for the end hosts in each of the switch so
that I could send ARP replies with destination MAC and it works now.



However, I don’t want to be statically populating the arpTable at switches
with information for each of the hosts in the network & would like to do it
programmatically. Does this mean that:

1.    1.  I can now configure the hosts with a default gateways

2.    2.  Have some way to identify that host is in a different subnet and
forward the ARP request to next hop and at destination subnet perform the
L2-Learning.

3.    3.  Repeat 2 for ARP response till it reaches the destn.


*- Rashmi*


On Mon, Jul 23, 2012 at 11:04 PM, Murphy McCauley <[email protected]
> wrote:

>  I did try to execute a ping on the same network topology H1
>> (10.0.1.2)---> H4(10.0.2.2) using the simple L3 switch in POX, however I
>> could only see ARP requests from H1 to S2. I don't see the reply being
>> sent. I am not sure where I am going wrong..
>>
>>
> You're seeing the ARPs for 10.0.1.1 -- but that's not really S2 in any
> real sense.  There's not really such a thing as 10.0.1.1.  The switch is
> not a router.
>
> And that's the problem you're seeing with POX's l3_learning -- the
> gateways.  10.0.1.1 and 10.0.2.1 don't exist.  If you just omitted the
> gateways (as if you were on a giant 0.0.0.0 "subnet"), it should work fine,
> because in this case, 10.0.1.2 would just ARP for 10.0.2.2, which should
> work.  Then 10.0.1.2 would get a MAC, which would be 10.0.2.2 itself, send
> there, and that would work.
>
> The version of l3_learning in my public POX fork on github (which will
> eventually be getting merged upstream) handles the case of gateways by
> setting up "fakeways" (e.g., it can be set to do fake ARP replies for
> arbitrary IP addresses), and by always rewriting destination MACs (to
> change them from the gateway MACs to the actual destination MACs).
>
> (There was recently some discussion about l3_learning on pox-dev that
> discusses this more.)
>
>
> If you want to keep debugging your NOX app, I'd suggest that you sniff the
> traffic between s3 and h4.  Verify that the echo request shows up there
> coming from the switch.  Then see what follows that coming from h4.
>
> -- Murphy
>
> On Jul 23, 2012, at 9:35 AM, Rashmi Pujar wrote:
>
> The network topology that i configured in Mininet is as below. Each host
> was configured with a default gateway.
>
> h1<-->s2<-->s3<-->h4
>
> h1 ifconfig h1-eth0 10.0.1.2/24
> h4 ifconfig h4-eth0 10.0.2.2/24
> h1 route add default gw 10.0.1.1
> h4 route add default gw 10.0.2.1
>
> and i tried to run: h1 ping -c1 h4
>
> *- Rashmi*
>
>
> On Sun, Jul 22, 2012 at 11:47 PM, Murphy McCauley <
> [email protected]> wrote:
>
>> (Copying pox-dev)
>>
>> You mention both 10.0.2.2 and 10.0.1.2.  Which is it?  Did you use the
>> right one when testing?
>>
>> Also, can you explain exactly how you configured and started up Mininet?
>>
>> -- Murphy
>>
>> On Jul 19, 2012, at 5:28 PM, Rashmi Pujar wrote:
>>
>> I am a newbie to Openflow and I have been using the Openflow tutorial and
>> the VM image that comes along to get myself started....and hence continued
>> to use NOX
>>
>> To monitor the OF traffic between the controller and switch I used
>> Wireshary and the last OF traffic i saw was a OFP+ICMP Packet-In for
>> H1--->H4 from Switch3 port to Controller Port..
>> For ARP requests sent from hosts to switches, I build an ARP reply to be
>> sent to the host. I can see OFP+ARP packet-in and out in Wireshark.
>>
>> I did try to execute a ping on the same network topology H1
>> (10.0.1.2)---> H4(10.0.2.2) using the simple L3 switch in POX, however I
>> could only see ARP requests from H1 to S2. I don't see the reply being
>> sent. I am not sure where I am going wrong..
>>
>> DEBUG:forwarding.l3_learning:2 1 flooding ARP request 10.0.1.2 => 10.0.1.1
>> DEBUG:forwarding.l3_learning:3 1 ARP request 10.0.1.2 => 10.0.1.1
>> DEBUG:forwarding.l3_learning:3 1 flooding ARP request 10.0.1.2 => 10.0.1.1
>> DEBUG:forwarding.l3_learning:2 1 ARP request 10.0.1.2 => 10.0.1.1
>> DEBUG:forwarding.l3_learning:2 1 flooding ARP request 10.0.1.2 => 10.0.1.1
>> DEBUG:forwarding.l3_learning:3 1 ARP request 10.0.1.2 => 10.0.1.1
>> DEBUG:forwarding.l3_learning:3 1 flooding ARP request 10.0.1.2 => 10.0.1.1
>> DEBUG:forwarding.l3_learning:2 1 ARP request 10.0.1.2 => 10.0.1.1
>> DEBUG:forwarding.l3_learning:2 1 flooding ARP request 10.0.1.2 => 10.0.1.1
>> DEBUG:forwarding.l3_learning:3 1 ARP request 10.0.1.2 => 10.0.1.1
>> DEBUG:forwarding.l3_learning:3 1 flooding ARP request 10.0.1.2 =>
>> 10.0.1.1
>>
>> *- Rashmi*
>>
>>
>> On Thu, Jul 19, 2012 at 4:55 PM, Murphy McCauley <
>> [email protected]> wrote:
>>
>>> Do you have a good reason for using NOX-Classic?  As we're no longer
>>> doing any development with it, you might think about using POX (which
>>> already contains a simple L3 switch).
>>>
>>> To more directly answer your question, you can use Wireshark to monitor
>>> the OpenFlow traffic between the controller and the switch.  The OpenFlow
>>> reference implementation contains the OpenFlow dissector, and there's also
>>> a github project for it.
>>>
>>> What are you doing about non-IP traffic? More to the point, what are you
>>> doing about ARP?
>>>
>>> -- Murphy
>>>
>>> On Jul 19, 2012, at 4:46 PM, Rashmi Pujar wrote:
>>>
>>> > Hi,
>>> > I am trying to implement a static L3 Switch using NOX in Python. I
>>> have hardcoded the IPs and hence I do not perform any 'IP learning' as such.
>>> > My network topology looks as below.
>>> >
>>> >       Switch2<---------->Switch3
>>> >       |                       |
>>> >       |                       |
>>> >       H1                      H4
>>> >
>>> > When Host1 tries to ping H4 i.e. an ICMP req to H4. The controller
>>> ensures the destination mac address in this request is that of H4's;
>>> installs a flow in Switch2 and forwards the packet to the next hop i.e.
>>> Switch3. At Switch3 the arriving ICMP req has no flow entry and hence is
>>> sent to controller. The controller again checks against its IP table and
>>> installs a flow in Switch3 to finally forward the packet to the host at H4.
>>> I can see in my logs that a flow entry is being made for action on an
>>> appropriate port connecting to H4. However, I am expecting an ICMP echo
>>> reply from H4 to complete the ping process and I do not see that
>>> happenening...Is there a way to debug this, to actually see if an OF packet
>>> has been sent to the host at H4? Am I expected to handle ICMP requests?
>>> >
>>> > It would be great if you could help.
>>> >
>>> > Thanks,
>>> > Rashmi
>>> >
>>>
>>>
>>
>>
>
>

Reply via email to