netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ppp and routing table rules.
@ 2007-03-02  4:46 Ben Greear
  2007-03-02  6:29 ` Ben Greear
  0 siblings, 1 reply; 4+ messages in thread
From: Ben Greear @ 2007-03-02  4:46 UTC (permalink / raw)
  To: NetDev

Hello!

I have a suspicion (but no proof at this time) that a rule like this:

20:     from all iif ppp400 lookup 10001

is not actually working for ppp interfaces.  Before I go adding printk 
statements, are there any
stats that would show if packets are hitting a particular rule or 
routing table?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ppp and routing table rules.
  2007-03-02  4:46 ppp and routing table rules Ben Greear
@ 2007-03-02  6:29 ` Ben Greear
  2007-03-03  5:54   ` Bill Fink
  0 siblings, 1 reply; 4+ messages in thread
From: Ben Greear @ 2007-03-02  6:29 UTC (permalink / raw)
  To: NetDev

Ben Greear wrote:
> Hello!
>
> I have a suspicion (but no proof at this time) that a rule like this:
>
> 20:     from all iif ppp400 lookup 10001
>
> is not actually working for ppp interfaces.  Before I go adding printk 
> statements, are there any
> stats that would show if packets are hitting a particular rule or 
> routing table?
Ok, the rule is working and the routing table is being used.  But, 
weirdness abounds.

Here is my setup:

I have ppp401 (11.1.1.3/32) connected to ppp400 (11.1.1.2/32), over a 
cross-over T1 NIC (ie, this is going to the same machine).
Anything coming in on ppp400, uses a particular routing table, whose 
routes look like this:

10.1.1.3 via 172.1.2.2 dev rddVR4
11.1.1.2 via 11.1.1.2 dev ppp400
172.1.2.0/24 via 172.1.2.1 dev rddVR4
172.1.1.0/24 via 172.1.2.2 dev rddVR4
10.0.0.0/8 via 172.1.2.2 dev rddVR4
11.0.0.0/8 via 11.1.1.2 dev ppp400
default via 11.1.1.2 dev ppp400

If all worked as planned, the packets would traverse several other 
routing tables, the final which
has another pair of ppp links in it (ppp200, 10.1.1.2/32  connected to 
ppp201, 10.1.1.3/23).

I am sending udp packets through ppp400, and I see them appear on ppp401 
as expected.

The thing that is bothering me is that all I see on rddVR4 (172.1.2.1) 
is arps for 172.1.2.2, but the 'tell' IP is that of the
originating ppp400 link, not the IP of rddVR4, as I expected:

21:47:16.119640 arp who-has 172.1.2.2 tell 11.1.1.3
21:47:17.119371 arp who-has 172.1.2.2 tell 11.1.1.3
21:47:18.119254 arp who-has 172.1.2.2 tell 11.1.1.3
21:47:19.273118 arp who-has 172.1.2.2 tell 11.1.1.3

Unless I'm missing something dumb, a similar setup with all ethernet-ish 
network devices
works fine.

I have also enabled arp filtering:
# Only answer ARPs if it is for the IP on our own interface.
echo 2 > /proc/sys/net/ipv4/conf/all/arp_ignore
and for every device used in these routing tables:
echo 1 > /proc/sys/net/ipv4/conf/[dev]/arp_filter

Any idea what I need to do in order to make  the source IP for the ARP 
packet correct?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ppp and routing table rules.
  2007-03-02  6:29 ` Ben Greear
@ 2007-03-03  5:54   ` Bill Fink
  2007-03-03  7:22     ` Ben Greear
  0 siblings, 1 reply; 4+ messages in thread
From: Bill Fink @ 2007-03-03  5:54 UTC (permalink / raw)
  To: Ben Greear; +Cc: NetDev

On Thu, 01 Mar 2007, Ben Greear wrote:

