RE: frame relay encapsulation type

From: Victor Cappuccio (cvictor@protokolgroup.com)
Date: Tue Jul 18 2006 - 11:09:42 ART


Hi Scott
I do not see any problem; Do I'm missing something?

Rack1R3#show frame-relay map
Serial0/0 (up): ip 123.123.123.1 dlci 301(0x12D,0x48D0), dynamic,
              broadcast,
              IETF, status defined, active
Rack1R3#
BB1-TS#1
[Resuming connection 1 to R1 ... ]
                                                                      
Rack7R1#
Rack7R1#telnet 123.123.123.3
Trying 123.123.123.3 ... Open
                                                                      
                                                                      
Password required, but none set
                                                                      
[Connection to 123.123.123.3 closed by foreign host]
Rack7R1#

-----Mensaje original-----
De: Scott Morris [mailto:swm@emanon.com]
Enviado el: Martes, 18 de Julio de 2006 10:01 a.m.
Para: 'Victor Cappuccio'; 'Quetta Walla'; ccielab@groupstudy.com
Asunto: RE: frame relay encapsulation type

Now try doing a telnet and see what happens.

Scott

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Victor Cappuccio
Sent: Tuesday, July 18, 2006 9:49 AM
To: 'Quetta Walla'; ccielab@groupstudy.com
Subject: RE: frame relay encapsulation type

Hi, What I have heard so far is that Cisco Router support both encapsulation
type (yes even using the Cisco Default encapsulation at the other end)

So having this topology; R1 ==== FR ==== R3 and R3 is the HUB, using encap
frame-relay ietf, and in R1 we use encap frame ietf

As you can see Rack7R1#show int s0/0 | in DLCI
  LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE

DLCI 0 is used as the management DLCI on R1, and in R3 There is no DLCI
information Rack1R3#show run int s0/0 | in DLCI

LMI monitors and reports on the status of PVCs. Any changes to the status of
a PVC can be forwarded to other devices on the WAN. LMI multicast groups can
be specified to multicast PVC and DLCI status updates. LMI uses reserved
DLCI 1023 (cisco LMI) or DLCI 0 (ANSI and ITU).
 
So it seems that R1 has detected that the remote end is not a Cisco Device
and that the user had configured bad the router, and he says "the router"
well ok let it be "just my interpretation"

Rack1R3#show run int s0/0
Building configuration...
                                          
Current configuration : 132 bytes
!
interface Serial0/0
 ip address 123.123.123.3 255.255.255.0
 encapsulation frame-relay IETF
 clock rate 64000
 no fair-queue
end

Serial0/0(i): dlci 103(0x1871), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP),
Serial0/0: frame relay INARP received
FR: Sending INARP Reply on interface Serial0/0 dlci 103 for link 7(IP)
Rack7R1(config-if)#fraem-relay map ip 123.123.123.3 103 b
                      ^
% Invalid input detected at '^' marker.
                                                                            
Rack7R1(config-if)#do show frame-relay map
Serial0/0 (up): ip 123.123.123.3 dlci 103(0x67,0x1870), dynamic,
              broadcast,, status defined, active
Rack7R1(config-if)#do ping 123.123.123.3
                                                                            
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.123.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/59/60 ms
Rack7R1(config-if)#
Serial0/0(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104
Serial0/0(i): dlci 103(0x1871), NLPID 0x3CC(IP), datagramsize 104
Serial0/0(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104
Serial0/0(i): dlci 103(0x1871), NLPID 0x3CC(IP), datagramsize 104
Serial0/0(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104
Serial0/0(i): dlci 103(0x1871), NLPID 0x3CC(IP), datagramsize 104
Serial0/0(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104
Serial0/0(i): dlci 103(0x1871), NLPID 0x3CC(IP), datagramsize 104
Serial0/0(o): dlci 103(0x1871), pkt type 0x800(IP), datagramsize 104
Serial0/0(i): dlci 103(0x1871), NLPID 0x3CC(IP), datagramsize 104
Rack7R1(config-if)#do show run int s0/0
Building configuration...
                                                                            
Current configuration : 121 bytes
!
interface Serial0/0
 ip address 123.123.123.1 255.255.255.0
 encapsulation frame-relay
 frame-relay lmi-type ansi
end
                                                                            
Rack7R1(config-if)#

-----Mensaje original-----
De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] En nombre de Quetta
Walla Enviado el: Martes, 18 de Julio de 2006 04:47 a.m.
Para: ccielab@groupstudy.com
Asunto: frame relay encapsulation type

The Scenario here is that R1 is HUB and R2 & R3 are Spokes If we look at
configurations below, the encapsulation type on R2
(spoke) is Frame-relay IETF. The interface encapsulation on FR switch is set
to FR-IETF for interface connected to R2. So when we do our configuration on
R1 and R3. Should we use IETF on the static mapping towards R2 or should we
leave it like the way it is in the configuration. Can some one kindly help
me out through this.

I shall be grateful

R1 HUB

Interface s0/0
ip address 10.0.0.1 255.255.255.0
encapsulation frame-relay
no frame-relay inverse arp
frame-relay map ip 10.0.0.2 102 broadcast frame-relay map ip 10.0.0.3 103
broadcast

R2 Spoke

Interface s0/0
ip address 10.0.0.2 255.255.255.0
encapsulation frame-relay IETF
no frame-relay inverse arp
frame-relay map ip 10.0.0.1 201 broadcast frame-relay map ip 10.0.0.3 201

R3 Spoke

Interface s0/0
ip address 10.0.0.3 255.255.255.0
encapsulation frame-relay
no frame-relay inverse arp
frame-relay map ip 10.0.0.1 301 broadcast frame-relay map ip 10.0.0.2 301

--


This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:47 ART