Sample conf about 837 that does not work correctly

[emagallo]

Hello.

I'm trying the conf found in the following URL to work:

http://www.cisco.com/en/US/products/hw/routers/ps380/products_configuration_guide_chapter09186a00801dcb1c.html#1071853

For testing, I send a huge message via SMTP. This traffic has 128k reserved in the policy map.

Meanwhile, I send a huge message via webmail over the DSL so the uplink gets full. I don't reserve banwidth for that. When this starts, the other traffic slow down the speed to 40kbps aprox (so reservation does not work) and I see how the ATM interface reports output drops.

When I query the state of the policy map applied to the interface (show policy-map interface dialer 1) I see matches over the class map but no matches over the queue (pkts matched/bytes matched).

If I query the Dialer queue (show queue dialer 1) I see it's always empty but if I query the ATM queue I can see the wfq queue with both conversations.

If you try similar confs you'll see the same.

Could be probably a bug or an error configuration? Which conf would work correctly?

Many thanks.

[mchin345]

Just send me the output of the following cmds:

1.sh class-map

2.sh policy-map

3.sh access-list

4.sh queue

i need these information's to track the output

[emagallo]

First of all, thanks for replying.

The info you requested is attached.

This router is connected to a ISP so can't negotiate the LFI feature, but I think this would be independent of the CBWFQ.

I've noticed too that the queueing mechanism in the Dialer interface (weighted fair) is not cloned to the Virtual-Access. I've tried to upgrade the IOS too to the latest 11.3T version but still not working.

Instead, I've tried it with a Virtual Template and it works, but I have problems with the negotiated IP address and the NAT feature.

I've found the following technote, where you can read: ...the DSL interfaces do not support service policies that apply fancy queueing since these interfaces do not implement the "back-pressure algorithm" necessary to signal that excess packets should be queued by the Layer 3 (L3) queueing system.

http://www.cisco.com/en/US/customer/tech/tk543/tk545/technologies_tech_note09186a00800b2d29.shtml

I've found some other posts with similar problems.

Could be probably a bug or a limited feature?