> Ben Greear wrote:
> 
> I am sending udp packets through ppp400, and I see them appear on ppp401 
> as expected.
> 
> The thing that is bothering me is that all I see on rddVR4 (172.1.2.1) 
> is arps for 172.1.2.2, but the 'tell' IP is that of the
> originating ppp400 link, not the IP of rddVR4, as I expected:
> 
> 21:47:16.119640 arp who-has 172.1.2.2 tell 11.1.1.3
> 21:47:17.119371 arp who-has 172.1.2.2 tell 11.1.1.3
> 21:47:18.119254 arp who-has 172.1.2.2 tell 11.1.1.3
> 21:47:19.273118 arp who-has 172.1.2.2 tell 11.1.1.3
> 
> Unless I'm missing something dumb, a similar setup with all ethernet-ish 
> network devices
> works fine.
> 
> I have also enabled arp filtering:
> # Only answer ARPs if it is for the IP on our own interface.
> echo 2 > /proc/sys/net/ipv4/conf/all/arp_ignore
> and for every device used in these routing tables:
> echo 1 > /proc/sys/net/ipv4/conf/[dev]/arp_filter
> 
> Any idea what I need to do in order to make  the source IP for the ARP 
> packet correct?

Wouldn't that be controlled by arp_announce?

arp_announce - INTEGER
        Define different restriction levels for announcing the local
        source IP address from IP packets in ARP requests sent on
        interface:
        0 - (default) Use any local address, configured on any interface
        1 - Try to avoid local addresses that are not in the target's
        subnet for this interface. This mode is useful when target
        hosts reachable via this interface require the source IP
        address in ARP requests to be part of their logical network
        configured on the receiving interface. When we generate the
        request we will check all our subnets that include the
        target IP and will preserve the source address if it is from
        such subnet. If there is no such subnet we select source
        address according to the rules for level 2.
        2 - Always use the best local address for this target.
        In this mode we ignore the source address in the IP packet
        and try to select local address that we prefer for talks with
        the target host. Such local address is selected by looking
        for primary IP addresses on all our subnets on the outgoing
        interface that include the target IP address. If no suitable
        local address is found we select the first local address
        we have on the outgoing interface or on all other interfaces,
        with the hope we will receive reply for our request and
        even sometimes no matter the source IP address we announce.

        The max value from conf/{all,interface}/arp_announce is used.

        Increasing the restriction level gives more chance for
        receiving answer from the resolved target while decreasing
        the level announces more valid sender's information.

						-Bill

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ppp and routing table rules.
  2007-03-03  5:54   ` Bill Fink
@ 2007-03-03  7:22     ` Ben Greear
  0 siblings, 0 replies; 4+ messages in thread
From: Ben Greear @ 2007-03-03  7:22 UTC (permalink / raw)
  To: Bill Fink; +Cc: NetDev

Bill Fink wrote:
> On Thu, 01 Mar 2007, Ben Greear wrote:
>
>   
>> Ben Greear wrote:
>>
>> I am sending udp packets through ppp400, and I see them appear on ppp401 
>> as expected.
>>
>> The thing that is bothering me is that all I see on rddVR4 (172.1.2.1) 
>> is arps for 172.1.2.2, but the 'tell' IP is that of the
>> originating ppp400 link, not the IP of rddVR4, as I expected:
>>
>> 21:47:16.119640 arp who-has 172.1.2.2 tell 11.1.1.3
>> 21:47:17.119371 arp who-has 172.1.2.2 tell 11.1.1.3
>> 21:47:18.119254 arp who-has 172.1.2.2 tell 11.1.1.3
>> 21:47:19.273118 arp who-has 172.1.2.2 tell 11.1.1.3
>>
>> Unless I'm missing something dumb, a similar setup with all ethernet-ish 
>> network devices
>> works fine.
>>
>> I have also enabled arp filtering:
>> # Only answer ARPs if it is for the IP on our own interface.
>> echo 2 > /proc/sys/net/ipv4/conf/all/arp_ignore
>> and for every device used in these routing tables:
>> echo 1 > /proc/sys/net/ipv4/conf/[dev]/arp_filter
>>
>> Any idea what I need to do in order to make  the source IP for the ARP 
>> packet correct?
>>     
>
> Wouldn't that be controlled by arp_announce?
>   

Yes, after trawling through the code I found that one, and setting it to '2'
seems to have fixed everything.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-03-03  7:20 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-02  4:46 ppp and routing table rules Ben Greear
2007-03-02  6:29 ` Ben Greear
2007-03-03  5:54   ` Bill Fink
2007-03-03  7:22     ` Ben Greear

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).