You need to tell ovs-vswitchd to listen for incoming OpenFlow connections. Try
"ovs-vsctl set-controller ptcp:" You should then be able to remotely
connect to that bridge with OpenFlow over TCP. Note that if you have multiple
bridges on the same host, you'll need to use different IP addresse
Hi Sheili,
I'm not sure off hand about doing it remotely. I've always just used
ovs-ofctl dump-flows locally . Hopefully someone else on the list
will respond with the solution.
Aaron
On Tue, Jan 10, 2012 at 11:46 PM, Sheili Mittal
wrote:
> Hi Aaron,
>
> ** **
>
> Yes this is not related
Hi Aaron,
Yes this is not related to this mail chain, I just thought if you have
worked with remote machine with ofctl then it would help me.
This query was for me .
Can you please tell how you connect switch with local machine by using
ofctl command socket connection like tcp::port
I am
I've never tried it remotely, though this has nothing to do with this email
thread.
Aaron
On Tue, Jan 10, 2012 at 10:46 PM, Sheili Mittal
wrote:
> Hi Aaron,
>
> ** **
>
> Are you using ovs-ofctl for the connection.
>
> When I am using ovs-ofctl show tcp::6633
>
> It shows “Conn
Hi Aaron,
Are you using ovs-ofctl for the connection.
When I am using ovs-ofctl show tcp::6633
It shows "Connecton refused"
Please suggest how to make remote connection with ofctl?
I tried with loopback address too but the same error coming.
ovs-ofctl show ptcp::6633
this gives er
Hey Ben,
Sorry for some reason this packet seem to be showing up now.. I'm not quite
sure what the deal was before :/
1f:29:32:92:4d (oui Unknown) > 00:1b:21:6a:85:88 (oui Unknown), ethertype
IPv4 (0x0800), length 74: 10.0.0.10.36985 > 10.0.0.13.5004: S
00:1f:29:32:92:4d (oui Unknown) > 00:1f:2
As an experiment, you could start to add "printk"s to the kernel
module. That's what I'd do next while debugging the problem.
On Tue, Jan 10, 2012 at 05:10:38PM -0500, Aaron Rosen wrote:
> I'm not sure if this helps eliminate anything but I just tried this in
> mininet and the same thing occurs
I'm not sure if this helps eliminate anything but I just tried this in
mininet and the same thing occurs there if dl_src/nw_src ==
dl_dst/nw_dst .
Thanks,
Aaron
#packet that goes in
14:02:47.309736 06:3b:31:b8:d5:a2 (oui Unknown) > ca:05:25:be:fd:70
(oui Unknown), ethertype IPv4 (0x0800), len
Here are lines (154-158) from here http://codepad.org/APdmOTGN (more debug)
Thanks,
Aaron
Jan 10 14:46:07 localhost ovs-vswitchd: 04385|dpif|DBG|system@dp0: miss
upcall:
Jan 10 14:46:07 localhost ovs-vswitchd:
in_port(0),eth(src=00:1f:29:32:92:4d,dst=00:1b:21:6a:85:88),eth_type(0x0800),ipv4(src=
I'd expect such packets to show up in tcpdump in any case.
On Tue, Jan 10, 2012 at 01:35:48PM -0500, Aaron Rosen wrote:
> I'd be curious what the expected behavior should be if linux sees a packet
> arriving on an interface matching it's dl_src/src_ip. (Since this should
> have probably gone throu
If you apply the following series:
http://openvswitch.org/pipermail/dev/2011-December/013943.html
http://openvswitch.org/pipermail/dev/2011-December/013944.html
http://openvswitch.org/pipermail/dev/2011-December/013945.html
and then turn up the log level for the "dpif" module, then we should
be abl
I'd be curious what the expected behavior should be if linux sees a packet
arriving on an interface matching it's dl_src/src_ip. (Since this should
have probably gone through lo ).
I also enabled log_martians and it's not saying anything about this.
Thanks,
Aaron
On Tue, Jan 10, 2012 at 1:32 PM
These packets are the normal SYN packets to initial a TCP connection.
The weird thing though is if I use this flow_mod it works fine: (using a
fake ip/mac as the response).
cookie=0x0, duration=6.622s, table=0, n_packets=93776, n_bytes=6191149,
idle_timeout=100,priority=65535,tcp,in_port=65534,
The datapath actions look like what I'd expect to see. I'd expect the
modified packets to show up in tcpdump. I see that there are only two
such packets over an 18-second period. Can you send them faster? It
looks like the second packet didn't get caught by the kernel flow
("used:never") so bot
pg46 openvswitch # ovs-ofctl dump-flows dp0
NXST_FLOW reply (xid=0x4):
# Removed other flows here for paste...
cookie=0x0, duration=18.467s, table=0, n_packets=2, n_bytes=148,
idle_timeout=100,priority=65535,tcp,in_port=65534,vlan_tci=0x,dl_src=00:1f:29:32:92:4d,dl_dst=00:1b:21:6a:85:88,nw_src
On Tue, Jan 10, 2012 at 10:47:23PM +0530, Amit Tewari wrote:
> I am currently into analyzing ovs code flow for rule matching in flow tables
> when a packet arrives.
> 1.when a packet arrives and no matching exact match flow is found in datapath
> then a facet is created in userspace. this facet h
On Tue, Jan 10, 2012 at 12:15:39PM -0500, Aaron Rosen wrote:
> Hello,
>
> I have a quick question about what could be happening to these packets.
>
> I start a tcp connection 10.0.0.10 > 10.0.0.13:
>
> 12:02:55.961344 00:1f:29:32:92:4d (oui Unknown) > 00:1b:21:6a:85:88
> (oui Unknown), ethertype
hi,
I am currently into analyzing ovs code flow for rule matching in flow tables
when a packet arrives.
1.when a packet arrives and no matching exact match flow is found in datapath
then a facet is created in userspace. this facet has follwing members
facet->rule and facet->flow.
facet->flow is
Hello,
I have a quick question about what could be happening to these packets.
I start a tcp connection 10.0.0.10 > 10.0.0.13:
12:02:55.961344 00:1f:29:32:92:4d (oui Unknown) > 00:1b:21:6a:85:88
(oui Unknown), ethertype IPv4 (0x0800), length 74: 10.0.0.10.50490 >
10.0.0.13.5004: S
Then the foll
19 matches
Mail list logo
