From: Theo M (theorack@gmail.com)
Date: Thu Aug 02 2007 - 12:18:25 ART
Hi Ben,
I will assume you MUST use F.-R.
InverseARP is for L3->L2 resolution ( like ARP), not for L2->L3 ( like
ReverseARP), the name is misleading.
No DLCI means no communication possible, so:
-> for Back-to-Back, you will have to define one manually, with "fram
interf X", under the p-t-p subinterface.
-> for Hybrid, you will have to define it on the DCE side, so the DTE side
learns it and can use it
On the lab, I would explicitely ask the proctor: am I allowed to create a
DLCI for this task ?
Some common misconceptions, since we are on the F.-R. subject:
-> "no arp frame-relay" does... absolutely nothing !!! you can stop a
router from asking, but not from responding (InARP)
-> DCE/DTE at L1 do NOT have to be the same with the Frame-Relay DCE/DTE
at L2
HTH
--On 8/1/07, Ben <bmunyao@gmail.com> wrote: > > Hi Theo, > > Thank you for your comments. Sorry if my original post wasn't clear. The > topology is as follows: > > 10.1.12.0/24 > R1---------------------R2 (no FR switch between the routers) > > > The Question: The requirement is for automatic L3 to L2 mapping without > inverse ARP or PPPoFR. No DLCI given. > > From your comments, I gather the following: > 1. LMI is for PVC announcements and monitoring their status, between the > FR switch (DCE) and the local DTE. > 2. InverseARP is end to end between DTEs, for L2 to L3 resolution. > > Option 1 in original post qualifies as hybrid by your definitions, since > frame-relay switching is enabled on R2. > > You are right, enabling FR switching on R2 only introduces LMI, and has > nothing to do with InverseARP. Then it appears both solutions are valid, > with the only difference being that option 1 dynamically monitors PVC > status. Comments? > > Thanks > > Ben > > > > On 8/1/07, Theo M <theorack@gmail.com> wrote: > > > > Some points: > > > > F.-R. Back-to-Back: (no LMI) <-> (no LMI) > > F.-R. Hybrid: (no LMI) <-> (LMI) > > F.-R. Usual: (LMI)<->(FR_Switch)<->(LMI) > > > > You CAN do InverseARP without LMI, try it on a Back-to-Back F.-R. > > connection. > > > > LMI is about learning what PVCs are available on the FRswitch and their > > state. > > > > InverseARP is about dynamic L3->L2 resolution, over an already known > > PVC. > > > > Dynamic resolution and static resolution are forbidden, you are left w/ > > p-t-p subinterfaces: they don't need resolution, maybe this is your > > "automatic". > > > > Please re-state your full requirement and topology. > > > > -- > > > > > > On 7/31/07, Ben < bmunyao@gmail.com> wrote: > > > > > > Hi > > > > > > The requirement is for automatic L3 to L2 mapping without inverse ARP > > > or > > > PPPoFR. > > > > > > AFAIK there are two ways to implement this: > > > > > > Option 1 > > > ------------------------------- > > > R1 (dce cable side) > > > fram switching > > > int s0/0 > > > enca fram > > > clock rate 64000 > > > fram intf-type dce > > > int s0/0.1 po > > > ip add 10.1.12.1 255.255.255.0 > > > fram int 100 > > > > > > R2 (dte cable side) > > > int s0/0 > > > enca fram > > > int s0/0.1 po > > > ip add 10.1.12.2 255.255.255.0 > > > fram int 100 > > > > > > Option 2 > > > --------------------- > > > > > > R1 > > > int s0/0 > > > enca fram > > > no keepalive > > > clock rate 64000 > > > int s0/0.1 po > > > ip add 10.1.12.1 255.255.255.0 > > > fram int 100 > > > > > > R2 > > > int s0/0 > > > enca fram > > > no keepalive > > > int s0/0.1 po > > > ip add 10.1.12.2 255.255.255.0 > > > fram int 100 > > > > > > Do both of the above meet the requirement, or have I missed something? > > > > > > I wasn't sure about option 1 since we are enabling LMI. Any comments > > > are > > > welcome. > > > > > > TIA > > > Ben > > > > > > > > > _______________________________________________________________________ > > > Subscription information may be found at: > > > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Sep 01 2007 - 11:32:09 ART