Frame relay MTUs driving me nuts - what's going on???

Discussion in 'Cisco' started by groupstudy2001, Jan 13, 2006.

  1. I have a link running frame relay. If it is set up as a simple link
    only very small packets will pass across - circa 62 bytes. Any larger
    packets seem to be silently dropped. Found when EIGRP would only
    partially form neighborships then tested with ping packets until found
    the size permitted.

    The puzzler is that if I enable frame relay fragmentation packets will
    pass OK even if the fragment sizes are larger - much larger - than 62
    bytes.

    Simple question: How can the link pass large fragments when it fails to
    pass large packets???

    If anyone can tell me what FR does when fragmenting that allows large
    fragments to pass I'd be grateful. Our router interfaces and
    subinterfaces show MTUs as 1500. The telco advises their circuits are
    ignorant of packet size.......

    Salient config at the ends (just one end shown):

    interface Serial0/0/0
    encapsulation frame-relay
    frame-relay traffic-shaping
    frame-relay lmi-type cisco
    !
    interface Serial0/0/0.1 point-to-point
    ip address 10.1.1.1 255.255.255.252
    frame-relay interface-dlci 100
    class voice-data
    !
    map-class frame-relay voice-data
    frame-relay cir 284000
    frame-relay bc 1000
    frame-relay mincir 128000
    frame-relay fragment 64
    frame-relay adaptive-shaping becn
    frame-relay fecn-adapt
    service-policy output Remote-WAN
    !
    policy-map Remote-WAN
    class voice
    priority 96
    class class-default
    fair-queue


    Possibly relevant config on the telco's FR switch:

    interface Serial0/0
    encapsulation frame-relay
    no fair-queue
    frame-relay traffic-shaping
    frame-relay lmi-type cisco
    frame-relay intf-type dce
    frame-relay route 100 interface Serial0/1 100
    !
    interface Serial0/1
    encapsulation frame-relay
    no fair-queue
    frame-relay lmi-type cisco
    frame-relay intf-type dce
    frame-relay route 100 interface Serial0/0 100
    !
    map-class frame-relay voice-data
    frame-relay adaptive-shaping becn
    frame-relay cir 384000
    frame-relay bc 1000
    frame-relay mincir 349000
    frame-relay fair-queue
    frame-relay voice bandwidth 35000
    frame-relay fragment 300
     
    groupstudy2001, Jan 13, 2006
    #1
    1. Advertisements

  2. groupstudy2001

    garrisb Guest

    is this a typo?

    map-class frame-relay voice-data
    frame-relay cir 284000 (should it be 384000?)
     
    garrisb, Jan 13, 2006
    #2
    1. Advertisements

  3. groupstudy2001

    helpdesk Guest

    Hello James,

    the BC values in your classes do not look right. The smallest value
    that you can configure is 10ms, which would be 1/100th of the CIR. Can
    you try and change the values as following:

    map-class frame-relay voice-data
    frame-relay cir 284000
    --> frame-relay bc 2840
    frame-relay mincir 128000
    frame-relay fragment 64
    frame-relay adaptive-shaping becn
    frame-relay fecn-adapt
    service-policy output Remote-WAN

    map-class frame-relay voice-data
    frame-relay adaptive-shaping becn
    frame-relay cir 384000
    frame-relay bc 3840
    frame-relay mincir 349000
    frame-relay fair-queue
    frame-relay voice bandwidth 35000
    frame-relay fragment 300

    Regards,


    www.solutionfinders.nl
    We┬┤ve got answers !
     
    helpdesk, Jan 13, 2006
    #3
  4. groupstudy2001

    Alex Guest

    The puzzler is that if I enable frame relay fragmentation packets will
    Isn't that the expected behaviour?
    When FR fragmentation on local end is disabled and on remote end is enabled
    then only frames with length less than fragment size can pass.
    http://www.cisco.com/warp/public/788/vofr/fr_frag.html
    <quote>
    FRF.12 stipulates that, when fragmentation is on for a data-link connection
    identifier (DLCI), there is fragmentation of only data frames that exceed
    the specified fragmentation size. This arrangement allows small VoIP
    packets, which are not fragmented due to the size, to be interleaved as
    frames between large data packets that have been fragmented into smaller
    frames.
    </unquote>
    Don't be mistaken by wordf "VoIP" here, in reality the router does not care
    if the frame is VoIP or not VoIP, it's the size that matters :)
    HTH
    Cheers
    Alex
     
    Alex, Jan 13, 2006
    #4
  5. Your comments and the quote seem to differ, if I follow correctly. I
    had read the Cisco information before but it doesn't seem to help.

    What you said, however, seems to be key. I think the fragmentation may
    have been on only at one end. Are you saying that if fragmentation is
    set to, say, 64 bytes that that end will only /receive/ frames of that
    size or smaller as well as transmit frames of that size? That, I think,
    would explain it.
     
    groupstudy2001, Jan 14, 2006
    #5
  6. groupstudy2001

    Alex Guest

    http://www.cisco.com/warp/public/788/vofr/fr_frag.html
    The quote above says that small packets (less than configured fragment size)
    are not fragmented.
    So when fragmentation is enabled only on remote end, any packets that are
    bigger than configured fragment size
    are dropped by remote end because they don't have FRF.12 fragmentation
    header.
    When fragmentation is enabled on both ends small packets are sent "as-is"
    and big packets
    are sent fragmented (that is , they are split into smaller ones and have
    FRF.12 fragmentation header inserted).
    Makes sense?
    HTH
    Cheers
    Alex
     
    Alex, Jan 15, 2006
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.