Date: Tue, 19 Aug 2008 14:07:58 -0700 From: Julian Elischer <julian@elischer.org> To: Todor Genov <todor.genov@za.verizonbusiness.com> Cc: freebsd-net@freebsd.org Subject: Re: Possible bug - GRE tunnel routing Message-ID: <48AB362E.2060409@elischer.org> In-Reply-To: <48AB3358.4040709@za.verizonbusiness.com> References: <48AA1A9D.2040607@za.verizonbusiness.com> <48AA26FD.20305@elischer.org> <48AA88B4.6040606@za.verizonbusiness.com> <48AB0C5C.8090404@elischer.org> <48AB3358.4040709@za.verizonbusiness.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Todor Genov wrote: > Julian Elischer wrote: >> Todor Genov wrote: >>> Hi Julian, >> let me rephrase that.. >> p2p links do not support netmasks. That's all p2p links.. ppp, slip, >> tun, ng, gre, etc. >> >> If you what a virtual ethernet interface you may try tap(4) but you will >> need to have an appropriatly capable piece of software on the >> other end of the link. >> >> >> A p2p link doesn't take any notice of what you have written as netmask >> and it doesn't matter what your ISP has given you, or if you >> type /24 or /22 or /32. >> >> The point to point interface only knows about the ONE SINGLE ADDRESS >> on the other end of the link. >> If there is a network there, which that address is a part of, then >> it is up to YOU to add the route that allows packets to get there. >> >> > > This is fully understood and taken into account. > > For all intended purposes I treat the tunnels as a /30 subnets there you go again... tunnels are NOT SUBNETS OF ANY TYPE the two ends can be in completely different address spaces.. one can be 10.2.2.2 and the other end can be 192.168.2.42 there is NO SUBNETTING on point to point interfaces.. > (despite what ifconfig says) and as per the routing table which I pasted > destinations which need to be reached over those tunnels have static > routes specified: > > default 41.142.82.1 UGS 1 1365 tun0 > 41.142.82.1 41.142.82.37 UGH 1 0 tun0 > 192.168.254.1 192.168.254.2 UH 0 3 gre0 > 194.31.137.64 194.31.137.70 UH 1 0 tun1 > 194.31.154.148 194.31.137.64 UGS 0 0 tun1 > ^^^ this is the other end of the GRE tunnel > > From this routing table alone there is no way that traffic destined to > 196.31.154.148 should exit via tun0, but GRE traffic to 194.31.154.148 does. ^^^^ 196? I've deleted you original mail.. sorry.. Resend me privately the output of ifconfig -a and the FULL netstat -r output.. > > >>> The routing table does include routes to the /26 on tun1 and the /24 on >>> gre0. I have left them out as they are not relevant to the problem. The >>> troublesome route is the one to 194.31.154.148/32 >>> >>> Just noticed that the PtP address for tun1 looks incorrect - with that >>> netmask into account .64 is the network address. I'll look into that as >>> a possible cause. >> the netmask should not be taken into account because it is ignored. > > I was referring to static routes, not interface addressing in the above. so why are you setting netmasks. actually I see a bug, which is that ifconfig -a shows a netmask no matter if it makes sense.. > > Those routes also exist in my routing table, even though I omitted them > in my original paste > > 192.168.254.0/24 192.168.254.1 UGS 0 0 gre0 > 196.31.137.64/26 196.30.157.65 UGS 0 0 tun1 > (which i omitted in my original paste). > > Both those routes are irrelevant as the GRE endpoint is not these > subnets - it's merely reachable via tun1 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48AB362E.2060409>