Date: Thu, 1 Feb 2001 15:35:41 -0000 From: parminder.mudhar@bt.com To: nick@rapidnet.com Cc: freebsd-net@FreeBSD.org Subject: RE: Routes and tunnels Message-ID: <71DA16F18D32D2119A1D0000F8FE9A9409D21C69@mbtlipnt01.btlabs.bt.co.uk>
next in thread | raw e-mail | index | archive | help
Nick Thanks for taking the time to reply to query. Here is more information that may help you. Having created the tunnel, I create a route to a node that I know is on the other side of the tunnel. When I try to ping this site, or even the tunnel end, I get a 'sendto: Network is down' reply from ping. I then use tcpdump to monitor the packets that should appear on the ethernet, but I don't see any packets that have destination address of the tunnel end. It seems to me that what is happening is the following: I want to send a packet where the destination address is the tunnel end ip_output gets this packet and looks up a route for this destination this route contains the next hop gateway, and the interface to use (gif) ip_output places the packet in the output queue of the interface (gif) which then proceeds to append an outer header to the packet its been given. This outer header will have the source address set to the tunnel source address and the destination set to the address of the tunnel end. The packet gets given to ip_ouput to send it to the destination address, which is the address of the tunnel end, and the route contains a reference to the interface (gif), etc. In other words, since the route entries contain an entry to a destination address which is the address of the end point of the tunnel and the interface to use is the tunnel interface (gif), what you are doing is appending an outer IP packet to your packet all the time, and since the destination address of the outer header has a route that uses the tunnel interface (gif)then you end up in an infinite loop - the packet will never be placed in the queue for transmission. I could be wrong, but if you look at the route entries given below, and go through the motions of packet forwarding, then you may arrive at the above conclusion. the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 the_swamp# netstat -rnf inet Routing tables Internet: Destination Gateway Flags Netif Expire default 132.146.115.1 UGSc 1 0 fxp1 127.0.0.1 127.0.0.1 UH 0 4 lo0 132.145.113.1 132.146.115.164 UH 0 0 gif0 132.146.115/24 link#2 UC 0 0 fxp1 => 132.146.115.1 0:30:19:9a:e4:71 UHLW 2 0 fxp1 460 What you say about this being "correct behaviour" is interesting, but it may put a damper on me trying to use this pointopoint tunnels for this purpose. Again, thanks very much for replying to my request for help and I look forward to hearing from you soon. Parminder Mudhar __________________________ parminder.mudhar@bt.com -----Original Message----- From: Nick Rogness [mailto:nick@rapidnet.com] Sent: Thursday, February 01, 2001 2:12 PM To: parminder.mudhar@bt.com Cc: freebsd-net@FreeBSD.org Subject: RE: Routes and tunnels On Thu, 1 Feb 2001 parminder.mudhar@bt.com wrote: > Hi > > Thanks for the replies. > > Sorry, I forgot to say that I was using to the tunnel to connect to the > remote site with interface address of 132.146.113.1 and I am not using the > tunnels to send the packets to the local address, 132.146.115.164. I am > trying to use tunnels as point to point links for running routing over them. > > But the end result is that I do not see a packet destined for the end point > of the tunnel, 132.146.113.1 on the wire. WHat do you mean on the wire? THe other side? Is the other side setup to tunnel? How did you configure the outside IP'w with gifconfig ? Need a tad more details to help you out. the behavior you described below about the kernel adding routes is correct as a 'gif' tunnel is a directly connect interface. Most OS's do the same thing with directly connect interfaces. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve " > > -----Original Message----- > > From: Mudhar,PS,Parminder,CEG2 R > > Sent: Wednesday, January 31, 2001 5:02 PM > > To: 'freebsd-net@FreeBSD.org' > > Subject: Routes and tunnels > > > > Hi > > > > I don't know if this is intentional or a bug, but if ifconfig is used to > > configure a point to point device, such as 'tun' or the newer 'gif' > > devices, then the kernel insists on installing a route where the > > destination is the end point of the tunnel, the gateway is the source of > > the tunnel and the interface is the device itself. I have checked this in > > version 3.2+KAME, what I a using, and also on version 4.1. The effect of > > the above is that the packet that uses the tunnel will never appear on the > > wire. > > > > Here is an output > > > > the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 > > the_swamp# netstat -rnf inet > > Routing tables > > > > Internet: > > Destination Gateway Flags Netif Expire > > default 132.146.115.1 UGSc 1 0 fxp1 > > 127.0.0.1 127.0.0.1 UH 0 4 lo0 > > 132.145.113.1 132.146.115.164 UH 0 0 gif0 > > 132.146.115/24 link#2 UC 0 0 fxp1 => > > 132.146.115.1 0:30:19:9a:e4:71 UHLW 2 0 fxp1 > > 460 > > > > I am also interested in using gated with point to point tunnels, but gated > > also insists on doing the above for point to point links. > > > > I thank you in advance for any advice you may have. > > > > Parminder Mudhar > > __________________________ > > parminder.mudhar@bt.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?71DA16F18D32D2119A1D0000F8FE9A9409D21C69>