On Tue, Nov 23, 2004 at 04:05:01PM -0300, Emilio Lucena wrote:
> 1. Is the next-hop really optional?
The next-hop is required when the destination IP address of the packet
being route-to'd is not on the local network segment connected to the
interface you specify.
For instance, if you have an interface xl0 with address 10.1.1.1 and
netmask 255.255.0.0, and the packet being route-to'd has destination
address 10.1.2.2, that destination address is within xl0's network and
therefore directly reachable. You shouldn't specify a next-hop address,
so the pf box will do an arp lookup for the local destination 10.1.2.2
and send the packet to the resulting MAC address. If you would specify a
next-hop address, pf would send the packet to that address' MAC, and the
packet would first go the the next-hop, and the get forwarded again. If
you can reach the destination directly, you probably want to send it
directly, not via another local hop.
On the other hand, if the destination IP address is not local, you need
to tell pf what gateway you want to send the packets to. Same example as
before, but the destination is 62.65.145.30. This is not within xl0's
network, so the pf box can't do an arp lookup for 62.65.145.30. Instead,
it must send the packet to a local box that acts as gateway. The
next-hop address in the route-to rule is the IP address of that gateway.
For instance, route-to (xl0 10.1.3.3) would make the pf box do an arp
lookup for 10.1.3.3, and send the packet (with destination 62.65.145.30)
to the resulting MAC address.
> 2. how to create a table for route-to?
The table in route-to can only hold next-hop addresses, like
pass in route-to (xl0 <nexthops>)
or even
pass in route-to { (xl0 <nexthops_xl0>), (xl1 <nexthops_xl1>) }
It can't hold a list of interfaces, for instance
pass in route-to { xl0, xl1, xl2 }
pass in route-to { (xl0 10.1.3.3), (xl1 10.2.3.3) }
can't be converted into tables.
Tables can only hold numerical IP addresses (and netmasks), they can't
hold interface names or pairs of interface name and addresses.
If you need either of the last two forms and want to use tables for the
purpose of removing/adding interfaces to the round-robin pool from the
command line, the following trick should work:
Use a rule specifying all possible interface with one table of next-hop
addresses for each one, like
pass in route-to { (xl0 <nexthops_xl0>), (xl1 <nexthops_xl1>), ... }
and put only a single next-hop address into each table (the IP address
of the gateway for the network on that interface).
When an uplink dies, remove the address from the interface's next-hop
table, so the table becomes empty. pf will then skip the interface when
selecting from the pool. When the uplink comes back, re-add the address
to the corresponding pool.
I haven't actually tried it, but I think that's how it's supposed to
work, YMMV ;)
Daniel
