forget my last sentence "Because there is no IP src in an ARP request"
c/p error 2013/3/4 Arnaud M <arnau...@gmail.com> > Thanks a lot Luca, it's crystal clear for me now that the controller HAS > TO be involved in this arp reply task even if it's very basic... > > > > Because there is no IP src in an ARP request > > > > > 2013/3/4 Luca Prete <luca.pr...@garr.it> > >> Hi! >> This could help: >> http://technet.microsoft.com/en-us/library/cc758357%28v=ws.10%29.aspx at >> paragraph "How ARP resolves media access controll addresses for remote >> traffic". The thing is that OpenFlow switches (based on rules, actions...) >> can't reply alone (without contacting the controller) to ARP request, >> because they don't have ARP tables, protocols, etc....inside. >> Thus, everytime they have to contact the controller sending back to the >> host who made the ARP request a specific ARP reply. >> >> In your case: let's say you want to ping from H3 another host under S2 >> (let's call it H2) with IP address 10.0.2.2. >> - the host check with IP in its routing table and sees that to reach >> 10.0.2.2 must goes through the gateway >> - the host check in its ARP table for a corrispondence for the gateway >> but it doesn't find anything >> - a broadcast arp request is generated and it arrives to s1 that >> intercept it for the first time asking what to do to the controller (with a >> packetin) >> - The controller, analyzing headers, sees an ARP request from host >> 10.0.1.2 >> - The controller build a unicast ARP reply directed to the host witch >> requested, generating a packetout to the ingress port (on the switch) of >> the requesting message. >> Every time this reply changes depending on witch host generated the >> request.....by the way, also if the address for any reason would remain the >> same, switches can't manage alone ARP relies because they don't have the >> ARP protocol (as normal routers have!). >> - The controller (simulating the behaviour of the router) adds an ARP >> entry (in a ad-hoc ARP table similar to MAC table of learning switch) a >> tuple with the association 10.0.1.2 - MAC address. >> >> Hope to be clear, let me know if you need more help! >> >> Cheers, >> >> Luca >> >> Il 04/03/2013 08:45, Arnaud M ha scritto: >> >> Hi, thanks for response >> >> Just to specify : I want my switch (which is a "router" in this case) >> responds to ARP request concerning only its ip Address (like it has to do) >> >> >> >> 2013/3/4 Luca Prete <luca.pr...@garr.it> >> >>> Hi! >>> >>> If you have a table con the controller with some records ip -- mac >>> addr you can intercept broadcast arp request with the packet in message and >>> answer with a unicast packet out to the machine witch generated the request >>> (arp reply) >>> >>> Of course you COULD install a flowmod on the switch but it would be >>> unusefull because arp request anyway would change every time, host by host. >>> >>> Anyway usually on the controller topology and device manager modules >>> should help you ;) >>> >>> Luca P. >>> >>> Il giorno 04/mar/2013, alle ore 07:46, Arnaud M <arnau...@gmail.com> ha >>> scritto: >>> >>> Hi everyone, >>> >>> I did the first part of this (great) tutorial and now i'm in the routing >>> part and i'm wondering few things : >>> >>> 1 - why do we need 2 switch for this topology ? one should be enough >>> right ? >>> 2 - In the switching part, one didn't care about ARP reply/request... >>> but here in routing mode we should, so here is my question : how do you >>> craft ARP reply ? In the controller after a packet In message by sending a >>> packet out message to the switch ? Or is there a way to push a flow that >>> would match the ARP request and with actions would send an ARP reply ? >>> 3 - What about ARP request ? When one need to replace ethernet >>> destination... the controller should do it by using a packet out ? >>> >>> Thanks for your help >>> >>> Arnaud M >>> >>> _______________________________________________ >>> openflow-discuss mailing list >>> openflow-discuss@lists.stanford.edu >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> >>> >> >> >
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
