AS5800 not working with Windows 95 - but works with everything else?

Discussion in 'Cisco' started by Vinny Abello, Dec 2, 2003.

  1. Vinny Abello

    Vinny Abello Guest

    Hi all,

    We recently replaced a Portmaster 4 with a Cisco AS5800. Everything is
    fine except that our Windows 95 users cannot pass IP traffic (good
    thing most people don't use Windows 95 anymore). I am thinking the
    issue might be with incompatible negotiated compression as I saw this
    with Windows 98 users during testing. I had previously defined on the
    dialer group and group-async "compress stac" which caused issues for
    Windows 98 working. I replaced it with "compress mppc" and it fixed
    the Win98 people. We never had Win95 person test it so now that we're
    trying to use it we're finding this problem with the handful of 95
    users out there. Any ideas about what the differences are? I want to
    be able to use stac for devices that support it (which currently works
    even with compress mppc as it's negotiated automatically) and mppc
    compression for clients that support that.

    The other thing I thought of was somehow Windows 95 wasn't getting the
    right gateway info. The client comes online but I can't ping the
    address assigned to them. I unfortunately don't have a Windows 95
    machine to test with to reproduce the problem. Every other type of
    router, Windows OS, Mac OS and a couple Linux OS's we've had people
    try work just fine.

    I can't easily debug this as we have hundreds of users using this
    system now and I'll get flooded with PPP debug output. :(

    We're running IOS 12.3(3) on the AS5800. Here is some sample of my
    configuration which I believe would be useful in troubleshooting.


    All PRI's are configured as such:

    interface Serial1/0/0:23
    no ip address
    encapsulation ppp
    ip tcp header-compression
    dialer rotary-group 0
    dialer-group 1
    isdn switch-type primary-ni
    isdn incoming-voice modem
    compress mppc
    no cdp enable
    ppp authentication pap chap
    ppp multilink

    Virtual Template used for multilink PPP is as follows:

    interface Virtual-Template1
    ip unnumbered Loopback1
    ip tcp header-compression
    no snmp trap link-status
    peer default ip address pool FocalDialPool
    compress mppc
    ppp authentication pap chap PPPDialup
    ppp ipcp dns 216.182.4.5 216.182.1.2
    ppp multilink
    ppp timeout idle 1200 inbound

    Dialer being used is configured as such:

    interface Dialer0
    ip unnumbered Loopback1
    ip idle-group 101 in
    encapsulation ppp
    ip tcp header-compression
    dialer in-band
    dialer-group 1
    ntp disable
    no snmp trap link-status
    peer default ip address pool FocalDialPool
    compress mppc
    no cdp enable
    ppp authentication pap chap PPPDialup
    ppp ipcp dns 216.182.4.5 216.182.1.2
    ppp multilink
    ppp timeout idle 1200 inbound

    Group-Async is configured as follows:

    interface Group-Async0
    ip unnumbered Loopback1
    encapsulation ppp
    ip tcp header-compression
    no ip mroute-cache
    load-interval 30
    ntp disable
    no snmp trap link-status
    async mode interactive
    peer default ip address pool FocalDialPool
    compress mppc
    ppp authentication pap chap PPPDialup
    ppp ipcp dns 216.182.4.5 216.182.1.2
    ppp multilink
    group-range 1/4/00 1/11/143

    All lines are configured as such:

    line 1/4/00 1/4/143
    no motd-banner
    no exec-banner
    no flush-at-activation
    no modem callout
    modem Dialin
    modem autoconfigure type MICA_2940
    no modem log rs232
    autoselect during-login
    autoselect ppp



    Any help in fixing this would greatly be appreciated. Any help on the
    side pointing out stupid things I have defined in my config would also
    be appreciated. :) Sorry for not posting the whole config, but there
    are security concerns in posting our whole config.
     
    Vinny Abello, Dec 2, 2003
    #1
    1. Advertisements

  2. Vinny Abello

    Vinny Abello Guest

    Not to reply to my own post or anything, but we're also having
    horrible stability problems with the box when it's under load. About
    400 connections or so and it starts having problems responding to
    pings from the loopback address, and right before it died the last
    time it didn't seem to understand commands I was typing. Memory leak?
    Last I noticed, I only had 27MB free RAM earlier in the day. There is
    256MB on the NPE300 and that didn't have a huge call volume on it.
     
    Vinny Abello, Dec 2, 2003
    #2
    1. Advertisements

  3. Vinny Abello

    Vinny Abello Guest

    OK, I'm replying to my own post again, but I think we found that the
    source of the stability problems are because of lingering Nachi
    infections. Our symptoms match those of other people that posted back
    in August about it. We never had an issue with the Portmasters with
    Nachi... Oh well. Live and learn I guess. I'm trying to impliment
    certain things to fix that now.

    Anyway, we still have the Windows 95 issue... I actually have a couple
    customers bringing their Win95 boxen in, so if I figure it out, I'll
    post the answer in case some future person runs across the same issue.
    Hopefully Windows 95 will be completely extinct at that time. ;)
    Still, if anyone knows the answer, all help is appreciated. Thanks!
     
    Vinny Abello, Dec 2, 2003
    #3
  4. An AS5800 with NPE-300 can support (ballpark figures here)
    about 40 calls doing STAC/MPPC. I'd recommend that you
    turn it off.

    I don't know why your Win95 users are having problems;
    I don't even have a theory.

    Aaron

    ---

    ~ Not to reply to my own post or anything, but we're also having
    ~ horrible stability problems with the box when it's under load. About
    ~ 400 connections or so and it starts having problems responding to
    ~ pings from the loopback address, and right before it died the last
    ~ time it didn't seem to understand commands I was typing. Memory leak?
    ~ Last I noticed, I only had 27MB free RAM earlier in the day. There is
    ~ 256MB on the NPE300 and that didn't have a huge call volume on it.
    ~
    ~ On Tue, 02 Dec 2003 15:38:24 -0500, Vinny Abello <>
    ~ wrote:
    ~
    ~ >Hi all,
    ~ >
    ~ >We recently replaced a Portmaster 4 with a Cisco AS5800. Everything is
    ~ >fine except that our Windows 95 users cannot pass IP traffic (good
    ~ >thing most people don't use Windows 95 anymore). I am thinking the
    ~ >issue might be with incompatible negotiated compression as I saw this
    ~ >with Windows 98 users during testing. I had previously defined on the
    ~ >dialer group and group-async "compress stac" which caused issues for
    ~ >Windows 98 working. I replaced it with "compress mppc" and it fixed
    ~ >the Win98 people. We never had Win95 person test it so now that we're
    ~ >trying to use it we're finding this problem with the handful of 95
    ~ >users out there. Any ideas about what the differences are? I want to
    ~ >be able to use stac for devices that support it (which currently works
    ~ >even with compress mppc as it's negotiated automatically) and mppc
    ~ >compression for clients that support that.
    ~ >
    ~ >The other thing I thought of was somehow Windows 95 wasn't getting the
    ~ >right gateway info. The client comes online but I can't ping the
    ~ >address assigned to them. I unfortunately don't have a Windows 95
    ~ >machine to test with to reproduce the problem. Every other type of
    ~ >router, Windows OS, Mac OS and a couple Linux OS's we've had people
    ~ >try work just fine.
    ~ >
    ~ >I can't easily debug this as we have hundreds of users using this
    ~ >system now and I'll get flooded with PPP debug output. :(
    ~ >
    ~ >We're running IOS 12.3(3) on the AS5800. Here is some sample of my
    ~ >configuration which I believe would be useful in troubleshooting.
    ~ >
    ~ >
    ~ >All PRI's are configured as such:
    ~ >
    ~ >interface Serial1/0/0:23
    ~ > no ip address
    ~ > encapsulation ppp
    ~ > ip tcp header-compression
    ~ > dialer rotary-group 0
    ~ > dialer-group 1
    ~ > isdn switch-type primary-ni
    ~ > isdn incoming-voice modem
    ~ > compress mppc
    ~ > no cdp enable
    ~ > ppp authentication pap chap
    ~ > ppp multilink
    ~ >
    ~ >Virtual Template used for multilink PPP is as follows:
    ~ >
    ~ >interface Virtual-Template1
    ~ > ip unnumbered Loopback1
    ~ > ip tcp header-compression
    ~ > no snmp trap link-status
    ~ > peer default ip address pool FocalDialPool
    ~ > compress mppc
    ~ > ppp authentication pap chap PPPDialup
    ~ > ppp ipcp dns 216.182.4.5 216.182.1.2
    ~ > ppp multilink
    ~ > ppp timeout idle 1200 inbound
    ~ >
    ~ >Dialer being used is configured as such:
    ~ >
    ~ >interface Dialer0
    ~ > ip unnumbered Loopback1
    ~ > ip idle-group 101 in
    ~ > encapsulation ppp
    ~ > ip tcp header-compression
    ~ > dialer in-band
    ~ > dialer-group 1
    ~ > ntp disable
    ~ > no snmp trap link-status
    ~ > peer default ip address pool FocalDialPool
    ~ > compress mppc
    ~ > no cdp enable
    ~ > ppp authentication pap chap PPPDialup
    ~ > ppp ipcp dns 216.182.4.5 216.182.1.2
    ~ > ppp multilink
    ~ > ppp timeout idle 1200 inbound
    ~ >
    ~ >Group-Async is configured as follows:
    ~ >
    ~ >interface Group-Async0
    ~ > ip unnumbered Loopback1
    ~ > encapsulation ppp
    ~ > ip tcp header-compression
    ~ > no ip mroute-cache
    ~ > load-interval 30
    ~ > ntp disable
    ~ > no snmp trap link-status
    ~ > async mode interactive
    ~ > peer default ip address pool FocalDialPool
    ~ > compress mppc
    ~ > ppp authentication pap chap PPPDialup
    ~ > ppp ipcp dns 216.182.4.5 216.182.1.2
    ~ > ppp multilink
    ~ > group-range 1/4/00 1/11/143
    ~ >
    ~ >All lines are configured as such:
    ~ >
    ~ >line 1/4/00 1/4/143
    ~ > no motd-banner
    ~ > no exec-banner
    ~ > no flush-at-activation
    ~ > no modem callout
    ~ > modem Dialin
    ~ > modem autoconfigure type MICA_2940
    ~ > no modem log rs232
    ~ > autoselect during-login
    ~ > autoselect ppp
    ~ >
    ~ >
    ~ >
    ~ >Any help in fixing this would greatly be appreciated. Any help on the
    ~ >side pointing out stupid things I have defined in my config would also
    ~ >be appreciated. :) Sorry for not posting the whole config, but there
    ~ >are security concerns in posting our whole config.
     
    Aaron Leonard, Dec 2, 2003
    #4
  5. Vinny Abello

    Vinny Abello Guest

    Wow. Only 40?? We allowed all users on the Portmasters to do stac as
    far as I know. (I didn't originally configure them). Then again, the
    Portmasters didn't have a need for a "show cpu" type of thing because
    it wasn't possible to exhaust the cpu because of the architectural
    design (from what I'm told by one of the designers of the PM's).

    I'm still adjusting to the differences between the two. :)

    I have a Windows 95 machine that was just dropped off as I'm typing
    this. I'll give it a shot, probably remove the compress mppc and see
    how it goes. I'll post back to the list for everyone's benefit.
     
    Vinny Abello, Dec 2, 2003
    #5
  6. Vinny Abello

    Vinny Abello Guest

    Which process does the compression take place in? The only thing we
    are seeing consume a lot of CPU is the IP Input process. With around
    520 users currently online it's averaging around 50 to 60% CPU load. I
    don't know if a lot of that is just from lingering Nachi infections.

    I stopped the memory from being exhausted by turning off route-caching
    on the fastethernet interface that connects back to our core router. I
    found this suggestion on a message board. I didn't wanted try that
    first before policy routing on the dialer and virtual templates and
    break Windows traceroute which I know my customers would scream about.
    It seems to have completely stabilized the router.

    We were wondering, if we wanted to do compression still, would it be
    better for us to "downgrade" the chassis to a 7206 non VXR and add an
    SA-COMP/4 card to offload all MPPC/STAC compression to? Or is there
    another service adapter that we could offload compression to that
    would work in a VXR chassis?
     
    Vinny Abello, Dec 3, 2003
    #6
  7. Vinny Abello

    jurjen.bos Guest

    Hi,

    Windows 95 is using another chap protocol

    You can try to use the folloing in you're dialer

    ppp authentication pap chap PPPDialup mschap

    HTH

    /jurjen
     
    jurjen.bos, Dec 3, 2003
    #7
  8. Vinny Abello

    Vinny Abello Guest

    The authentication is not the problem. Users authenticate with no
    problem using PAP or CHAP.

    The issue was actually related to the compression I had enabled. I had
    a Windows 95 machine here finally. I tested with it. It logs on and
    authenticates with no problem. No IP traffic can be passed. I then
    unchecked software compression in the dial-up connection Windows 95
    and it worked. At that point, I downloaded the Windows 95 DUN 1.3
    update (I know there is a 1.4 but I wanted to try 1.3 first). I
    installed that, then turned compression back on and it negotiated MPPC
    compression and worked without a problem. I don't think the original
    Windows 95 actually had support for MPPC, only stac. I don't think
    MPPC was even around at the time 95 was introduced. It only came later
    with that upgrade.

    At any rate, I removed the compression from my virtual-template and
    dialer interfaces because it was causing severe performance problems
    under high load.

    The other issue was the Nachi worm sending out all the icmp echo's to
    ranges of IP's. It was filling up the route cache and causing the
    memory to be exhausted. Despite Cisco's recommendations to block that
    traffic using policy routing (and breaking Windows traceroute as a
    result) I tried something I found on a message board. I turned of
    route-cache on the fast ethernet interface that is facing our network.
    That immediately stabilized the memory load and I can't detect any
    performance problems as a result. Route-caching is still enabled for
    the dialer and virtual-templates.

    After all that, we now seem to have a stable AS5800. :)

    I've got some more questions about the AS5800, but I'll do a little
    more research before I post on that and see if I can find the answers.
     
    Vinny Abello, Dec 3, 2003
    #8
  9. ~ Which process does the compression take place in? The only thing we
    ~ are seeing consume a lot of CPU is the IP Input process. With around
    ~ 520 users currently online it's averaging around 50 to 60% CPU load. I
    ~ don't know if a lot of that is just from lingering Nachi infections.

    Yeah, software compression would be in IP Input.

    ~ I stopped the memory from being exhausted by turning off route-caching
    ~ on the fastethernet interface that connects back to our core router.

    Yikes, this would punish the CPU even worse.

    ~ I
    ~ found this suggestion on a message board. I didn't wanted try that
    ~ first before policy routing on the dialer and virtual templates and
    ~ break Windows traceroute which I know my customers would scream about.
    ~ It seems to have completely stabilized the router.

    Um, OK, but really, the 5800 wants to run CEF or at least fastswitched.

    If you are fastswitching but are sufferent from route cache bloat
    due to infected MS clients, then I'd recommend that you address
    this not by disabling fastswitching, but by ageing the route cache
    quicker. I recommend " ip cache-ager 20 3 3" -- see the discussion
    in http://www.cisco.com/warp/public/63/ts_codred_worm.shtml .

    ~ We were wondering, if we wanted to do compression still, would it be
    ~ better for us to "downgrade" the chassis to a 7206 non VXR and add an
    ~ SA-COMP/4 card to offload all MPPC/STAC compression to? Or is there
    ~ another service adapter that we could offload compression to that
    ~ would work in a VXR chassis?

    Well, I guess you could go non-VXR and put in an SA-COMP/4
    - I see that we DO assert that this is supported
    (http://www.cisco.com/warp/public/cc/pd/as/as5800/prodlit/as58_ov.htm),
    although I've never seen anyone DO this, so this would be
    a ways off the beaten path.

    Our plan for supporting lots of STAC/MPPC on a VXR is
    (I guess) to use the NPE-G1, but the NPE-G1 is not supported
    on the 5800 RS.

    Realistically, the AS5800 is designed for very large scale
    dialin PPP analog modem use. In that environment, V.42bis/V.44
    compression scales quite nicely; you don't need STAC/MPPC.

    Aaron

    ---

    ~ On Tue, 02 Dec 2003 14:41:26 -0800, Aaron Leonard <>
    ~ wrote:
    ~
    ~ >An AS5800 with NPE-300 can support (ballpark figures here)
    ~ >about 40 calls doing STAC/MPPC. I'd recommend that you
    ~ >turn it off.
    ~ >
    ~ >I don't know why your Win95 users are having problems;
    ~ >I don't even have a theory.
    ~ >
    ~ >Aaron
    ~ >
    ~ >---
    ~ >
    ~ >~ Not to reply to my own post or anything, but we're also having
    ~ >~ horrible stability problems with the box when it's under load. About
    ~ >~ 400 connections or so and it starts having problems responding to
    ~ >~ pings from the loopback address, and right before it died the last
    ~ >~ time it didn't seem to understand commands I was typing. Memory leak?
    ~ >~ Last I noticed, I only had 27MB free RAM earlier in the day. There is
    ~ >~ 256MB on the NPE300 and that didn't have a huge call volume on it.
    ~ >~
    ~ >~ On Tue, 02 Dec 2003 15:38:24 -0500, Vinny Abello <>
    ~ >~ wrote:
    ~ >~
    ~ >~ >Hi all,
    ~ >~ >
    ~ >~ >We recently replaced a Portmaster 4 with a Cisco AS5800. Everything is
    ~ >~ >fine except that our Windows 95 users cannot pass IP traffic (good
    ~ >~ >thing most people don't use Windows 95 anymore). I am thinking the
    ~ >~ >issue might be with incompatible negotiated compression as I saw this
    ~ >~ >with Windows 98 users during testing. I had previously defined on the
    ~ >~ >dialer group and group-async "compress stac" which caused issues for
    ~ >~ >Windows 98 working. I replaced it with "compress mppc" and it fixed
    ~ >~ >the Win98 people. We never had Win95 person test it so now that we're
    ~ >~ >trying to use it we're finding this problem with the handful of 95
    ~ >~ >users out there. Any ideas about what the differences are? I want to
    ~ >~ >be able to use stac for devices that support it (which currently works
    ~ >~ >even with compress mppc as it's negotiated automatically) and mppc
    ~ >~ >compression for clients that support that.
    ~ >~ >
    ~ >~ >The other thing I thought of was somehow Windows 95 wasn't getting the
    ~ >~ >right gateway info. The client comes online but I can't ping the
    ~ >~ >address assigned to them. I unfortunately don't have a Windows 95
    ~ >~ >machine to test with to reproduce the problem. Every other type of
    ~ >~ >router, Windows OS, Mac OS and a couple Linux OS's we've had people
    ~ >~ >try work just fine.
    ~ >~ >
    ~ >~ >I can't easily debug this as we have hundreds of users using this
    ~ >~ >system now and I'll get flooded with PPP debug output. :(
    ~ >~ >
    ~ >~ >We're running IOS 12.3(3) on the AS5800. Here is some sample of my
    ~ >~ >configuration which I believe would be useful in troubleshooting.
    ~ >~ >
    ~ >~ >
    ~ >~ >All PRI's are configured as such:
    ~ >~ >
    ~ >~ >interface Serial1/0/0:23
    ~ >~ > no ip address
    ~ >~ > encapsulation ppp
    ~ >~ > ip tcp header-compression
    ~ >~ > dialer rotary-group 0
    ~ >~ > dialer-group 1
    ~ >~ > isdn switch-type primary-ni
    ~ >~ > isdn incoming-voice modem
    ~ >~ > compress mppc
    ~ >~ > no cdp enable
    ~ >~ > ppp authentication pap chap
    ~ >~ > ppp multilink
    ~ >~ >
    ~ >~ >Virtual Template used for multilink PPP is as follows:
    ~ >~ >
    ~ >~ >interface Virtual-Template1
    ~ >~ > ip unnumbered Loopback1
    ~ >~ > ip tcp header-compression
    ~ >~ > no snmp trap link-status
    ~ >~ > peer default ip address pool FocalDialPool
    ~ >~ > compress mppc
    ~ >~ > ppp authentication pap chap PPPDialup
    ~ >~ > ppp ipcp dns 216.182.4.5 216.182.1.2
    ~ >~ > ppp multilink
    ~ >~ > ppp timeout idle 1200 inbound
    ~ >~ >
    ~ >~ >Dialer being used is configured as such:
    ~ >~ >
    ~ >~ >interface Dialer0
    ~ >~ > ip unnumbered Loopback1
    ~ >~ > ip idle-group 101 in
    ~ >~ > encapsulation ppp
    ~ >~ > ip tcp header-compression
    ~ >~ > dialer in-band
    ~ >~ > dialer-group 1
    ~ >~ > ntp disable
    ~ >~ > no snmp trap link-status
    ~ >~ > peer default ip address pool FocalDialPool
    ~ >~ > compress mppc
    ~ >~ > no cdp enable
    ~ >~ > ppp authentication pap chap PPPDialup
    ~ >~ > ppp ipcp dns 216.182.4.5 216.182.1.2
    ~ >~ > ppp multilink
    ~ >~ > ppp timeout idle 1200 inbound
    ~ >~ >
    ~ >~ >Group-Async is configured as follows:
    ~ >~ >
    ~ >~ >interface Group-Async0
    ~ >~ > ip unnumbered Loopback1
    ~ >~ > encapsulation ppp
    ~ >~ > ip tcp header-compression
    ~ >~ > no ip mroute-cache
    ~ >~ > load-interval 30
    ~ >~ > ntp disable
    ~ >~ > no snmp trap link-status
    ~ >~ > async mode interactive
    ~ >~ > peer default ip address pool FocalDialPool
    ~ >~ > compress mppc
    ~ >~ > ppp authentication pap chap PPPDialup
    ~ >~ > ppp ipcp dns 216.182.4.5 216.182.1.2
    ~ >~ > ppp multilink
    ~ >~ > group-range 1/4/00 1/11/143
    ~ >~ >
    ~ >~ >All lines are configured as such:
    ~ >~ >
    ~ >~ >line 1/4/00 1/4/143
    ~ >~ > no motd-banner
    ~ >~ > no exec-banner
    ~ >~ > no flush-at-activation
    ~ >~ > no modem callout
    ~ >~ > modem Dialin
    ~ >~ > modem autoconfigure type MICA_2940
    ~ >~ > no modem log rs232
    ~ >~ > autoselect during-login
    ~ >~ > autoselect ppp
    ~ >~ >
    ~ >~ >
    ~ >~ >
    ~ >~ >Any help in fixing this would greatly be appreciated. Any help on the
    ~ >~ >side pointing out stupid things I have defined in my config would also
    ~ >~ >be appreciated. :) Sorry for not posting the whole config, but there
    ~ >~ >are security concerns in posting our whole config.
     
    Aaron Leonard, Dec 3, 2003
    #9
  10. Vinny Abello

    Vinny Abello Guest

    OK, that makes sense.
    That's what I thought at first, but doesn't seem that bad. With
    ~500-600 users connected the CPU stays around 30%. We have 362 online
    right now at 10% CPU load. There is only a default route pointing to
    our network and the routes in our IGP are fairly low. Don't know if
    that has anything to do with it.
    Sure, I'd like to also. :)
    I'd definitely like to have cef running on all interfaces. In looking
    at this and looking at my AS5800, I don't see this is an available
    option when in config mode. I tried typing it in and it's not
    understood. I also tried under the FastEthernet interface and it's not
    understood either.
    Like many other Cisco unsupported things, does it or will it work in
    theory even though it's not yet supported?

    Will it be supported in the future?

    Well, V.42bis dies at the modem's limitation of 115.2 on most modems,
    particularly the hardware based ones limited by the serial port speed.
    I agree V.44 probably works well as it's usually only available on
    software based modems which bypass any serial limitation, but I
    haven't had enough time to do benchmarks. ALL (Windows) users were
    getting excellent throughput with MPPC if they had software
    compression enabled (default). We had tests showing compressed data
    being transfered at over 400kbps on a ~50kbps modem connection.
     
    Vinny Abello, Dec 4, 2003
    #10
  11. ~ >~ I stopped the memory from being exhausted by turning off route-caching
    ~ >~ on the fastethernet interface that connects back to our core router.
    ~ >
    ~ >Yikes, this would punish the CPU even worse.
    ~
    ~ That's what I thought at first, but doesn't seem that bad. With
    ~ ~500-600 users connected the CPU stays around 30%. We have 362 online
    ~ right now at 10% CPU load. There is only a default route pointing to
    ~ our network and the routes in our IGP are fairly low. Don't know if
    ~ that has anything to do with it.

    No sense arguing with success then. If you're using 30% CPU
    at 600 users, then I'd say stick with what you're doing :)

    ~ >Our plan for supporting lots of STAC/MPPC on a VXR is
    ~ >(I guess) to use the NPE-G1, but the NPE-G1 is not supported
    ~ >on the 5800 RS.
    ~
    ~ Like many other Cisco unsupported things, does it or will it work in
    ~ theory even though it's not yet supported?
    ~
    ~ Will it be supported in the future?

    I can't say whether the NPE-G1 might or might not work
    in the 5800 RS. But I can DEFINITELY tell you that
    this is not supported, and as far as I know, there are
    no plans to support it. For very large scale dial/voice
    access, our development work has been in the AS5850.

    ~ >Realistically, the AS5800 is designed for very large scale
    ~ >dialin PPP analog modem use. In that environment, V.42bis/V.44
    ~ >compression scales quite nicely; you don't need STAC/MPPC.
    ~
    ~ Well, V.42bis dies at the modem's limitation of 115.2 on most modems,
    ~ particularly the hardware based ones limited by the serial port speed.

    That's true of V.44 as well as V.42bis. However, hardware
    based modems are in practice increasingly rare any more. On the
    great majority of client modems now, V.42bis and V.44 are
    really "software" compression - i.e. performed by the PC
    CPU and so not subject to serial port limitations.

    ~ I agree V.44 probably works well as it's usually only available on
    ~ software based modems which bypass any serial limitation, but I
    ~ haven't had enough time to do benchmarks. ALL (Windows) users were
    ~ getting excellent throughput with MPPC if they had software
    ~ compression enabled (default). We had tests showing compressed data
    ~ being transfered at over 400kbps on a ~50kbps modem connection.

    With V.44 compression enabled in our newer NextPort modems
    (available in the UPC324 for the 5800/5850, also in the
    5350/5400), we have measured 400kbps as well. With the
    older MICA modems, we have measured 200kbps with V.44, and
    180kbps with V.42bis.

    With real-world data, of course, it is rare that you will
    often encounter data patterns that are compressible to
    anything like 400kbps.

    Regards,

    Aaron
     
    Aaron Leonard, Dec 5, 2003
    #11
  12. Vinny Abello

    Vinny Abello Guest

    That's what I figured. :)
    Understood. Of course that is why the 5800 is no longer sold and the
    5850 is. No sense in breathing life into something that could compete
    with your newer model. ;)
    Oddly, I have a USR Performance Pro modem which has a hardware based
    controller (in other words, it's 3 times more expensive than the other
    modems in Walmart) and it support v.92... but not really. I didn't
    find out until recently that USR doesn't bother implimenting v.44
    compression on their hardware based or external v.92 modems for
    obvious reasons. Fastconnect and modem on hold work fine. Can't test
    pcm.upstream as it's not supported on the AS5800 with our MICA's.
    What are the major differences between the MICA modems and the
    NextPort modems? We have all MICA modems and they seem to work fairly
    well so far. Obviously, the DSP seems faster if V.44 gives greater
    throughput, but what else?
    Of course, but it looks really impressive to users that you can point
    to a test with highly compressible data! :) Some users did notice a
    big increase in web pages (HTML) loading.

    Thanks for all your information by the way. It's much appreciated!
     
    Vinny Abello, Dec 6, 2003
    #12
  13. Vinny Abello

    Robert Boyle Guest

    Will a VAM2 in the 5800 RS enable full STAC/MPPC support for 1000+
    sessions? If so, it may be worth buying one. We are running 12.3 so it
    should be supported in IOS if we update to 12.3T. The spec sheets just
    say it supports STAC, but they never mention how many sessions or how
    much bandwidth it can compress. Thanks for your help and suggestions.

    -Robert
     
    Robert Boyle, Dec 6, 2003
    #13
  14. [ ... ]

    ~ >With V.44 compression enabled in our newer NextPort modems
    ~ >(available in the UPC324 for the 5800/5850, also in the
    ~ >5350/5400), we have measured 400kbps as well. With the
    ~ >older MICA modems, we have measured 200kbps with V.44, and
    ~ >180kbps with V.42bis.
    ~
    ~ What are the major differences between the MICA modems and the
    ~ NextPort modems? We have all MICA modems and they seem to work fairly
    ~ well so far. Obviously, the DSP seems faster if V.44 gives greater
    ~ throughput, but what else?

    For ordinary modem applications (V.34/V.90/V.92 QC/MoH, with
    V.42bis/V.44), the observed performance should be very close
    between MICA and NextPort - only with very highly compressible
    data should you see a difference.

    The main difference is in terms of features - the NextPort DSPs
    support VoIP and MICA doesn't. Modem features are almost
    identical; NextPort has the edge when tuning for slow-speed
    point-of-sale applications (you can get NextPort down to
    4 or 5 seconds trainup time, while the best MICA can do is
    around 8.)

    Aaron
     
    Aaron Leonard, Dec 10, 2003
    #14
  15. ~ >~ We were wondering, if we wanted to do compression still, would it be
    ~ >~ better for us to "downgrade" the chassis to a 7206 non VXR and add an
    ~ >~ SA-COMP/4 card to offload all MPPC/STAC compression to? Or is there
    ~ >~ another service adapter that we could offload compression to that
    ~ >~ would work in a VXR chassis?
    ~ >
    ~ >Well, I guess you could go non-VXR and put in an SA-COMP/4
    ~ >- I see that we DO assert that this is supported
    ~ >(http://www.cisco.com/warp/public/cc/pd/as/as5800/prodlit/as58_ov.htm),
    ~ >although I've never seen anyone DO this, so this would be
    ~ >a ways off the beaten path.
    ~ >
    ~ >Our plan for supporting lots of STAC/MPPC on a VXR is
    ~ >(I guess) to use the NPE-G1, but the NPE-G1 is not supported
    ~ >on the 5800 RS.
    ~ >
    ~ >Realistically, the AS5800 is designed for very large scale
    ~ >dialin PPP analog modem use. In that environment, V.42bis/V.44
    ~ >compression scales quite nicely; you don't need STAC/MPPC.
    ~
    ~ Will a VAM2 in the 5800 RS enable full STAC/MPPC support for 1000+
    ~ sessions? If so, it may be worth buying one. We are running 12.3 so it
    ~ should be supported in IOS if we update to 12.3T. The spec sheets just
    ~ say it supports STAC, but they never mention how many sessions or how
    ~ much bandwidth it can compress. Thanks for your help and suggestions.
    ~
    ~ -Robert

    (discussed with Robert offline)

    VAM/VAM2 do not support STAC or MPPC; they are designed for
    IPsec acceleration and IPPCP LZS compression (RFCs 2393, 2395).

    Aaron
     
    Aaron Leonard, Dec 10, 2003
    #15
    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.