Date: Mon, 20 Jul 2009 05:30:17 -0400 From: "Jacobs, Brian" <Brian.Jacobs@lodgenet.com> To: "Jacobs, Brian" <Brian.Jacobs@lodgenet.com>, "Julian Elischer" <julian@elischer.org>, <freebsd-net@freebsd.org> Subject: RE: GRE tunnel limitations Message-ID: <126E45722B459248997856ECB72DEB7701285DED@host.lodgenet.com> In-Reply-To: <126E45722B459248997856ECB72DEB7701285DC2@host.lodgenet.com> References: <126E45722B459248997856ECB72DEB7701285DC0@host.lodgenet.com><4A5F5927.3080904@elischer.org> <126E45722B459248997856ECB72DEB7701285DC2@host.lodgenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
For all interested, I've been doing some implementation work over the
weekend. Tonight I did a cutover of 766 GRE tunnels to a RELENG_7 box:
[root@yttrium /lso/dev/real]# uname -a
FreeBSD yttrium.colo.XXXXXXXXXX.net 7.1-RELEASE FreeBSD 7.1-RELEASE #1:
Mon Apr 13 11:37:56 EDT 2009 bjacobs@yttrium.colo.
XXXXXXXXXX.net:/usr/obj/usr/src/sys/YTTRIUM i386
[root@yttrium /lso/dev/real]# ifconfig |grep gre |wc -l
766
[root@yttrium /lso/dev/real]# netstat -nr |wc -l=20
1494
[root@yttrium /lso/dev/real]# uptime
5:32AM up 74 days, 11:01, 5 users, load averages: 0.00, 0.26, 0.59
Load average is nothing (hovers between 0 and .20), although there isn't
much traversing the tunnels (yet), nor have we implemented IPsec (yet --
next step, have crypto card if needed). Another project commencing
shortly will push/pull about 10mb/s aggregate (estimate) across the
collective tunnels.
Please advise if the group (or any individuals) want performance data
from real world usage.
/bmj
-----Original Message-----
From: owner-freebsd-net@freebsd.org
[mailto:owner-freebsd-net@freebsd.org] On Behalf Of Jacobs, Brian
Sent: Thursday, July 16, 2009 12:50 PM
To: Julian Elischer
Cc: freebsd-net@freebsd.org
Subject: RE: GRE tunnel limitations
IP unnumbered between the two boxen. I've built some scripts to
automatically generate config files, and then other scripts to
automagically create the GRE interfaces and inject appropriate routes.
GRE numbers are assigned sequentially based on config file lines (and
are of no consequence):
gre45: flags=3D9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu
1476
tunnel inet 10.3.100.39 --> 207.230.84.130
inet 10.3.100.39 --> 10.11.146.129 netmask 0xffffffff=20
gre46: flags=3D9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu
1476
tunnel inet 10.3.100.39 --> 12.35.57.131
inet 10.3.100.39 --> 10.10.201.1 netmask 0xffffffff
10.3.100.39 is the primary Ethernet interface address of the local box
(terminator). 10.10.201.1 is the inside Ethernet of the remote box.
Routing statement for 10.0.0.0/8 live on the remote box, and individual
routes live on the concentrator:
root@yttrium /root# netstat -nr | grep 10.10.201
10.10.201.0/26 10.10.201.1 UGS 0 2042 gre46
10.10.201.1 10.3.100.39 UH 1 49263 gre46
/bmj
-----Original Message-----
From: Julian Elischer [mailto:julian@elischer.org]=20
Sent: Thursday, July 16, 2009 12:45 PM
To: Jacobs, Brian
Cc: freebsd-net@freebsd.org
Subject: Re: GRE tunnel limitations
Jacobs, Brian wrote:
> Does anyone have some realistic data on the number of GRE/ipip tunnels
> FreeBSD 7.x can reasonably terminate? Assume no IPsec, just standard
> encapsulation. I have an ad-hoc need to terminate about 1,4000 static
> GRE tunnels (as Cisco 7206's are backordered until September). J
>=20
> =20
>=20
> Thanks in advance!
>=20
> =20
>=20
> /bmj
>=20
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
The limitation would be that there is an interface for reach one and=20
the interface 'interface' uses a linked list. it might work but there=20
would probably be scaling issues.
I've often thought that what we need is a way to do "bulk encapsulatin=20
interfaces" where there is not an "interface" assigned to each=20
destination. (at least not one that shows up in 'ifconfig').
How will you want to decide which gre interface to use for a given=20
packet? is it just a standard routing decision based on the remote=20
address?
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?126E45722B459248997856ECB72DEB7701285DED>