From: Victor Cappuccio (vcappuccio@desca.com)
Date: Fri Nov 10 2006 - 12:58:26 ART
I can not tell you that, because I do not know it, sorry
But if one spoke was preconfigured with IETF, then I would assume that
spoke is "NON-Cisco"
Maybe Asking the proctor, or another advice from other person, I would
map to IETF but I could be very wrong
Regards
Victor.-
________________________________
From: Ian Blaney [mailto:ian.blaney@gmail.com]
Sent: Viernes, 10 de Noviembre de 2006 11:48 a.m.
To: Victor Cappuccio
Cc: Angelo De Guzman; Adam Frederick; Cisco certification
Subject: Re: Re(2): Frame Relay IETF
Victor
Thanks for your link.This explains why it works even when they are using
different encapsulation types in an all cisco setup.
Maybe I am going too deep here but if in the lab scenario one of the
spokes is preconfigured with "encapsulation frame IETF" are they wanting
you to assume this is a non-cisco device? Technically it still works no
matter what you configure but if on the assumption the spoke is an
non-cisco device they are looking for you to configure frame map IETF on
the hub in a multipoint.
My original question was, assuming the spoke configured with
encapsulation IETF was a non-cisco device, is IETF required on the frame
map of the other spoke router? I understand it is required on the hub
but not sure about the other spoke. I don't think its required.
R1 Hub
interface Serial0
encapsulation frame-relay
ip address 10.10.10.1 255.255.255.0
frame-relay map ip 10.10.10.2 102 broadcast
frame-relay map ip 10.10.10.3 103 IETF broadcast
no frame-relay inverse-arp
R2 Spoke Non-Cisco
interface Serial0
encapsulation frame-relay IETF
ip address 10.10.10.2 255.255.255.0
frame-relay map ip 10.10.10.1 201 broadcast
frame-relay map ip 10.10.10.3 201
no frame-relay inverse-arp
R3 Spoke
interface Serial0
encapsulation frame-relay IETF
ip address 10.10.10.3 255.255.255.0
frame-relay map ip 10.10.10.1 301 broadcast
frame-relay map ip 10.10.10.2 301 ***IETF***?????
no frame-relay inverse-arp
Ian
On 11/10/06, Victor Cappuccio <vcappuccio@desca.com> wrote:
http://www.groupstudy.com/archives/ccielab/200603/msg00484.html
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Angelo De Guzman
Sent: Jueves, 09 de Noviembre de 2006 10:46 p.m.
To: Adam Frederick; Cisco certification; Ian Blaney
Subject: Re(2): Frame Relay IETF
Hi Ian,
AFAIK yes. You need to have the have the same encapsulation type for
the hub
and spoke to talk. Remember when you do an encapsulation FR this
defaults to
Cisco. In real life scenario if you use a different router to connect
via FR to
a Cisco router. If you use encapsulation FR only on the Cisco router.
This
set-up is never going to work.
My Two cents,
Angelo
Ian Blaney (11/10/06 7:21 AM):
>On Spoke 2 router what if I enter a frame map for the other spoke
>
>Would it be
>
>frame map ip 172.1.24.142 301 IETF
>or
>frame map ip 172.1.24.142 301
>
>This is basically my question
>
>
>On 11/9/06, Adam Frederick < AFrederick@homefederalbank.com
<mailto:AFrederick@homefederalbank.com> > wrote:
>>
>> It is necessary to keep IETF consistent on the PVC.
>>
>> Example;
>>
>> Hub Router
>> !
>> interface serial0/0
>> Encapsulaton frame-relay
>> No frame-relay inverse-arp
>> Bandwidth 1544
>> Ip address 172.16.24.141 255.255.255.0
>> Frame map ip 172.16.24.142 102 broad ietf
>> Frame map ip 172.16.24.143 103 broad
>> !
>> !
>> Spoke 1
>> !
>> Interface serial0/0/0.1 point-to-point
>> Encapsulation frame-relay ietf
>> Bandwidth 256
>> Ip address 172.16.24.142 255.255.255.0
>> Frame-relay interface-dlci 201
>> !
>> !
>> Spoke 2
>> !
>> Interface serial0/0
>> Encapsulation frame-relay
>> No frame-relay inverse-arp
>> Bandwidth 256
>> Ip address 172.16.24.143 255.255.255.0
>> Frame map ip 172.1.24.141 301 broad
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: nobody@groupstudy.com [mailto: nobody@groupstudy.com
<mailto:nobody@groupstudy.com> ] On Behalf
Of
>> Ian Blaney
>> Sent: Thursday, November 09, 2006 2:40 PM
>> To: ccielab@groupstudy.com
>> Subject: Frame Relay IETF
>>
>> I am sure this has been asked before but I cannot find the answer in
the
>> archives.
>>
>> In a frame relay hub and 2 spokes scenario with static mappings where
>> one
>> spoke is
>> configured with RFC190 "encapsulation frame IETF". Is it necessary to
>> configured
>> IETF on the frame map of the other spoke as well as the hub?
>>
>>
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:46 ART