GRE tunnel limitations

[Julian Elischer]

Jacobs, Brian wrote:
> 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:

good to know, though load with traffic is more important.

talk to Philip Paeps about crypto support.. some crypto offload
cards slow down the system.. you need to have a PCI-E one or PCI-X
at slowest for it to be worth while on a fast machine.

(CC'd)




> 
> [root at 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 at yttrium.colo.
> XXXXXXXXXX.net:/usr/obj/usr/src/sys/YTTRIUM  i386
> [root at yttrium /lso/dev/real]# ifconfig |grep gre |wc -l
>      766
> [root at yttrium /lso/dev/real]# netstat -nr |wc -l 
>     1494
> [root at 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 at freebsd.org
> [mailto:owner-freebsd-net at freebsd.org] On Behalf Of Jacobs, Brian
> Sent: Thursday, July 16, 2009 12:50 PM
> To: Julian Elischer
> Cc: freebsd-net at 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=9051<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 
> gre46: flags=9051<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 at 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 at elischer.org] 
> Sent: Thursday, July 16, 2009 12:45 PM
> To: Jacobs, Brian
> Cc: freebsd-net at 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
>>
>>  
>>
>> Thanks in advance!
>>
>>  
>>
>> /bmj
>>
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> 
> 
> 
> The limitation would be that there is an interface for reach one and 
> the interface 'interface' uses a linked list.  it might work but there 
> would probably be scaling issues.
> 
> I've often thought that what we need is a way to do "bulk encapsulatin 
> interfaces" where there is not an "interface" assigned to each 
> destination. (at least not one that shows up in 'ifconfig').
> 
> How will you want to decide which gre interface to use for a given 
> packet? is it just a standard routing decision based on the remote 
> address?
> 
> 
> 
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"