[c-nsp] vss and mlq qos 10g-only command
Hi all Can someone explain exactly what the vss command mls qos 10g-only does. I know it changes queuing and buffer mechanism, but I'm a bit astonished by the impact. We had a problem on a datacenter where we uses a VSS144 setup. We have both vss links on the supervisior modules. The problem was between Xen provisionings servers and Xen client hosts. The Xen client OS that is streamed to the client, had retransmissions. After enabling the command all works fine. We are talking max 3Gb certain rate. Can this really overrun the vss-links ?? /Arne ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Resolve the FQDN of the URL published in web VPN in ASA
Dear All, I have the requirement to resolve the FQDN of the URL published in web VPN in ASA. When remote users connect to web vpn then they access one URL (https://fully qualified domain name:7004/console-selfservice) which is published in Web VPN and which is accessible through FQDN. So how i can resolve the FQDN against. Can we done this on ASA. or can we configure Web VPN so that when remote users connect to VPN they can get DNS server IP to resolve the FQDN ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Resolve the FQDN of the URL published in web VPN in ASA
On 11/26/11 11:24 AM, Farooq Razzaque wrote: Dear All, I have the requirement to resolve the FQDN of the URL published in web VPN in ASA. When remote users connect to web vpn then they access one URL (https://fully qualified domain name:7004/console-selfservice) which is published in Web VPN and which is accessible through FQDN. So how i can resolve the FQDN against. Can we done this on ASA. or can we configure Web VPN so that when remote users connect to VPN they can get DNS server IP to resolve the FQDN Does the FQDN point to the same IP for all users? Is the base domain a standard registered name? If yes to both, you can just publish it in your regular DNS A records and any resolver worldwide should be able to find it recursively. If it points to different IPs then what mechanism determines this? If a private domain name like [whatever].local, consider also creating a public one. There's nothing preventing you from publishing a public A record that resolves to private RFC1918 space. It won't be useful to those who aren't connected to your private network but that shouldn't matter. You can also have two variants such as host.example.net - public IP and host.vpn.example.net - private IP. Or if the ASA is assigning DHCP to the remote users it can direct them to a specific name server that has the appropriate zone file. I'm not 100% clear on exactly what the problem is that you are trying to solve. If it's more complex than this, please provide more detail. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ME3600 IOS / SPAN
Ankur, I would recommend moving to 15.1(2)EY1 which will be posted on CCO in couple of weeks. SPAN/RSPAN is not currently supported and the feature is in roadmap. -Waris -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ankur Mittal Sent: Tuesday, November 22, 2011 10:16 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ME3600 IOS / SPAN Hi there, Anyone out there tried the new IOS 15.1(2). Currently we are running 12.2(52) and wondering if we should be upgrading it 15.1(2) in production. Release notes mentioned a lot of open caveats rather than the fixed ones. Also has anyone tried port mirroring / SPAN on the ME3600. Can't really find documentation on how to do that on these switches. I am not even sure if it's supported on the ME3600. Any feedback would be appreciated. Thanks - Ankur ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ME3600 IOS / SPAN
Tassos, Can you send me the list if SRs? ME3800X should not be dropping packets with maximum queue-limit. We are working on an enhancement to increase the queue-limit range. Is there a SR for the counter issue? Can you also send me the details of the last issue matching of non default classes? I would like to do further investigation on that topic. I would recommend moving to 15.1(2)EY1 once it'll be available on CCO in couple of weeks. -Waris -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos Chatzithomaoglou Sent: Tuesday, November 22, 2011 2:06 PM To: Nick Hilliard Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ME3600 IOS / SPAN We migrated from ME-3400 to ME-3800X and we noticed that we started getting output drops on 1G interfaces, while the traffic was ~700 Mbps. I know about bursts and so on, but the same traffic wasn't causing any drops on the older platform. We tried some output shaping service policies under the interface, but the drops were still there, and then on the policy-map too. We also noticed that the rate counters on the policy-map were totally wrong. Then we applied shaping service policies under the service instances and increased the queue-limit to the max available, and the drops got very low (but still existent). Tac concluded that this is due to the default egress buffers being too small, and we're waiting for the developers to come up with a solution. Another issue we met, is that any match of non-default classes under the service policies under the service instances wasn't working at all, when there was no ingress L2 control traffic from the other side. I know it sounds very strange, but this was the conclusion we came to, after doing many different tests. To summarize, we have quite a few of strange cases with tac on this platform. -- Tassos Nick Hilliard wrote on 22/11/2011 22:29: On 22/11/2011 18:44, Tassos Chatzithomaoglou wrote: Unfortunately there are still a lot of features missing + some things that don't work well (primarily the -hardcoded- small egress buffers) Can you elaborate on this? Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ME3600 IOS / SPAN
Ankur, Replies inline [Waris] -Waris -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ankur Mittal Sent: Tuesday, November 22, 2011 3:49 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ME3600 IOS / SPAN Thanks for the information. Are you saying that we can't push more than 700 Mbps thorugh a GigE interface on the ME3600 switch when running a 15.1(2) version. [Waris] This is not correct. You should be able to run line rate traffic. We are noticing some weird problems with this platform- - Upgraded the software from 12.2(52)EY to 15.1(2)EY and when the switch rebooted, we lost Out-of-Band management to the switch. Resolution: Had to console into the switch and do a shut/no shutdown on the OOB mgmt interface. [Waris] This bug should be resolved in 15.1(2)EY1. - Also did nop cdp enable globally and lost OOB mgmt functionaily. Had to do the same thing as mentioned above to resolve the issue. I noticed that this is actually mentioned the Open caveats [Waris] This should also be resolved. Let me confirm this with engineering team. What I am mainly concerned about is the service instance / bridge domain model that was introduced in the whales version. Have you found any weird behaviour with doing simple VLAN manipulation or Q-in-Q and the QoS classification on ingress and or other catastrophic problems. [Waris] We have many customers who have deployed EVC infrastructure. Let me know if you have any specific concerns. I would appreciate if you guys can share any other findings or open caveats that are not mentioned in the cisco release notes but do exist on this software version. Thanks- Ankur ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
