From: John Murphy (jt.murphy@comcast.net)
Date: Tue Mar 01 2005 - 18:27:41 GMT-3
Wow, you get no argument from me on that one Tim. Unfortunately in some
areas the MQC interface is occasionally a little unstable. Even more
unfortunate though is I won't be surprised to see the legacy method
deprecated in this case very soon. The 12.3 documentation says:
"Note Frame Relay DE group functionality is being replaced by the
Modular QoS CLI (MQC) DE marking functionality. For information about
the MQC commands that are used to configure Frame Relay DE marking,
refer to the/ Cisco IOS Quality of Service Configuration Guide/ and
/Cisco IOS Quality of Service Command Reference/."
This could be significant, especially since it seems the 'set fr-de'
option seems to not work on 2500s. :(
Which just makes your point about verify, verify,verify even more
timely. The only thing I'd add is verify, verify, verify. Then
write-mem, reload, and verify again.
I'll see if I can duplicate your results later tonight - it sounds like
a ddts may need to be filed.
Best Regards,
John
ccie2be wrote:
>Hey John,
>
>I don't remember exactly what the config was where using MQC to set the DE
>bit didn't work for locally generated traffic, but I can guarantee you that
>there is a MQC config where this doesn't work.
>
>It might be that I was using nbar to match ospf traffic or a different
>version of IOS.
>
>But, the key point I'm trying to make, perhaps not very successfully is
>this.
>
>Don't trust your config to work as expected. Verify. And verify again from
>the other side. And, use the sh fram pvc <dlci #> to verify.
>
>I once saw inconsistent results:
>
>The sh poli interface command said it was working.
>
>The show fram pvc <dlci#> showed that it wasn't.
>
>Also, there may have been sub-interfaces involved and there may have been
>FRTS shaping involved as well.
>
>The problem I was working on at the time was to configure f/r link between
>rtr 1 and rtr 2 such that if there was congestion ospf traffic would NOT be
>dropped.
>
>Now, that I think about it, I'm fairly sure the link between rtr-1 and rtr-2
>was a p2p sub-interface.
>
>And, I recall configuring MQC something like this:
>
>Class-map NOT-OSPF
> Match not prot ospf
>
>Policy-map SET-DE
> Class NOT-OSPF
> set fr-de
>
>int s0/0
>
>service-policy output SET-DE
>
>In any case, it didn't work as expected. I don't remember if I put the
>service under the physical interface or the sub-interface. But, I do
>remembered being astonished that it wasn't working.
>
>Then I spent hours testing various permutations to see which variations
>worked and which didn't work. I also spoke with Brain Dennis and Brian
>McGahan about this and determined that you have to be especially careful
>when if comes to locally generated traffic. While there weren't any problems
>with transit traffic, locally generated sometimes wasn't marked when it
>should have been. I don't remember which version of IOS I was using but I
>definitely know some combo's didn't work.
>
>So, the bottom line is this.
>
>Know both the legacy and the MQC methods of configuring DE bit setting. If
>the MQC method isn't working and you're using Nbar, replace nbar with an
>acl. If it still isn't working, use the legacy method.
>
>I couldn't find any scenario where the legacy method didn't set the DE as
>expected.
>
>HTH, Tim
>
>
>
>-----Original Message-----
>From: John Murphy [mailto:jt.murphy@comcast.net]
>Sent: Tuesday, March 01, 2005 1:43 PM
>To: ccie2be
>Cc: 'Eric Taylor'; 'Bajo'; 'kuldip singh'; 'Wayne Bellward';
>ccielab@groupstudy.com
>Subject: Re: Setting the DE bit in frame relay
>
>Seems to work as expected with 12.2(15)T12 Tim...
>
>RTR1 ------ RTR2 -------RTR3
>172.16.200.10 is the interface on RTR1
>172.16.123.3 is the serial int on rtr3
>
>
> class-map match-all fr-de
> match access-group 101
>!
>!
> policy-map frame-de
> class fr-de
> set fr-de
>!
>R2#sh access-list 101
>Extended IP access list 101
> 10 permit ip host 172.16.200.10 host 172.16.123.3 (14 matches)
>R2#
>
>R2#sh policy-map interface ser2/0
>
> Serial2/0
>
> Service-policy output: frame-de
>
> Class-map: fr-de (match-all)
> 14 packets, 1456 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: access-group 101
> QoS Set
> fr-de
> Packets marked 14
>
> Class-map: class-default (match-any)
> 87 packets, 4430 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: any
>
>
>R3#sh fram pvc 302
>
>PVC Statistics for interface Serial2/0 (Frame Relay DTE)
>
>DLCI = 302, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0
>
> input pkts 19 output pkts 28 in bytes 1976
> out bytes 2912 dropped pkts 0 in pkts dropped
>0
> out pkts dropped 0 out bytes dropped 0
> in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
> out BECN pkts 0 in DE pkts 14 out DE pkts 0
> out bcast pkts 0 out bcast bytes 0
> 5 minute input rate 0 bits/sec, 1 packets/sec
> 5 minute output rate 0 bits/sec, 0 packets/sec
> pvc create time 00:35:56, last time pvc status changed 00:35:37
>R3#
>
>
>
>
>ccie2be wrote:
>
>
>
>>Eric,
>>
>>I'm not sure that show command is trustworthy.
>>
>>What happens when you do the same thing but use the show fram pvc <dlci #>
>>instead on the remote router?
>>
>>Do you get the same results?
>>
>>Tim
>>
>>-----Original Message-----
>>From: Eric Taylor [mailto:etaylor10@tampabay.rr.com]
>>Sent: Tuesday, March 01, 2005 11:55 AM
>>To: ccie2be; 'Bajo'; 'kuldip singh'
>>Cc: 'Wayne Bellward'; ccielab@groupstudy.com
>>Subject: RE: Setting the DE bit in frame relay
>>
>>R4#ping
>>Protocol [ip]:
>>Target IP address: 172.16.10.3
>>Repeat count [5]: 200
>>Datagram size [100]:
>>Timeout in seconds [2]:
>>Extended commands [n]:
>>Sweep range of sizes [n]:
>>Type escape sequence to abort.
>>Sending 200, 100-byte ICMP Echos to 172.16.10.3, timeout is 2 seconds:
>>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>Success rate is 100 percent (200/200), round-trip min/avg/max = 56/60/108
>>
>>
>ms
>
>
>>R4#sh policy-map int s0/0
>>
>>Serial0/0
>>
>> Service-policy output: SET-DE-IP
>>
>> Class-map: ip-traffic (match-all)
>> 215 packets, 22026 bytes
>> 5 minute offered rate 2000 bps, drop rate 0 bps
>> Match: access-group 150
>> QoS Set
>> fr-de
>> Packets marked 215
>>
>> Class-map: class-default (match-any)
>> 5 packets, 65 bytes
>> 5 minute offered rate 0 bps, drop rate 0 bps
>> Match: any
>>R4#
>>
>>
>>Changed the access-list to just ospf and observed the following after
>>clearing the counters.
>>
>>R4#sh policy-map int s0/0
>>
>>Serial0/0
>>
>> Service-policy output: SET-DE-IP
>>
>> Class-map: ip-traffic (match-all)
>> 4 packets, 352 bytes
>> 5 minute offered rate 0 bps, drop rate 0 bps
>> Match: access-group 150
>> QoS Set
>> fr-de
>> Packets marked 4
>>
>> Class-map: class-default (match-any)
>> 3 packets, 89 bytes
>> 5 minute offered rate 0 bps, drop rate 0 bps
>> Match: any
>>R4#
>>
>>It looks like it is marking locally generated traffic.
>>
>>HTH,
>>Eric
>>
>>-----Original Message-----
>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>>ccie2be
>>Sent: Tuesday, March 01, 2005 11:15 AM
>>To: 'Eric Taylor'; 'Bajo'; 'kuldip singh'
>>Cc: 'Wayne Bellward'; ccielab@groupstudy.com
>>Subject: RE: Setting the DE bit in frame relay
>>
>>
>>Eric et al;
>>
>>I seem to recall that the router will NOT set the DE bit on traffic
>>originating from itself, only transit traffic.
>>
>>I believe this can be checked by doing a show fram pvc <dlci #> on the
>>remote router. Just make sure you clear the counters first.
>>
>>For example, since you're using OSPF, try setting the DE bit on just the
>>ospf traffic to see if that's possible.
>>
>>HTH, Tim
>>
>>-----Original Message-----
>>From: Eric Taylor [mailto:etaylor10@tampabay.rr.com]
>>Sent: Tuesday, March 01, 2005 10:56 AM
>>To: ccie2be; 'Bajo'; 'kuldip singh'
>>Cc: 'Wayne Bellward'; ccielab@groupstudy.com
>>Subject: RE: Setting the DE bit in frame relay
>>
>>Here is a link for doing the MQC version
>>
>>http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_gui
>>
>>
>d
>
>
>>e09186a00800804ab.html#wp1058622
>>
>>
>>
>>I just put it up in the lab and it appears to be working as advertised.
>>
>>class-map match-all ip-traffic
>> match access-group 150
>>!
>>!
>>policy-map SET-DE-IP
>> class ip-traffic
>> set fr-de
>>!
>>access-list 150 permit ip any any
>>!
>>interface Serial0/0
>>ip address 172.16.10.4 255.255.255.0
>>service-policy output SET-DE-IP <--- I want to set the DE bit on all
>>outbound traffic on all PVCs
>>encapsulation frame-relay
>>ip ospf network broadcast
>>ip ospf priority 0
>>frame-relay map ip 172.16.10.1 203
>>frame-relay map ip 172.16.10.2 204 broadcast
>>frame-relay map ip 172.16.10.3 203 broadcast
>>frame-relay map ip 172.16.10.4 203
>>no frame-relay inverse-arp
>>!
>>
>>R4#sh policy-map int s0/0
>>
>>Serial0/0
>>
>> Service-policy output: SET-DE-IP
>>
>> Class-map: ip-traffic (match-all)
>> 59 packets, 5040 bytes
>> 5 minute offered rate 0 bps, drop rate 0 bps
>> Match: access-group 150
>> QoS Set
>> fr-de
>> Packets marked 59 <------ Shows that the packets are being
>>marked.
>>
>> Class-map: class-default (match-any)
>> 18 packets, 234 bytes
>> 5 minute offered rate 0 bps, drop rate 0 bps
>> Match: any
>>R4#
>>
>>HTH,
>>Eric
>>
>>
>>-----Original Message-----
>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>>ccie2be
>>Sent: Tuesday, March 01, 2005 10:23 AM
>>To: 'Bajo'; 'kuldip singh'
>>Cc: 'Wayne Bellward'; ccielab@groupstudy.com
>>Subject: RE: Setting the DE bit in frame relay
>>
>>
>>The frame congestion-management command you refer to is configured on the
>>frame relay switch not on endpoints of the frame circuit.
>>
>>It should also be noted that when using the legacy global command to define
>>which traffic should have the DE bit set,
>>
>>frame-relay de-list # protocol ip gt 512,
>>
>>another command must also be used to associate this traffic with a dlci.
>>This command is
>>
>>frame de-group # <dlci>e de-group # <dlci>
>>
>>Think of this the same way you do with acl's: 1 command to define which
>>traffic is affected and a 2nd command to apply it to the interface. The big
>>difference is that when setting the DE bit, you need to apply the defined
>>traffic to a dlci, not an interface.
>>
>>Also, you should be aware that the DE bit can also be set by using the new
>>MQC syntax.
>>
>>HTH, Tim
>>
>>-----Original Message-----
>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>>
>>
>Bajo
>
>
>>Sent: Tuesday, March 01, 2005 9:54 AM
>>To: kuldip singh
>>Cc: Wayne Bellward; ccielab@groupstudy.com
>>Subject: Re: Setting the DE bit in frame relay
>>
>>Wayne,
>>
>>A search on the DOC-CD:
>>http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fwa
>>
>>
>n
>
>
>>_c/wcffrely.htm
>>
>>"When the output interface queue reaches or exceeds the ECN excess
>>threshold, all Frame Relay DE bit packets on all PVCs crossing that
>>interface will be marked with FECN or BECN, depending on their
>>direction of travel. When the queue reaches or exceeds the ECN
>>committed threshold, all Frame Relay packets will be marked with FECN
>>or BECN."
>>
>>
>>R1(config-if)#frame co?
>>congestion-management
>>
>>R1(config-if)#frame co
>>
>>R1(config-fr-congest)#?
>>Frame Relay congestion management configuration commands:
>>default Set a command to its defaults
>>exit Exit from frame relay congestion management configuration mode
>>no Negate a command or set its defaults
>>threshold Configure Frame Relay congestion thresholds
>><cr>
>>
>>R1(config-fr-congest)#thres?
>>threshold
>>
>>R1(config-fr-congest)#thres ?
>>de Configure Frame Relay DE discard threshold
>>ecn Configure Frame Relay ECN congestion thresholds
>>
>>R1(config-fr-congest)#thres
>>
>>interface serial1
>>
>> encapsulation frame-relay
>>
>> frame-relay intf-type dce
>>
>> frame-relay congestion-management
>>
>> threshold ecn be 0
>>
>> threshold ecn bc 20
>>
>> threshold de 40
>>
>>
>>On Tue, 1 Mar 2005 13:55:34 +0000, kuldip singh <dipa.singh@gmail.com>
>>wrote:
>>
>>
>>
>>
>>>Wayne,
>>> Below is example of how to use the de-list:
>>>
>>>The following example specifies that IP packets larger than 512 bytes
>>>(including the 4-byte Frame Relay Encapsulation) will have the DE bit
>>>set:
>>>
>>>frame-relay de-list 1 protocol ip gt 512
>>>
>>>
>>>On Tue, 1 Mar 2005 13:15:55 +0000, Wayne Bellward <wbellward@gmail.com>
>>>
>>>
>>>
>>>
>>wrote:
>>
>>
>>
>>
>>>>Hi,
>>>>
>>>>This is the first time i've actually posted a question, the archives
>>>>have always been great in the past. I'm sure someone can help and it
>>>>would be greatly appreciated.
>>>>
>>>>I'd like to set the discard eligible bit for ip on my standard frame
>>>>relay interface and can't seem to find anything substantial on this or
>>>>how to confirm it. I have a 2521 as my frame switch and am using frame
>>>>route commands so I'm not even sure I can confirm any of the FRTS
>>>>functions i configure.
>>>>
>>>>interface Serial0
>>>>ip address 137.20.101.2 255.255.255.0
>>>>encapsulation frame-relay
>>>>ip ospf network broadcast
>>>>ip ospf priority 0
>>>>no fair-queue
>>>>frame-relay interface-dlci 201
>>>>end
>>>>
>>>>Any help or advise on this would be great.
>>>>
>>>>Many Thanks,
>>>>
>>>>Wayne
>>>>
>>>>_______________________________________________________________________
>>>>Subscription information may be found at:
>>>>http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>
>>>_______________________________________________________________________
>>>Subscription information may be found at:
>>>http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>--
>>Kind Regards,
>>
>>Bajo
>>
>>_______________________________________________________________________
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>>_______________________________________________________________________
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>>_______________________________________________________________________
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>>_______________________________________________________________________
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>>
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:38 GMT-3