Skip navigation
Cisco Learning Home > CCNP R&S Study Group > Discussions
This Question is Answered 1 Helpful Answer available (2 pts)
18021 Views 16 Replies Latest reply: Mar 11, 2012 1:36 PM by Doug Koobs RSS 1 2 Previous Next

Currently Being Moderated

Frame Relay encapsulation Cisco vs. IETF

Dec 14, 2011 4:17 PM

Martin 13,077 posts since
Jan 16, 2009

I have 2 routers using frame relay.  One is configured with encapsulation frame-relay ietf, the other one with encapsulation frame-relay

 

Everything else (DLCIs, mapping, LMI) is configured correctly.  Will those two routers have problem communicate or not and why?

  • Warren Sullivan - CCNP 934 posts since
    Jun 4, 2010
    Currently Being Moderated
    1. Dec 14, 2011 4:35 PM (in response to Martin)
    Re: Frame Relay encapsulation Cisco vs. IETF

    From what you did to my lab the other day...... Yes they do, communication is fine, no idea why at this stage, it was on my "to explore" list

  • Warren Sullivan - CCNP 934 posts since
    Jun 4, 2010

    Come to think of it, isn't ietf default? It might not react as per normal cisco behavior, where defaults are omitted from running configs.....

  • Warren Sullivan - CCNP 934 posts since
    Jun 4, 2010
    Currently Being Moderated
    4. Dec 14, 2011 4:49 PM (in response to Martin)
    Re: Frame Relay encapsulation Cisco vs. IETF

    If coarse, your right..... The other day you put frame relay encap ietf on R4 s0/0.34 interface and the other end was cisco, it worked fine, have you labbed anything up? Wire shark? Debugs? Keen to help you look into it but I've got to go and buy camping gear:-)

  • durga 181 posts since
    Nov 20, 2009
    Currently Being Moderated
    6. Dec 14, 2011 9:54 PM (in response to Martin)
    Re: Frame Relay encapsulation Cisco vs. IETF

    Since encapsulation is DTE to DTE, I was under an impression that the ping might fail, I tried to lab it up in PT and verify .I found pings to be working just fine. I am not sure how,

  • abdel_n 110 posts since
    Jul 10, 2008
    Currently Being Moderated
    7. Dec 15, 2011 8:09 AM (in response to Martin)
    Re: Frame Relay encapsulation Cisco vs. IETF

    Hi Martin,

     

    - Frame Relay encapsulation works between DTE devices (client FR routers) and IETF encapsulation is for interoperability between Cisco and non-Cisco, so IETF on one side (Cisco device) and any other device with IETF encapsulation (Cisco devices included) should work.

     

    - Frame Relay LMI needs to be matched between each couple of DTE-DCE devices (client FR routers and FR Provider switch). The FR Switch device is responsible for managing and maintaining status between the devices so need to understand the format the client DTE is using.

    ==>   Consequently DTE router and DCE router with different LMI type will not be able to  communicate.

     

    top.png

     

    In the following example R3 (DTE) has Cisco the default encapsulation and R2 (DTE) has IETF encapsulation

     

    R3 (DTE) :

    R3:

    R3#sh int s0/3

    Serial0/3 is up, line protocol is up

      Hardware is M4T

      Internet address is 192.168.23.3/24

      MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

         reliability 255/255, txload 1/255, rxload 1/255

      Encapsulation FRAME-RELAY, crc 16, loopback not set

      Keepalive set (10 sec)

      Restart-Delay is 0 secs

      LMI enq sent  19, LMI stat recvd 19, LMI upd recvd 0, DTE LMI up

      LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0

      LMI DLCI 1023  LMI type is CISCO  frame relay DTE

      FR SVC disabled, LAPF state down

    <output omitted>

    R3#

    R2 (FR Switch) :

    R2(config-if)#do sh int s0/0

    Serial0/0 is up, line protocol is up

      Hardware is M4T

      Internet address is 192.168.23.2/24

      MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

         reliability 255/255, txload 1/255, rxload 1/255

      Encapsulation FRAME-RELAY IETF, crc 16, loopback not set

      Keepalive set (10 sec)

      Restart-Delay is 0 secs

      LMI enq sent  35, LMI stat recvd 35, LMI upd recvd 0, DTE LMI up

      LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0

      LMI DLCI 1023  LMI type is CISCO  frame relay DTE

      FR SVC disabled, LAPF state down

    ping from R3(DTE) to R2(DTE) :

    R3#ping 192.168.23.2 repeat 1

     

    Type escape sequence to abort.

    Sending 5, 100-byte ICMP Echos to 192.168.23.2, timeout is 2 seconds:

    !

    Success rate is 100 percent (5/5), round-trip min/avg/max = 32/52/84 ms

    R3#

    *Mar  1 00:07:22.147: Serial0/3(o): dlci 302(0x48E1), pkt type 0x800(IP), datagramsize 104

    *Mar  1 00:07:22.231: Serial0/3(i): dlci 302(0x48E1), NLPID 0x3CC(IP), datagramsize 104

     

    debug on R2 (DTE):

    R2#

    *Mar  1 00:07:22.427: Serial0/0(i): dlci 203(0x30B1), pkt type 0x800, datagramsize 104

    *Mar  1 00:07:22.431: Serial0/0(o): dlci 203(0x30B1), NLPID 0x3CC(IP), datagramsize 104

    R2#

     

    -------------- FRS Configuration

    R1#sh frame route

    Input Intf      Input Dlci      Output Intf     Output Dlci     Status

    Serial0/2       203             Serial0/3       302             active

    Serial0/3       302             Serial0/2       203             active

    R1#

    R1#sh run int s0/2

    Building configuration...

     

    Current configuration : 214 bytes

    !

    interface Serial0/2

    no ip address

    encapsulation frame-relay

    serial restart-delay 0

    clockrate 2016000

    frame-relay lmi-type cisco

    frame-relay intf-type dce

    frame-relay route 203 interface Serial0/3 302

    end

     

    R1#sh run int s0/3

    Building configuration...

     

    Current configuration : 214 bytes

    !

    interface Serial0/3

    no ip address

    encapsulation frame-relay

    serial restart-delay 0

    clockrate 2016000

    frame-relay lmi-type cisco

    frame-relay intf-type dce

    frame-relay route 302 interface Serial0/2 203

    end

     

    R1#


    As you can see the ping is successful despite the different FR encapsulation

     

     

    As soon as I change the LMI  on the FR switch R1, both the switch interface and the DTE interfaces become "Protocol Down":

     

    R1(FR Switch):

    R1(config)#interface Serial0/3

    R1(config-if)#frame-relay lmi-type ansi

    R1(config-if)#

    *Mar  1 00:10:27.415: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/3, changed state to down

    R1(config-if)#

    R1(config-if)#

    *Mar  1 00:13:01.035: Serial0/2(in): StEnq, myseq 76

    *Mar  1 00:13:01.035: RT IE 1, length 1, type 1

    *Mar  1 00:13:01.035: KA IE 3, length 2, yourseq 77, myseq 76

    *Mar  1 00:13:01.035: Serial0/2(out): Status, myseq 77, yourseen 77, DCE up

    *Mar  1 00:13:01.411: Serial0/3: Invalid LMI type 1

    R1(config-if)#

    R3 (DTE)  :

    *Mar  1 00:14:00.875: Serial0/3(out): StEnq, myseq 20, yourseen 60, DTE down

    *Mar  1 00:14:00.875: datagramstart = 0x7A019D4, datagramsize = 13

    *Mar  1 00:14:00.875: FR encap = 0xFCF10309

    *Mar  1 00:14:00.875: 00 75 01 01 00 03 02 14 3C

    *Mar  1 00:14:00.879:

    As you can see the ping is fails with different FR LMI types between DTE-DCE

     

    Now back to normal :

     

    R2 (FRS):  ==> turn to protocol UP and start sending and receiving LMI messages

    R1(config-if)#int s0/3

    R1(config-if)#frame-relay lmi-type cisco

    *Mar  1 00:17:42.395: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/3, changed state to up

    R1(config-if)#

    *Mar  1 00:17:51.011: Serial0/2(in): StEnq, myseq 105

    *Mar  1 00:17:51.011: RT IE 1, length 1, type 1

    *Mar  1 00:17:51.011: KA IE 3, length 2, yourseq 106, myseq 105

    *Mar  1 00:17:51.011: Serial0/2(out): Status, myseq 106, yourseen 106, DCE up

    R3 (DTE): ==> turn to protocol UP and start sending and receiving LMI messages

    *Mar  1 00:17:41.875: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/3, changed state to up

     

    *Mar  1 00:18:00.875: Serial0/3(out): StEnq, myseq 44, yourseen 4, DTE up

    *Mar  1 00:18:00.875: datagramstart = 0x7B6D934, datagramsize = 13

    *Mar  1 00:18:00.875: FR encap = 0xFCF10309

    *Mar  1 00:18:00.875: 00 75 01 01 01 03 02 2C 04

    *Mar  1 00:18:00.879:

    *Mar  1 00:18:00.907: Serial0/3(in): Status, myseq 44, pak size 13

    *Mar  1 00:18:00.907: RT IE 1, length 1, type 1

    *Mar  1 00:18:00.907: KA IE 3, length 2, yourseq 5 , myseq 44

  • Legnica69 337 posts since
    Nov 13, 2010
    Currently Being Moderated
    9. Dec 15, 2011 6:35 PM (in response to abdel_n)
    Re: Frame Relay encapsulation Cisco vs. IETF

    abdel, not sure if I got it?  can u explain following?

    Frame Relay encapsulation works between DTE devices (client FR routers) and IETF encapsulation is for interoperability between Cisco and non-Cisco, so IETF on one side (Cisco device) and any other device with IETF encapsulation (Cisco devices included) should work

    so, non-cisco device cannot have cisco encapsulation, right ?

    mixing encapsulations should not work on any devices in my opinion;

  • PRASH 40 posts since
    Jun 20, 2011
    Currently Being Moderated
    10. Dec 15, 2011 11:08 PM (in response to Martin)
    Re: Frame Relay encapsulation Cisco vs. IETF

    From what I understand non Cisco routers must use the IEFT encapsulation and Cisco ones must use the default Cisco.  When i attempted to use IETF on cisco router it when into up/down state. I was using Packet tracer.

  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,397 posts since
    Oct 7, 2008
    Currently Being Moderated
    11. Dec 16, 2011 7:41 PM (in response to Martin)
    Re: Frame Relay encapsulation Cisco vs. IETF

    Newer Cisco routers will work just fine with a mismatch.  They will SEND based on what you have configured, but they will automatically RECEIVE either one.  Makes it a pain if you are working on a CCIE lab, and you miss the encapsulation part because everything "works" just fine. 

     

    The magic sometimes distracts from reality, but saves on TAC calls!

     

    Scott

  • Elvin Arias 1,855 posts since
    Mar 12, 2010

    That's very interesting, i alwasys configured both sides equally (the encap) because i though it wouldn't work if they were different. Good to know that.

     

    Elvin

  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,397 posts since
    Oct 7, 2008
    Currently Being Moderated
    14. Dec 17, 2011 4:37 AM (in response to Elvin Arias)
    Re: Frame Relay encapsulation Cisco vs. IETF

    You're welcome Martin...

     

    Elvin - And I would continue to do so!  Because that's router/IOS version dependent...  Never count on magic to solve your configuration problems!  

     

    Scott

Actions

More Like This

  • Retrieving data ...

Bookmarked By (1)