Jesse, thanks so much. Things are routing, OSPF seems happy and I'm
pushing iperf tests now.
The MTU of 1396 yields a functional size of around 1496 with the odd
fragmented packet here and there. Anyone have thoughts to a more optimal
MTU size?
I had some issues getting the syntax for the options: statements correct
but all seems sorted now. Here's the current working configuration,
hopefully it helps someone else.
- - - -
Host: Tango (OVS)
IP external: 1.1.1.1 (ext0)
IP internal: 10.1.1.1 (int0)
LAN 10.1.1.0/24
TUN ID: 10.10.10.1/24
Host: Cash (iproute2)
IP external: 2.2.2.2 (eth0)
IP internal: 10.2.2.2 (eth1)
LAN 10.2.2.0/24
TUN ID: 10.10.10.2/24
Tango setup:
ovs-vsctl add-br ext0
ovs-vsctl add-br int0
ovs-vsctl add-port ext0 eth0
ovs-vsctl add-port int0 eth1
ovs-vsctl add-br gre_cash
ip link set gre_cash up multicast on mtu 1396
ip addr add 10.10.10.1 peer 10.10.10.2 dev gre_cash
ovs-vsctl add-port gre_cash gre0 -- set interface gre0 type=gre
options:remote_ip=2.2.2.2 options:local_ip=1.1.1.1
options:header_cache=false
Tango Ipsec (StrongSwan, PSK)
conn tango-cash
right=1.1.1.1
left=2.2.2.2
keyingtries=%forever
type=tunnel
auth=esp
authby=secret
auto=addJesse, thanks so much. Things are routing, OSPF seems
happy and I'm pushing iperf tests now.
The MTU of 1396 yields a functional size of around 1496 with the odd
fragmented packet here and there. Anyone have thoughts to a more optimal
MTU size?
I had some issues getting the syntax for the options: statements correct
but all seems sorted now. Here's the current working configuration,
hopefully it helps someone else.
- - - -
Host: Tango (OVS)
IP external: 1.1.1.1 (ext0)
IP internal: 10.1.1.1 (int0)
LAN 10.1.1.0/24
TUN ID: 10.10.10.1/24
Host: Cash (iproute2)
IP external: 2.2.2.2 (eth0)
IP internal: 10.2.2.2 (eth1)
LAN 10.2.2.0/24
TUN ID: 10.10.10.2/24
Tango setup:
ovs-vsctl add-br ext0
ovs-vsctl add-br int0
ovs-vsctl add-port ext0 eth0
ovs-vsctl add-port int0 eth1
ovs-vsctl add-br gre_cash
ip link set gre_cash up multicast on mtu 1396
ip addr add 10.10.10.1 peer 10.10.10.2 dev gre_cash
ovs-vsctl add-port gre_cash gre0 -- set interface gre0 type=gre
options:remote_ip=2.2.2.2 options:local_ip=1.1.1.1
options:header_cache=false
Tango Ipsec (StrongSwan, PSK)
conn tango-cash
right=1.1.1.1
left=2.2.2.2
keyingtries=%forever
type=tunnel
auth=esp
authby=secret
auto=add
Cash setup: *note gretap as type
ip link add gre_tango type gretap remote 1.1.1.1 local 2.2.2.2 ttl 255
ip link set gre_tango up multicast on mtu 1396
ip addr add 10.10.10.2 peer 10.10.10.1 dev gre_tango
Cash ipsec (StrongSwan, PSK)
conn itm-cc
right=2.2.2.2
left=1.1.1.1
keyingtries=%forever
type=tunnel
auth=esp
authby=secret
auto=add
Cash setup: *note gretap as type
ip link add gre_tango type gretap remote 1.1.1.1 local 2.2.2.2 ttl 255
ip link set gre_tango up multicast on mtu 1396
ip addr add 10.10.10.2 peer 10.10.10.1 dev gre_tango
Cash ipsec (StrongSwan, PSK)
conn itm-cc
right=2.2.2.2
left=1.1.1.1
keyingtries=%forever
type=tunnel
auth=esp
authby=secret
auto=add
On Tue, 8 Jan 2013 09:42:33 -0800, Jesse Gross <je...@nicira.com> wrote:
> On Tue, Jan 8, 2013 at 9:39 AM, m...@privateit.net <m...@privateit.net>
> wrote:
>> gretap fixed my GRE tunneling issue, thank you...
>>
>> However, ipsec between the two systems is now “broken”. If the ipsec
>> tunnel is shutdown and the GRE tunnels are up, we can route without
>> problem. If the ipsec tunnel is up, GRE packets from the iproute2 box
>> (cash) appear to be ipsec encapsulated, packets from Tango (OVS) seem
to
>> arrive without ipsec encapsulation.
>
> On the OVS tunnel configuration you need to set header_cache=false in
> order to traverse the IPsec stack.
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
