From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Wed Aug 03 2005 - 09:47:18 GMT-3
Thanks for the response, Thomwin. I thought that you could not use the
frame-relay interface-dlci and the frame map commands on the same
interface. My understanding is that you have to use one or the other
(on your second config). I'll have to try that one out....but how does
it know to not do inverse arp, since there is no "no frame inv" command.
I am a bit confused on that part.
Dave Schulz,
Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com%20>
________________________________
From: Thomwin Chen [mailto:thomwin_chen@yahoo.com]
Sent: Wednesday, August 03, 2005 8:20 AM
To: Schulz, Dave; Brian Dennis; nobody@groupstudy.com; Desmond Ong; lab
Subject: RE: frame-relay inverse arp
Hi Dave,
usually, if using multipoint subinterface FR, one would assign all
related DLCIs to it by using frame-relay interface-dlci xxx.
example :
==========================
!
int s0/0.1 multipoint
ip add 192.168.1.1 255.255.255.0
frame-relay interface-dlci 102
frame-relay interface-dlci 103
!
this config, will send inverse-arp for IP on dlci 102 and 103, even
after you disable inverse-arp explicitly on main/physical interface.
==========================
and if the requirement to not use frame-relay inverse-arp, simply map it
statically, so it become like this:
int s0/0.1 multipoint
ip add 192.168.1.1 255.255.255.0
frame-relay interface-dlci 102
frame-relay interface-dlci 103
frame-relay map ip 192.168.1.2 102 broadcast
frame-relay map ip 192.168.1.3 103 broadcast
!
this config, will stop inverse-arp for IP on DLCI 102 and 103, no need
to put no frame-relay inverse-arp on your multipoint subinterface.
=========================
and if your main/physical/multipoint subinterface doesn't have any
addressing, that interface will never send inverse-arp on any DLCI no
matter how much DLCIs assigned to it.
so, no frame-relay inverse-arp command is not required in this case.
int s0/0.1 multipoint
no ip address
frame-relay interface-dlci 102
frame-relay interface-dlci 103
this config will never send inverse-arp on dlci 102 and 103.
(except if you configure IPX address hehehe)
I tested this at about one month ago.
(by using debug frame-relay packet and show frame map)
Please check it, as I might be wrong.
Rgds,
Thomwin
"Schulz, Dave" <DSchulz@dpsciences.com> wrote:
Brian -
It appears that the last examples have Inarp active, but I must
be missing something. There is not a "no frame inverse" command on
those two. Also, if you are using subinterfaces and the question wants
you to not learn any unused DLCIs, then is it enough to use the "no
frame inverse" on only the subinterfaces? Or, should you insure that
you have it on the main interface also?
Dave
-----Original Message-----
From: nobody@groupstudy.com
To: Thomwin Chen; Desmond Ong; lab
Sent: 8/3/2005 12:15 AM
Subject: RE: frame-relay inverse arp
Thomwin,
You do not need to disable inverse-ARP on the physical
interfaces if you are using only subinterfaces. This is because
the "no
frame-relay inverse-arp" command is not inherited by
subinterfaces.
Here are some examples of when inverse-ARP is enabled or
disable
based on the configuration itself or based on the use of the "no
frame-relay inverse-arp" command.
**********************************
*** InARP Enabled for DLCI 102 ***
**********************************
interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 multipoint
ip address 10.1.1.1 255.255.255.0
frame-relay interface-dlci 102
**********************************
*** InARP Enabled for DLCI 102 ***
**********************************
interface Serial0/0
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
!
interface Serial0/0.1 multipoint
ip address 10.1.1.1 255.255.255.0
frame-relay interface-dlci 102
***********************************
*** InARP Disabled for DLCI 102 ***
***********************************
interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 multipoint
ip address 10.1.1.1 255.255.255.0
frame-relay interface-dlci 102
no frame-relay inverse-arp
*****************************************
*** InARP Disabled for IP on DLCI 102 ***
*****************************************
interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 multipoint
ip address 10.1.1.1 255.255.255.0
frame-relay interface-dlci 102
no frame-relay inverse-arp IP 102
*****************************************
*** InARP Disabled for IP on DLCI 102 ***
*****************************************
interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 multipoint
ip address 10.1.1.1 255.255.255.0
frame-relay map ip 10.1.1.1 102 broadcast
***********************************
*** InARP Disabled for DLCI 102 ***
***********************************
interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
ip address 10.1.1.1 255.255.255.0
frame-relay interface-dlci 102
Also it's a myth (aka urban legend ;-) that the "no arp
frame-relay" command stops the replies to inverse-ARP. It
doesn't.
HTH,
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
<http://www.internetworkexpert.com/>
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf Of
Thomwin Chen
Sent: Tuesday, August 02, 2005 8:45 PM
To: Desmond Ong; 'lab'
Subject: Re: frame-relay inverse arp
Hi Desmond,
you can test it by using a simple command :
debug frame-relay packet and see why most workbooks suggest no
frame-relay inverse-arp configured on physical FR interface.
probably, you will also need this to know : no arp frame-relay
Rgds,
Thomwin
Desmond Ong <desmond.gk@netstarnetworks.com> wrote:
hi there,
anyone can enlighten me on the following?
when to use "no frame-relay inverse arp" and when to
specifically use
"no
frame-relay inverse arp ip " ???
Thanks!
Regards,
Des
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:18 GMT-3