Possible bug - GRE tunnel routing

[Todor Genov]

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
(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.


>>
>>  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.

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


-- 
Regards,

Todor Genov
Systems Operations

Verizon Business South Africa (Pty) Ltd

todor.genov at za.verizonbusiness.com
Tel: +27 11 235 6500
Fax: 086 692 0543