Date: Tue, 13 Feb 2007 17:56:50 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: "Kather Rafi -TLS,Chennai" <katherrafi@hcl.in> Cc: freebsd-net@freebsd.org Subject: Re: "route add" how it behaves Message-ID: <45D1FBE2.2050308@FreeBSD.org> In-Reply-To: <6B2C2CD6EB6A2743950CB51B60DEB946278EDA@CHN-HCLT-EVS01.HCLT.CORP.HCL.IN> References: <6B2C2CD6EB6A2743950CB51B60DEB946278EDA@CHN-HCLT-EVS01.HCLT.CORP.HCL.IN>
next in thread | previous in thread | raw e-mail | index | archive | help
Kather Rafi -TLS,Chennai wrote:
> Hi all,
>
> I am new to FreeBSD.
>
> I want to know how the "route add " is working for the network routes
> and host routes in the case of with out specifying the gateway.
>
> In linux we can add like "route add -host 10.0.12.24 eth0" but in
> FreeBSD it should be like "route add -host 10.0.12.24 -iface fxp0"
>
> I want to know
>
> 1. how the flag -iface provides gateway to the route inside
> the kernel.?
>
>
Watch the output of 'route -nv monitor' running in the background when
you do it.
> 2. If it does not provide the gateway address how it
> identifies the ifaddr inside the kernel (ie interface address for the
> particular interface)?
>
If you specify an interface as the next-hop, what you are doing is
asking the link layer to resolve the next-hop.
In the case of a PPP interface, it should just send the packet to the
next hop (example: someone running PPP over RFCOMM with Bluetooth with
Proxy-ARP to bridge the Bluetooth endpoint device onto a LAN).
In the case of Ethernet (a CSMA/CD broadcast LAN which uses BSD's
route-cloning facility), it should ARP for the address.
The 'route' command actually manages the Forwarding Information Base
(FIB) or 'forwarding table'. We just call it the 'routing table' though
that is a misnomer. The Layer 2 entries ('ARP table') are also contained
within the FreeBSD FIB.
FreeBSD usually relies on an interface having an IPv4 number.The results
for an unnumbered PPP interface, which is not bridging in the example
above, may be undefined.
In the case of Ethernet, it's quite possible that an entity on the
directly attached LAN knows how to resolve the next-hop by doing Proxy
ARP on its behalf.
Hope this clarifies matters.
Regards,
BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45D1FBE2.2050308>