Re: GIF tunnel doesnt like fragmented packets?
On Wed, Jul 11, 2012 at 4:27 AM, Chris Benesch wrote:
> So I'm trying to set up a tunnel with Hurricane Electric. Works great on
> OpenBSD BTW, took only a minute or two.
>
There is no support for fragmented ipv6 packets in pf(4) for FreeBSD.
> So heres rc.conf
>
> ipv6_gateway_enable="YES"
> gif_interfaces="gif0"
> gifconfig_gif0="198.168.0.2 64.62.134.130"
> ipv6_network_interfaces="rl0 em0 gif0 lo0"
> ifconfig_gif0_ipv6="inet6 2001:470:66:3a3::2 2001:470:66:3a3::1 prefixlen
> 128"
> ipv6_defaultrouter="2001:470:66:3a3::1"
>
> And I am running pf on the box.
>
> # macros
> ext_if="rl0"
> int_if="em0"
> if_6="gif0"
>
> tcp_services="{ 22,25,80 }"
> udp_services="{ 500 }"
> icmp_types="echoreq"
>
> workstation="192.168.231.15"
>
> # options
> set optimization normal
> set block-policy return
> set skip on { lo gif0 }
>
> # scrub
> scrub in no-df
>
> # nat/rdr
> nat on $ext_if inet from !($ext_if) -> ($ext_if:0)
>
>
> # filter rules
> block in log on rl0
> pass out quick flags S/SA keep state
> pass in quick on $int_if flags S/SA keep state allow-opts
> pass in quick from 192.168.231.1 to 192.168.231.1
> pass in log from 64.62.134.130 to any
>
> antispoof quick for { lo }
>
> pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services
> pass in on $if_6 inet6 proto tcp from any to ($if_6) port $tcp_services
> pass in on $ext_if inet proto udp from any to ($ext_if) port $udp_services
> pass in on $if_6 inet6 proto udp from any to ($if_6) port $udp_services
>
> pass in inet6 proto icmp6 from any to any
> pass in inet proto icmp from any to any
>
> Ok, so now thats out of the way.
>
> Basically I see packets going out, but none coming back, and they clearly
> are coming back on the internet facing interface. I've ran a dump on pflog
> and nothing its not dropping it.
>
> Here is a dump for a couple pings from the outside interface:
>
> 18:53:09.462410 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4
> (0x0800), length 90: (tos 0x0, ttl 30, id 35752, offset 0, flags [none],
> proto IPv6 (41), length 76)
> 192.168.0.2 > 64.62.134.130: (hlim 64, next-header ICMPv6 (58) payload
> length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6,
> echo request, length 16, seq 0
> 18:53:09.507572 00:24:7b:c8:f1:70 > 00:11:09:01:c8:26, ethertype IPv4
> (0x0800), length 90: (tos 0x0, ttl 248, id 0, offset 0, flags [DF], proto
> IPv6 (41), length 76)
> 64.62.134.130 > 192.168.0.2: (hlim 64, next-header ICMPv6 (58) payload
> length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6,
> echo reply, length 16, seq 0
> 18:53:09.507598 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4
> (0x0800), length 90: (tos 0x0, ttl 247, id 0, offset 0, flags [none], proto
> IPv6 (41), length 76)
> 192.168.0.2 > 198.168.0.2: (hlim 64, next-header ICMPv6 (58) payload
> length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6,
> echo reply, length 16, seq 0
> 18:53:10.462714 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4
> (0x0800), length 90: (tos 0x0, ttl 30, id 35756, offset 0, flags [none],
> proto IPv6 (41), length 76)
> 192.168.0.2 > 64.62.134.130: (hlim 64, next-header ICMPv6 (58) payload
> length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6,
> echo request, length 16, seq 1
> 18:53:10.509347 00:24:7b:c8:f1:70 > 00:11:09:01:c8:26, ethertype IPv4
> (0x0800), length 90: (tos 0x0, ttl 248, id 0, offset 0, flags [DF], proto
> IPv6 (41), length 76)
> 64.62.134.130 > 192.168.0.2: (hlim 64, next-header ICMPv6 (58) payload
> length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6,
> echo reply, length 16, seq 1
> 18:53:10.509366 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4
> (0x0800), length 90: (tos 0x0, ttl 247, id 0, offset 0, flags [none], proto
> IPv6 (41), length 76)
> 192.168.0.2 > 198.168.0.2: (hlim 64, next-header ICMPv6 (58) payload
> length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6,
> echo reply, length 16, seq 1
>
> You get the picture there is back and forth
>
> And here is gif0
>
> [root@maricopacomputer ~]# tcpdump -leni gif0
> tcpdump: WARNING: gif0: no IPv4 address assigned
> tcpdump: listening on gif0, link-type NULL (BSD loopback), capture size
> 65535 bytes
> 18:52:34.975121 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58)
> payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok]
> ICMP6, echo request, length 16, seq 0
> 18:52:35.975701 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58)
> payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok]
> ICMP6, echo request, length 16, seq 1
> 18:52:36.975684 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58)
> payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok]
> ICMP6, echo request, length 16, seq 2
> 18:52:37.975689 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58)
> payload length: 16) 2001:470:66:3a3:
Re: GIF tunnel doesnt like fragmented packets?
On 11. Jul 2012, at 07:14 , Ermal Luçi wrote: > On Wed, Jul 11, 2012 at 4:27 AM, Chris Benesch > wrote: >> So I'm trying to set up a tunnel with Hurricane Electric. Works great on >> OpenBSD BTW, took only a minute or two. >> > There is no support for fragmented ipv6 packets in pf(4) for FreeBSD. It's wrong to say it like that. There is no support for transparent reassembly and checking in FreeBSD but we can happily filter on IPv6 fragments and allow or block them. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: GIF tunnel doesnt like fragmented packets?
On Tue, Jul 10, 2012 at 07:27:04PM -0700, Chris Benesch wrote: > The only thing I notice is that the ones coming from HE have the DF flag > set? Am I on the wrong path? Have no idea how to get this to work. The problem isn't fragmentation (those DF packets are not large enough to require fragmentation), but the fact that you're not answering the neighbor solicitation queries from the peer. > ifconfig_gif0_ipv6="inet6 2001:470:66:3a3::2 2001:470:66:3a3::1 prefixlen 128" See http://www.tunnelbroker.net/forums/index.php?topic=1191.0 Daniel ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
VNET and IPv6 multicast routing
Is $subj supposed to work in -current? When I set MFC entries in a second jails the ones installed from the first jail get destroyed or mixed up. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: GIF tunnel doesnt like fragmented packets?
OMG I am so stupid gifconfig_gif0="192.168.0.2 64.62.134.130" << works gifconfig_gif0="198.168.0.2 64.62.134.130" << what it was before, doesnt work Sorry to waste everyones time ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance
I tried to configure lagg with the latest source from SVN head and it did not help. Regards Adarsh -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On Behalf Of Adarsh Joshi Sent: Tuesday, July 10, 2012 10:53 AM To: Andrew Boyer Cc: freebsd-net@freebsd.org Subject: RE: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance Andrew, Here are the logs with LACP_DEBUG defined in ieee802.3ad_lacp.c, after typing Ifconfig lagg0 create ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 netmask 255.255.255.0 I compiled it as a standalone driver by the way. System 1: # ifconfig -v lagg0 lagg0: flags=8843 metric 0 mtu 1500 options=13b ether 00:0e:1e:08:05:20 inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255 nd6 options=29 media: Ethernet autoselect status: active groups: lagg laggproto lacp lag id: [(8000,00-0E-1E-08-05-20,01D3,,), (8000,00-0E-1E-04-2C-F0,0213,,)] laggport: ql1 flags=18 state=7D [(8000,00-0E-1E-08-05-20,01D3,8000,000D), (,00-00-00-00-00-00,,,)] laggport: ql0 flags=1c state=3D [(8000,00-0E-1E-08-05-20,01D3,8000,000C), (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] System 2: # ifconfig -v lagg0 lagg0: flags=8843 metric 0 mtu 1500 options=13b ether 00:0e:1e:04:2c:f0 inet 192.168.100.2 netmask 0xff00 broadcast 192.168.100.255 nd6 options=29 media: Ethernet autoselect status: active groups: lagg laggproto lacp lag id: [(8000,00-0E-1E-04-2C-F0,0213,,), (,00-00-00-00-00-00,,,)] laggport: ql1 flags=1c state=7D [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), (,00-00-00-00-00-00,,,)] laggport: ql0 flags=18 state=3D [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), (8000,00-0E-1E-08-05-20,01D3,8000,000C)] System 1 logs : Jul 10 10:38:49 bsd-14 kernel: lacp_attach[738] : lacp attached Jul 10 10:38:49 bsd-14 kernel: lacp_attach[740] : lacp_defined Jul 10 10:38:49 bsd-14 kernel: lagg0: link state changed to UP Jul 10 10:38:49 bsd-14 kernel: ql0: media changed 0x0 -> 0x100033, ether = 1, fdx = 1, link = 1 Jul 10 10:38:49 bsd-14 kernel: ql0: -> UNSELECTED Jul 10 10:38:49 bsd-14 kernel: ql1: media changed 0x0 -> 0x100033, ether = 1, fdx = 1, link = 1 Jul 10 10:38:49 bsd-14 kernel: ql1: -> UNSELECTED Jul 10 10:38:49 bsd-14 kernel: lacp_select_tx_port: no active aggregator Jul 10 10:38:50 bsd-14 kernel: ql1: port lagid=[(8000,00-0E-1E-08-05-20,01D3,8000,000D),(,00-00-00-00-00-00,,,)] Jul 10 10:38:50 bsd-14 kernel: ql1: aggregator created Jul 10 10:38:50 bsd-14 kernel: ql1: aggregator lagid=[(8000,00-0E-1E-08-05-20,01D3,,),(,00-00-00-00-00-00,,,)] Jul 10 10:38:50 bsd-14 kernel: ql1: mux_state 0 -> 1 Jul 10 10:38:50 bsd-14 kernel: ql0: port lagid=[(8000,00-0E-1E-08-05-20,01D3,8000,000C),(,00-00-00-00-00-00,,,)] Jul 10 10:38:50 bsd-14 kernel: ql0: aggregator created Jul 10 10:38:50 bsd-14 kernel: ql0: aggregator lagid=[(8000,00-0E-1E-08-05-20,01D3,,),(,00-00-00-00-00-00,,,)] Jul 10 10:38:50 bsd-14 kernel: ql0: mux_state 0 -> 1 Jul 10 10:38:51 bsd-14 kernel: ql1: lacpdu transmit Jul 10 10:38:51 bsd-14 kernel: actor=(8000,00-0E-1E-08-05-20,01D3,8000,000D) Jul 10 10:38:51 bsd-14 kernel: actor.state=85 Jul 10 10:38:51 bsd-14 kernel: partner=(,00-00-00-00-00-00,,,) Jul 10 10:38:51 bsd-14 kernel: partner.state=2 Jul 10 10:38:51 bsd-14 kernel: maxdelay=0 Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu transmit Jul 10 10:38:51 bsd-14 kernel: actor=(8000,00-0E-1E-08-05-20,01D3,8000,000C) Jul 10 10:38:51 bsd-14 kernel: actor.state=85 Jul 10 10:38:51 bsd-14 kernel: partner=(,00-00-00-00-00-00,,,) Jul 10 10:38:51 bsd-14 kernel: partner.state=2 Jul 10 10:38:51 bsd-14 kernel: maxdelay=0 Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu receive Jul 10 10:38:51 bsd-14 kernel: actor=(8000,00-0E-1E-04-2C-F0,0213,8000,000E) Jul 10 10:38:51 bsd-14 kernel: actor.state=5 Jul 10 10:38:51 bsd-14 kernel: partner=(8000,00-0E-1E-08-05-20,01D3,8000,000C) Jul 10 10:38:51 bsd-14 kernel: partner.state=85 Jul 10 10:38:51 bsd-14 kernel: maxdelay=0 Jul 10 10:38:51 bsd-14 kernel: ql0: old pstate 2 Jul 10 10:38:51 bsd-14 kernel: ql0: new pstate 5 Jul 10 10:38:51 bsd-14 kernel: ql0: partner timeout changed Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu receive Jul 10 10:38:51 bsd-14 kernel: actor=(8000,00-0E-1E-04-2C-F0,0213,8000,000E) Jul 10 10:38:51 bsd-14 kernel: actor.state=5 Jul 10 10:38:51 bsd-14 kernel: partner=(8000,00-0E-1E-08-05-20,01D3,8000,000C) Jul 10 10:38:51 bsd-14 kernel: partner.state=85 Ju
Interface MTU question...
Howdy,
Does anyone know the reason for this particular check in
ip_output.c?
if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) {
/*
* This case can happen if the user changed the MTU
* of an interface after enabling IP on it. Because
* most netifs don't keep track of routes pointing to
* them, there is no way for one to update all its
* routes when the MTU is changed.
*/
if (rte->rt_rmx.rmx_mtu > ifp->if_mtu)
rte->rt_rmx.rmx_mtu = ifp->if_mtu;
mtu = rte->rt_rmx.rmx_mtu;
} else {
mtu = ifp->if_mtu;
}
To my mind the > ought to be != so that any change, up or down, of the
interface MTU is eventually reflected in the route. Also, this code
does not check if it is both a HOST route and UP, but only if it is
one other the other, so don't be fooled by that, this check happens
for any route we have if it's up.
My proposed change is this:
Index: ip_output.c
===
--- ip_output.c (revision 225561)
+++ ip_output.c (working copy)
@@ -320,7 +320,7 @@
* them, there is no way for one to update all its
* routes when the MTU is changed.
*/
- if (rte->rt_rmx.rmx_mtu > ifp->if_mtu)
+ if (rte->rt_rmx.rmx_mtu != ifp->if_mtu)
rte->rt_rmx.rmx_mtu = ifp->if_mtu;
mtu = rte->rt_rmx.rmx_mtu;
} else {
Please let me know what y'all think.
Best,
George
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Interface MTU question...
On 07/11/12 14:30, g...@freebsd.org wrote:
Howdy,
Does anyone know the reason for this particular check in
ip_output.c?
if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) {
/*
* This case can happen if the user changed the MTU
* of an interface after enabling IP on it. Because
* most netifs don't keep track of routes pointing to
* them, there is no way for one to update all its
* routes when the MTU is changed.
*/
if (rte->rt_rmx.rmx_mtu > ifp->if_mtu)
rte->rt_rmx.rmx_mtu = ifp->if_mtu;
mtu = rte->rt_rmx.rmx_mtu;
} else {
mtu = ifp->if_mtu;
}
To my mind the > ought to be != so that any change, up or down, of the
interface MTU is eventually reflected in the route. Also, this code
does not check if it is both a HOST route and UP, but only if it is
one other the other, so don't be fooled by that, this check happens
for any route we have if it's up.
I believe rmx_mtu could be low due to some intermediate node between
this host and the final destination. An increase in the MTU of the
local interface should not increase the path MTU if the limit was due to
someone else along the route.
Regards,
Navdeep
My proposed change is this:
Index: ip_output.c
===
--- ip_output.c (revision 225561)
+++ ip_output.c (working copy)
@@ -320,7 +320,7 @@
* them, there is no way for one to update all its
* routes when the MTU is changed.
*/
- if (rte->rt_rmx.rmx_mtu > ifp->if_mtu)
+ if (rte->rt_rmx.rmx_mtu != ifp->if_mtu)
rte->rt_rmx.rmx_mtu = ifp->if_mtu;
mtu = rte->rt_rmx.rmx_mtu;
} else {
Please let me know what y'all think.
Best,
George
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ating 100Gbit transfer rate
On Wed, Jul 11, 2012 at 1:31 PM, Sami Halabi wrote: > Hi, > > We have several boxes using 10G cards and using most of the bandwidth. > as a future vision i would like to ask if someone ever combined hardware > with freebsd/linux to saturate 100Gbit of traffic. > what hardware (server, NICs, platform) and software do you recommend that > would allow me to acheive my goal? > > Is it possible with servers ? or i need dedicated hardware > (cisco/juniper/other?) if dedicated hardware needed, i would be glad to > hear from your experience what do you recommend in terms of performance and > price. I don't know of any 100GE hardware for any PC, but I may be a bit behind on the times. The way we saturate a 100GE with a FreeBSD (or Linux) system is using a 10G transmission stream and loop the data stream over the net using MPLS. Works quite well, though no end system ever sees more than about 9.9G, the routers do. We are using Alcatel-Lucent routers at this time for our national test network. It is available for research by educational, commercial and research organizations for a little longer as a federally funded testbed for 100G research. When the funding for that project runs out, most of the hardware will be re-purposed and will no longer be available for research. gnn@ mentioned it about a year ago and suggested that some FreeBSD people might want to submit proposals, but I sw no responses. We have tested with Juniper and they will work, too. All 100G hardware is just a mite pricey, though it has dropped tremendously over the past year and a half and I expect it will continue to do so. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ating 100Gbit transfer rate
Hi, Thank your for your response. i have 2 questions: 1. can you explain the looping method that allowed you to reach 100GB ? 2. Alcatel-Lucent is routers are givven for research internationally ? or its locally? what routers we are talking about here and what link do they have? i appreciatre if you explain more how do these routers saturate 100GB. Thanks, Sami On Thu, Jul 12, 2012 at 6:43 AM, Kevin Oberman wrote: > On Wed, Jul 11, 2012 at 1:31 PM, Sami Halabi wrote: > > Hi, > > > > We have several boxes using 10G cards and using most of the bandwidth. > > as a future vision i would like to ask if someone ever combined hardware > > with freebsd/linux to saturate 100Gbit of traffic. > > what hardware (server, NICs, platform) and software do you recommend > that > > would allow me to acheive my goal? > > > > Is it possible with servers ? or i need dedicated hardware > > (cisco/juniper/other?) if dedicated hardware needed, i would be glad to > > hear from your experience what do you recommend in terms of performance > and > > price. > > I don't know of any 100GE hardware for any PC, but I may be a bit > behind on the times. > > The way we saturate a 100GE with a FreeBSD (or Linux) system is using > a 10G transmission stream and loop the data stream over the net using > MPLS. Works quite well, though no end system ever sees more than about > 9.9G, the routers do. > > We are using Alcatel-Lucent routers at this time for our national test > network. It is available for research by educational, commercial and > research organizations for a little longer as a federally funded > testbed for 100G research. When the funding for that project runs out, > most of the hardware will be re-purposed and will no longer be > available for research. gnn@ mentioned it about a year ago and > suggested that some FreeBSD people might want to submit proposals, but > I sw no responses. We have tested with Juniper and they will work, > too. All 100G hardware is just a mite pricey, though it has dropped > tremendously over the past year and a half and I expect it will > continue to do so. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6...@gmail.com > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
