Hi Tulio, sure you have right and i write it:
>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
The problem is if your try to print the packet_in, you have tons of packet_in
from switch. I dont understand the sense of this. I understand well how
openflow/SDN works and my question is not basic concepts, because i think this
quantity of packet_in is a problem if i read this in the code:
simple_switch_13
>
>
# install a flow to avoid packet_in next time <<<<<<<< i think here we
dont install well the flow
if out_port != ofproto.OFPP_FLOOD:
match = parser.OFPMatch(in_port=in_port, eth_dst=dst)
# verify if we have a valid buffer_id, if yes avoid to send both
# flow_mod & packet_out
if msg.buffer_id != ofproto.OFP_NO_BUFFER:
self.add_flow(datapath, 1, match, actions, msg.buffer_id)
return
else:
self.add_flow(datapath, 1, match, actions)
data = None
if msg.buffer_id == ofproto.OFP_NO_BUFFER:
data = msg.data
out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,
in_port=in_port, actions=actions, data=data)
datapath.send_msg(out)
this is my flow table with mininet and Open vswitch, i have 2 switch with 1
host everyone, after 20 seconds:
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=14.193s, table=0, n_packets=136, n_bytes=22625,
idle_age=3, priority=0 actions=CONTROLLER:65535
*** s1 ------------------------------------------------------------------------
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=14.151s, table=0, n_packets=135, n_bytes=22535,
idle_age=2, priority=0 actions=CONTROLLER:65535
we can see that there are only the basic table miss flow, and nothing more. If
i ping an host, it will add a new flow correctly, but the point is that the
switch make tons of packet_in because simple_switch13 doesnt add a flow for the
comunication between 2 switch, so everytime create a packet_in for ask at the
controller how the switch must foward the packet.
PS: i work with virtual box, i just check that i have abnormal numbers of
interfaces. I dont know why, but i think that all these interfaces are the
problem. Btw try to check the script with 2 switch topology and print all
packet_in.
Thank you so much for your time, Luca Spinazzè
________________________________
Da: Túlio Pascoal <[email protected]>
Inviato: mercoledì 30 novembre 2016 11.33.57
A: Spinazze' Luca
Cc: [email protected]
Oggetto: Re: [Ryu-devel] Some question about how manage packet_in
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://static.licdn.com/scds/common/u/img/webpromo/btn_profile_bluetxt_80x15.png]<https://br.linkedin.com/pub/t%C3%BAlio-pascoal/a0/2a9/b69>
[https://docs.google.com/uc?export=download&id=0B3_6bTMFX9QOc01SUkNaT2NyVEU&revid=0B3_6bTMFX9QOdXlWZGtORk1BbFJ0UVNkNnBTMUx2eHRQTUpVPQ]
<http://lattes.cnpq.br/3973060880564786>
On 30 November 2016 at 07:24, Spinazze' Luca
<[email protected]<mailto:[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]<mailto:[email protected]>>
Inviato: mercoledì 30 novembre 2016 01.12.08
A: Spinazze' Luca
Cc: [email protected]<mailto:[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<http://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<http://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<http://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<http://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<http://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<http://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<http://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]<mailto:[email protected]>>
> Inviato: lunedì 28 novembre 2016 00.47.27
> A: Spinazze' Luca
> Cc: [email protected]<mailto:[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]<mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Ryu-devel mailing list
>> [email protected]<mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
------------------------------------------------------------------------------
_______________________________________________
Ryu-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
------------------------------------------------------------------------------
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel
