Hi Luca, That is because as you have a flow rule installed (in the switch) already for that flow, the switch know already what to do (forward to the host), then no Packet-In (for rule´s instalation) is necessary.
These are SDN/OpenFlow basic concepts. Regards, -- Túlio Albuquerque Pascoal <https://br.linkedin.com/pub/t%C3%BAlio-pascoal/a0/2a9/b69> <http://lattes.cnpq.br/3973060880564786> On 30 November 2016 at 07:24, Spinazze' Luca <[email protected]> wrote: > Hi Iwase Yusuke, thank you for your reply at my question. > > I check your reply and its correct, but i don't understand one point: > > Why the packet_in genereted from switch never stop to coming? And i make a > ping, the controller install the flow (correctly) and in this method a new > ping between hosts dont create a new packet_in. Something dosent work or i > miss something? > > Thank you for your time > > Luca Spinazzè > ------------------------------ > *Da:* Iwase Yusuke <[email protected]> > *Inviato:* mercoledì 30 novembre 2016 01.12.08 > *A:* Spinazze' Luca > *Cc:* [email protected] > *Oggetto:* Re: [Ryu-devel] Some question about how manage packet_in > > Hi. > > Sorry for the delay. > > On 2016年11月28日 16:45, Spinazze' Luca wrote: > > Thank you for your answer! > > > > I see these pages, but when i print the ipv4_src (if the packet have it) > this is ip of switch and not of host. This is correct, because the packet > is encapsulated with eth(ipv4/6(tcp/udp( packet_in()))). I need to read the > ipv4 of host that generated the packet_in, not the switch that send it. Is > it possibile? > > Well, that sounds strange... > If you analyze the packet data of the Packet-In messages (e.g., > ev.msg.data), > the contained packets should be from hosts. > > As you say, the destination of the Packet-In message is the controller, > OTOH, the Packet-In messages should contain the packets from hosts. > > Here is a sample for parsing IPv4 packets extracted from the Packet-In > messages. > > $ git diff > diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py > index 3e7c598..322ed3a 100644 > --- a/ryu/app/simple_switch_13.py > +++ b/ryu/app/simple_switch_13.py > @@ -21,6 +21,7 @@ from ryu.ofproto import ofproto_v1_3 > from ryu.lib.packet import packet > from ryu.lib.packet import ethernet > from ryu.lib.packet import ether_types > +from ryu.lib.packet import ipv4 > > > class SimpleSwitch13(app_manager.RyuApp): > @@ -90,6 +91,11 @@ class SimpleSwitch13(app_manager.RyuApp): > > self.logger.info("packet in %s %s %s %s", dpid, src, dst, > in_port) > > + ipv4_pkt = pkt.get_protocol(ipv4.ipv4) > + if ipv4_pkt: > + self.logger.info("IPv4 packet: src=%s, dst=%s", > + ipv4_pkt.src, ipv4_pkt.dst) > + > # learn a mac address to avoid FLOOD next time. > self.mac_to_port[dpid][src] = in_port > > > $ sudo mn --controller remote > ... > mininet> h1 ping -c 1 h2 > PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. > 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=5.71 ms > > --- 10.0.0.2 ping statistics --- > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > rtt min/avg/max/mdev = 5.717/5.717/5.717/0.000 ms > mininet> > > > $ ryu-manager ryu/app/simple_switch_13.py > loading app ryu/app/simple_switch_13.py > loading app ryu.controller.ofp_handler > instantiating app ryu/app/simple_switch_13.py of SimpleSwitch13 > instantiating app ryu.controller.ofp_handler of OFPHandler > ... > IPv4 packet: src=10.0.0.1, dst=10.0.0.2 > > > The src and dst addresses are hosts' address. > > mininet> h1 ip addr > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group > default qlen 1 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: h1-eth0@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue > state UP group default qlen 1000 > link/ether 96:ca:df:96:02:5c brd ff:ff:ff:ff:ff:ff link-netnsid 0 > inet 10.0.0.1/8 brd 10.255.255.255 scope global h1-eth0 > valid_lft forever preferred_lft forever > inet6 fe80::94ca:dfff:fe96:25c/64 scope link > valid_lft forever preferred_lft forever > mininet> > mininet> h2 ip addr > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group > default qlen 1 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: h2-eth0@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue > state UP group default qlen 1000 > link/ether 92:77:ef:99:58:53 brd ff:ff:ff:ff:ff:ff link-netnsid 0 > inet 10.0.0.2/8 brd 10.255.255.255 scope global h2-eth0 > valid_lft forever preferred_lft forever > inet6 fe80::9077:efff:fe99:5853/64 scope link > valid_lft forever preferred_lft forever > mininet> > > > Thanks, > Iwase > > > > > > I read that i can ask at the switch what match field it must send at the > controller, with switch_features_handler but nothing happenz. > > > > I have write a code like this: > > > > mod = parser.OFPFlowMod(datapath=datapath, > > priority=0, > > #Requires eth_type: 0x0800 (IPv4) or > eth_type: 0x86dd (IPv6) in match conditions > > match=parser.OFPMatch(eth_ > type=0x0800),#ether_types.ETH_TYPE_IP), > > instructions=inst) > > datapath.send_msg(mod) > > > > (in switch_features_handler) > > > > > > Thank you for your time, Luca Spinazzè > > > > ________________________________ > > Da: Iwase Yusuke <[email protected]> > > Inviato: lunedì 28 novembre 2016 00.47.27 > > A: Spinazze' Luca > > Cc: [email protected] > > Oggetto: Re: [Ryu-devel] Some question about how manage packet_in > > > > Hi, > > > > You can use "Packet Library" to analyze packet data in Packet-In > messages. > > Please refer to Ryu-Book: > > http://osrg.github.io/ryu-book/en/html/packet_lib.html > > or API reference of Ryu-Documentation: > > http://ryu.readthedocs.io/en/latest/library_packet.html > > > > Thanks, > > Iwase > > > > > > On 2016年11月28日 02:34, Spinazze' Luca wrote: > >> Hello, i'm Luca Spinazzè an italian student from Udine. I study for my > thesis Openflow and SDN. > >> > >> I'm trying to use the controller ryu for manage the packet_in in this > method: > >> > >> if the controller have a packet_in i want see the ip source of the > packet_in (not about switch) that generated the "problem". > >> > >> My problem is set how switch give me the fields on packet_in, now when > i print the message i can see only port_in or mac_address. Can i set that i > want a packet_in with the fields like :eth.src, eth.dst, ipv4.src, ipv4.dst > ... ? > >> > >> I hope that my bad english explane enough my problem, thank you for a > answer! > >> > >> Luca Spinazzè > >> > >> > >> > >> ------------------------------------------------------------ > ------------------ > >> > >> > >> > >> _______________________________________________ > >> Ryu-devel mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/ryu-devel > >> > >> > >> > >> ------------------------------------------------------------ > ------------------ > >> > >> > >> _______________________________________________ > >> Ryu-devel mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/ryu-devel > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > Ryu-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ryu-devel > >
------------------------------------------------------------------------------
_______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
