I just mean that there is no OpenFlow "NAT" action in the same way as there is an output action, for example. NAT is a higher-level idea which is only ever fully expressed at the controller, which results in lower-level things (e.g., IP rewriting) happening at the switch.
As for another way of doing NAT, POX comes with a NAT component. It may well work in the same basic way but differ on the details. -- Murphy On Aug 30, 2013, at 7:56 PM, AMER AL-GHADHBAN <[email protected]> wrote: > > Hello, > > Thank you for your comments > > But i did not understand how NAT is not an action > Is there a way of doing NATing other than what i post in my email; if there > is may you help me in how to do it. > > Best regards, > Amer > > في ٣١/٠٨/٢٠١٣، الساعة ١١:٣٧ م، كتب "Murphy McCauley" > <[email protected]>: > >> On Aug 31, 2013, at 4:12 AM, AMER AL-GHADHBAN <[email protected]> wrote: >> >>> I am using pox with mininet v2.0 >>> the main code in my controller is ideal-pairwise-switch >> >> Is this something you wrote, or something you found? It's not one of POX's >> packaged components. >> >>> My topology is 2 connected switches and 3 hosts in each >>> i am trying to do NAT between the switches# i do not know should I exclude >>> ARP pkts from NATing # >>> >>> I have added the following matching in _handel_PacketIn >>> >>> msg = of.ofp_flow_mod() >>> msg.idle_timeout = 10 >>> msg.hard_timeout = 30 >>> msg.match.dl_dst = packet.src >>> msg.match.dl_src = packet.dst >>> msg.actions.append(of.ofp_action_output(port = event.port)) >>> event.connection.send(msg) >>> msg = of.ofp_flow_mod() >>> msg.idle_timeout = 10 >>> msg.hard_timeout = 30 >>> msg.match.dl_type = packet.IP_TYPE >>> msg.match.dl_dst = packet.src >>> msg.match.nw_dst = packet.next.protodst >>> msg.match.nw_src = packet.next.protosrc >> >> You didn't post the traceback, but I am guessing the above lines are where >> the error came from. If the packet happens to be an ARP packet, this should >> work fine. packet is ethernet, packet.next is ARP, and ARP packets have >> protodst/protosrc attributes (these are the ARP TPA/SPA fields). But if the >> packet is an IP packet, you'll run into problems, because IP packets don't >> have such attributes. The source and destination IPs are in srcip and dstip >> attributes. >> >> The point is that you need to be aware what type of packet you're handling >> here, and I'm guessing you're not. >> >>> msg.match.dl_src = packet.dst >>> msg.actions.append(of.ofp_action_output(port = event.port)) >>> event.connection.send(msg) >>> # I want to get the IP of the packetin to be used in another function >>> # i do not know if there is a better way >>> >>> this is the NATing >>> msg = of.ofp_flow_mod() >>> msg.idle_timeout = 100 >>> msg.hard_timeout = 130 >>> msg.match.dl_type = pkt.ethernet.IP_TYPE >>> msg.match.nw_dst = IPAddr("10.0.1.1") >>> msg.actions.append(of.ofp_action_output(port = dst_port)) >>> msg.actions.append(of.ofp_action_nw_addr.set_dst(dst)) >>> core.openflow.sendToDPID(2, msg) >>> >>> I have the following questions: >>> 1. what is the causes of Attribute error as mentioned in previous email >> >> Answered above, but the short of it is that your code is in error. You're >> attempting to access ARP-packet-specific attributes on IP packets. >> >>> 2. Is there a way to do an action like go to next match or continue your >>> matching to subsequent flow table rules # I want the switch to execute the >>> NATing action and continue to execute the learning_switch action# >> >> Not with straight OpenFlow 1.0, but possibly with Open vSwitch or later >> OpenFlow versions. But I'm not sure you're thinking of this quite right... >> NATing and learning_switch aren't "actions" in the OpenFlow sense. >> Moreover, doing NAT with OpenFlow 1.0 requires that at least one packet from >> the flow comes to the switch, which is the same requirement as doing >> controller-based learning, so combining both should be possible... >> >>> I appreciate your time and efforts >>> Thank you >>> >>> >>> Eng Amer Alghadhban >>> COE >>> SANS-GCFW >>> CEH, SCNP, CCNA >>> >>> >>> Subject: Re: Attribute error with ping >>> From: [email protected] >>> Date: Fri, 30 Aug 2013 14:37:00 -0700 >>> CC: [email protected] >>> To: [email protected] >>> >>> Please see the final entry of the POX FAQ: >>> https://openflow.stanford.edu/display/ONL/POX+Wiki >>> >>> -- Murphy >>> >>> On Aug 30, 2013, at 2:19 PM, AMER AL-GHADHBAN <[email protected]> wrote: >>> >>> Hello, >>> >>> Hope you the best of wealth :) >>> >>> Some times I am facing this error: >>> AttributeError: 'ipv4' object has no attribute 'protodst' >>> if i do: >>> h2 ping -c3 h1 # i received no echo messages at all >>> >>> and after some seconds when i try it again it is pinging without any errors >>> >>> best wishes >>> >>> Eng Amer Alghadhban >>> COE >>> SANS-GCFW >>> CEH, SCNP, CCNA >>
