From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Fri Aug 05 2005 - 07:47:30 GMT-3
I'll have to check that (could be a version number issue). I heard that from
someone. Now the question needs asked....when you are in the lab, and using
the frame map statements....is it more correct to not add the no frame map
statement (or, leave it off since it is disabled)?
Dave
-----Original Message-----
From: Thomwin Chen
To: Schulz, Dave; Brian Dennis; nobody@groupstudy.com; Desmond Ong; lab
Sent: 8/5/2005 6:21 AM
Subject: RE: frame-relay inverse arp
Hi Dave,
sorry for the late reply, because i have to confirm your test with a
real test.
are u sure ?
It didn't happen to me.
(this test use multipoint subinterface on R3 and point-to-point
subinterface at remote end)
R3#show run int s0/0.3
Building configuration...
Current configuration : 190 bytes
!
interface Serial0/0.3 multipoint
ip address 192.168.11.3 255.255.255.0
frame-relay map ip 192.168.11.2 102 broadcast
frame-relay interface-dlci 102
frame-relay interface-dlci 105
end
R3#show frame map
Serial0/0.3 (up): ip 192.168.11.1 dlci 105(0x69,0x1890), dynamic,
broadcast,, status defined, active
Serial0/0.3 (up): ip 192.168.11.2 dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status defined, active
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int s0/0.3
R3(config-subif)#frame-relay map ip 192.168.11.1 105 broadcast
R3(config-subif)#^Z
00:30:31: %SYS-5-CONFIG_I: Configured from console by console
R3#show frame map
Serial0/0.3 (up): ip 192.168.11.1 dlci 105(0x69,0x1890), static,
broadcast,
CISCO, status defined, active
Serial0/0.3 (up): ip 192.168.11.2 dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status defined, active
R3#debug frame packet
Frame Relay packet debugging is on
R3#clear frame inarp
00:30:56: Serial0/0(i): dlci 105(0x1891), pkt type 0x800, datagramsize
68
00:30:57: Serial0/0(i): dlci 102(0x1861), pkt type 0x800, datagramsize
68
R3#clear frame inarp
R3#
00:31:06: Serial0/0(i): dlci 105(0x1891), pkt type 0x800, datagramsize
68
00:31:07: Serial0/0(i): dlci 102(0x1861), pkt type 0x800, datagramsize
68
R3#
00:31:15: Serial0/0(i): dlci 105(0x1891), pkt type 0x2000, datagramsize
284
R3#
00:31:16: Serial0/0(i): dlci 105(0x1891), pkt type 0x800, datagramsize
68
00:31:17: Serial0/0(i): dlci 102(0x1861), pkt type 0x800, datagramsize
68
R3#
00:31:21: Serial0/0(i): dlci 102(0x1861), pkt type 0x2000, datagramsize
284
R3#
00:31:26: Serial0/0(i): dlci 105(0x1891), pkt type 0x800, datagramsize
68
00:31:27: Serial0/0(i): dlci 102(0x1861), pkt type 0x800, datagramsize
68
R3#
00:31:36: Serial0/0(i): dlci 105(0x1891), pkt type 0x800, datagramsize
68
00:31:37: Serial0/0(i): dlci 102(0x1861), pkt type 0x800, datagramsize
68
R3#
00:31:46: Serial0/0(i): dlci 105(0x1891), pkt type 0x800, datagramsize
68
00:31:47: Serial0/0(i): dlci 102(0x1861), pkt type 0x800, datagramsize
68
R3#
00:31:56: Serial0/0(i): dlci 105(0x1891), pkt type 0x800, datagramsize
68
00:31:57: Serial0/0(i): dlci 102(0x1861), pkt type 0x800, datagramsize
68
Rgds,
Thomwin
"Schulz, Dave" <DSchulz@dpsciences.com> wrote:
Thanks, Thomwin. This brings up another interesting point on the inarp.
I
agree that if you use the frame map statement, then inarp is disabled
for that
DLCI. However, if the remote end is configured as point-to-point (and
you
forget to turn off inarp) and starts sending inarp, then this end will
begin
the inarp, even with the frame map statement. Any thoughts on
this....maybe it
is better to always put in the no frame inverse command, regardless.
Thoughts?
Dave
-----Original Message-----
From: Thomwin Chen
To: Schulz, Dave; Brian Dennis; nobody@groupstudy.com; Desmond Ong; lab
Sent: 8/3/2005 11:13 PM
Subject: RE: frame-relay inverse arp
Hi Dave,
do you have Caslow's book ?
on p.118 there is a statement like this :
"Inverse ARP will not be performed for the protocol on the specific DLCI
referenced in the frame relay map statement".
so, if you have frame-relay map ipx a.abcd.abcd.abcd 102 broadcast
statement,
then Inverse ARP is disabled for IPX on DLCI 102.
regarding the second config, it's an optional to put frame-relay
interface-dlci 102 and 103.
but, it has an advantage :
it keeps the concept of assigning DLCI consistently (with the first
config)
it's just an opinion hehehe...
Rgds,
Thomwin
"Schulz, Dave" wrote:
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
________________________________
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" 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
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 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