1 2 Previous Next 16 Replies Latest reply: Mar 11, 2012 1:36 PM by Doug Koobs RSS

    Frame Relay encapsulation Cisco vs. IETF

    Martin

      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?

        • 1. Re: Frame Relay encapsulation Cisco vs. IETF
          Warren Sullivan - CCNP

          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

          • 2. Re: Frame Relay encapsulation Cisco vs. IETF
            Warren Sullivan - CCNP

            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.....

            • 3. Re: Frame Relay encapsulation Cisco vs. IETF
              Martin

              Cisco is default;

              • 4. Re: Frame Relay encapsulation Cisco vs. IETF
                Warren Sullivan - CCNP

                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:-)

                • 5. Re: Frame Relay encapsulation Cisco vs. IETF
                  Martin

                  Scott M and I think that is important and routers fail on pings;

                  but Wendell O. wrote that it is important but routers may figure it out mismatch on encap. and pings may work just fine.

                   

                  Anybody else has an opinion ?

                  • 6. Re: Frame Relay encapsulation Cisco vs. IETF
                    durga

                    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,

                    • 7. Re: Frame Relay encapsulation Cisco vs. IETF
                      abdel_n

                      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

                      • 8. Re: Frame Relay encapsulation Cisco vs. IETF
                        Martin

                        Great work ! I also did test in GNS3 and my pings were OK between Hub and 2 other routers.

                         

                        R1#sh run int s0/0/0
                        interface Serial0/0/0
                        ip address 10.1.1.1 255.255.255.0
                        encapsulation frame-relay
                        frame-relay interface-dlci 102
                        frame-relay interface-dlci 103
                        end

                        R1#sh fram map
                        Serial0/0/0 (up): ip 10.1.1.2 dlci 102(0x66,0x1860), dynamic,
                                      broadcast,, status defined, active
                        Serial0/0/0 (up): ip 10.1.1.3 dlci 103(0x67,0x1870), dynamic,
                                      broadcast,, status defined, active
                        R1#ping 10.1.1.3

                        Type escape sequence to abort.
                        Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
                        !!!!!
                        but R3  has


                        interface Serial0/0/0
                        ip address 10.1.1.3 255.255.255.0
                        encapsulation frame-relay IETF
                        end

                        for more details see

                        https://learningnetwork.cisco.com/docs/DOC-13464

                        • 9. Re: Frame Relay encapsulation Cisco vs. IETF
                          Legnica69

                          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;

                          • 10. Re: Frame Relay encapsulation Cisco vs. IETF
                            PRASH

                            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.

                            • 11. Re: Frame Relay encapsulation Cisco vs. IETF
                              Scott Morris - CCDE/4xCCIE/2xJNCIE

                              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

                              • 12. Re: Frame Relay encapsulation Cisco vs. IETF
                                Martin

                                thanks for chiming in Scott;

                                • 13. Re: Frame Relay encapsulation Cisco vs. IETF
                                  Elvin Arias

                                  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

                                  • 14. Re: Frame Relay encapsulation Cisco vs. IETF
                                    Scott Morris - CCDE/4xCCIE/2xJNCIE

                                    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

                                    1 2 Previous Next