ARP, multiple interfaces, and ip route
John Sasso
broadcast medium with the "ip route" command, e.g.
ip route 10.1.1.1 255.255.255.255 FastEthernet0/0
won't work. I'm trying to get a handle on (technically) why this won't
work; I gather it has something to do with ARP, but correct be if I'm
wrong.
For example, suppose I have 2 routers (each with a PVC to an ISP)
interconnected peer-to-peer via a Cat5 x-over cable (via their
FastEthernet0/1 interfaces), as well as indirectly by a switch both are
connected to (via their FastEthernet0/0 interfaces). Both routers are
configured with a Loopback interface.
! Router A
interface FastEthernet0/0
ip address 172.20.1.1 255.255.255.0
interface FastEthernet0/1
ip address 10.10.10.1 255.255.255.252
interface Loopback0
ip address 172.17.2.1 255.255.255.255
!
ip route 172.17.2.2 255.255.255.255 FastEthernet0/1
ip route 172.17.2.2 255.255.255.255 FastEthernet0/0 5
! Router B
interface FastEthernet0/0
ip address 172.20.1.2 255.255.255.0
interface FastEthernet0/1
ip address 10.10.10.2 255.255.255.252
interface Loopback0
ip address 172.17.2.2 255.255.255.255
!
ip route 172.17.2.1 255.255.255.255 FastEthernet0/1
ip route 172.17.2.1 255.255.255.255 FastEthernet0/0 5
If router A has a packet to send to 172.17.2.2 on router B, then the
route lookup should indicate the packet should go out interface
FastEthernet0/1. Wouldn't this work by A just sending an ARP broacast
for 172.17.2.2 out its FastEthernet0/1 interface?
I've been pondering this for days now but I still cannot get a handle on
the technical details as to why this wouldn't work (not just that Cisco
says it cannot be done).
--john
John Agosta
the packet must be encapsulated in a layer 2 frame,
and then transported to the next hop associated with the address
in that layer 2 frame.
On an ethernet segment, the IP packet has to be encapsulated in an ARPA
frame destined to the MAC address that is bound to the layer 3 (IP) address.
So, yes, the problem does have to do with ARP. A MAC address associated with
172.17.2.2 has to be discovered before the frame can be directed to the
appropriate 'target' hardware address.
Remember, there may be many hosts connected to an ethernet.
So, on an ethernet, you need to specify the next-hop-ip-address.
This way, the next-hop-ip-address can be 'ARPed,' and the MAC can be
discovered. Once the MAC address is discovered, the IP packet can be
encapsulated in a frame and directed toward the specific hardware (MAC)
address that 'owns' the destination IP address.
Using proxy-arp is another work-around.
You may want to read up on how that works.
Sorry to leave ya hanging, but I hope some of this
helps to answer some of your questions....
-ja
Brett Frankenberger
John Sasso <jsas...@nycap.rr.com> wrote:
>
>! Router A
>interface FastEthernet0/0
> ip address 172.20.1.1 255.255.255.0
>interface FastEthernet0/1
> ip address 10.10.10.1 255.255.255.252
>interface Loopback0
> ip address 172.17.2.1 255.255.255.255
>!
>ip route 172.17.2.2 255.255.255.255 FastEthernet0/1
>ip route 172.17.2.2 255.255.255.255 FastEthernet0/0 5
>
>route lookup should indicate the packet should go out interface
>FastEthernet0/1. Wouldn't this work by A just sending an ARP broacast
>for 172.17.2.2 out its FastEthernet0/1 interface?
You don't ARP for addresses on remote subnets. Router A can't ARP from
172.17.2.2 out FA0/1, because FA0/1 is in the 172.20.1.X subnet, which
doesn't include 172.17.2.2. If Router B received such an ARP request,
it would ignore it because it's not for an IP address on the subnet
from which it was received. And if Router A sent such an ARP request,
it would be violating the protocol.
(As a practical matter, the restriction on answering ARPs for
non-local-subnet destinations is relaxed with Proxy ARP is enabled, but
that's a hack to support ancient devices that don't have a subnet mask
configurable; it's not intended for routers to use.)
-- Brett
Barry Margolin
Brett Frankenberger <r...@rbfnet.com> wrote:
>(As a practical matter, the restriction on answering ARPs for
>non-local-subnet destinations is relaxed with Proxy ARP is enabled, but
>that's a hack to support ancient devices that don't have a subnet mask
>configurable; it's not intended for routers to use.)
But the router *will* use it if you install a static route that points to a
LAN interface.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Brett Frankenberger
Barry Margolin <bar...@genuity.net> wrote:
>In article <ab8ml...@enews1.newsguy.com>,
>Brett Frankenberger <r...@rbfnet.com> wrote:
>>(As a practical matter, the restriction on answering ARPs for
>>non-local-subnet destinations is relaxed with Proxy ARP is enabled, but
>>that's a hack to support ancient devices that don't have a subnet mask
>>configurable; it's not intended for routers to use.)
>
>But the router *will* use it if you install a static route that points to a
>LAN interface.
Hmm ... then why is his test failing? His config doesn't have proxy
arp disabled in the second router. Does Cisco's proxy ARP
implementation only respond to destinations that are within the same
classful network as the interface?
-- Brett
Barry Margolin
Brett Frankenberger <r...@rbfnet.com> wrote:
>In article <VIRB8.5$pV6...@paloalto-snr2.gtei.net>,
>Barry Margolin <bar...@genuity.net> wrote:
>>In article <ab8ml...@enews1.newsguy.com>,
>>Brett Frankenberger <r...@rbfnet.com> wrote:
>>>(As a practical matter, the restriction on answering ARPs for
>>>non-local-subnet destinations is relaxed with Proxy ARP is enabled, but
>>>that's a hack to support ancient devices that don't have a subnet mask
>>>configurable; it's not intended for routers to use.)
>>
>>But the router *will* use it if you install a static route that points to a
>>LAN interface.
>
>Hmm ... then why is his test failing? His config doesn't have proxy
>arp disabled in the second router. Does Cisco's proxy ARP
>implementation only respond to destinations that are within the same
>classful network as the interface?
No. In my experience, if the router has a route to the destination via
interface X, and it hears an ARP query for that destination on interface Y
(Y != X), it will respond to the ARP query.
I don't know why it didn't work in the OP's configuration.
Hansang Bae
> Hmm ... then why is his test failing? His config doesn't have proxy
> arp disabled in the second router. Does Cisco's proxy ARP
> implementation only respond to destinations that are within the same
> classful network as the interface?
It will respond to any network that is in the routing table.
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
********************************************************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************