ppp and routing table rules.

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 <[email protected]> Candela Technologies Inc  http://www.candelatech.com

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 <[email protected]> Candela Technologies Inc  http://www.candelatech.com

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

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

Thanks,
Ben

Ben Greear <[email protected]> Candela Technologies Inc  http://www.candelatech.com