GRE tunnel limitations

Jacobs, Brian Brian.Jacobs at lodgenet.com
Thu Jul 16 16:50:03 UTC 2009


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?





More information about the freebsd-net mailing list