Re: [c-nsp] Unknown unicast only occuring when a host is under attack...
Assuming the DoS attack is routed traffic (since it's in netflow) it won't cause overflows in L2 forwarding table CAM. Unless there's a layer2 device downstream from the router. Not even then. Layer 2 source/dest addresses are rewritten on every router hop. All traffic going through a router will have that router's MAC address as L2 source. So even if you have 400,000 packets coming through a router, each packet may have a different source IP but all will have the same source MAC. No matter how many Layer 2 devices are downstream: they won't alter the packets, won't look at the Layer 3 source/dest and will only look at the L2 source/dest (which are, in this case, router MAC as source and host under attack MAC as destination). Have a look with a packet sniffer (eg Wireshark) if you don't believe me :) Regards, Jeroen van Ingen ___ 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] Unknown unicast only occuring when a host is under attack...
On Mar 25, 2011, at 2:11 AM, Drew Weaver wrote: Basically what is happening is a host in a VLAN is getting flooded with http requests and when this happens the http requests are being unicast to all ports in this VLAN. How was this diagnosed? Are you sure that the /32 of the individual host is all that's being attacked, or are the attackers perhaps going after more than one host on the same VLAN/subnet? Are directed broadcasts disabled? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde ___ 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] 6500/BGP/full route tables [even more] confusing...
This topic seems to come up periodically... and I thought I had it figured out... but apparently not. So I'm seeking some real-world answers and opinions on my particular combination/options. I had a 6509/Sup2 (clearly can't do full tables) for some time, using various route-maps and filtering tricks to keep the IPv4 routes under 128K (which seems to be the magic number with uRPF enabled). If that is exceeded, it generates TCAM overflow errors and essentially the 6500 is bricked relative to passing traffic. Under 128K and it's fine. I intended to upgrade this to something suitable for full routing tables, and went for a Sup720/PFC3CXL. A million routes, right? Initial replacement resulted in the WS-X6516-GBIC / DFC blade being refused and powered down. OK, incompatibilty issue, but you can RMA a suitable replacement. Received another WS-X6516-GBIC but with a DFC3A. Powers up, but switches everything to PFC3A mode: Router#show platform hardware capacity system System Resources PFC operating mode: PFC3A Supervisor redundancy mode: administratively sso, operationally sso Switching resources: Module Part number Series CEF mode 3WS-X6516-GBIC CEF256 dCEF 5VS-S720-10G supervisor CEF which means 192K unicast routes: *L3 Forwarding Resources FIB TCAM usage: Total Used %Used 72 bits (IPv4, MPLS, EoM) 196608 25 1% 144 bits (IP mcast, IPv6) 32768 7 1%* TAC says If the routes are more than 192K, part of the unicast routes will NOT be in the hardware and the traffic using those routes will be punted to RP (Route Processor). This will result in high CPU. OK, how much traffic would it take to choke a VS-S720-10G with RP switching? I'm not looking at pushing terabits here... Official TAC recommendation is to get a DFC3CXL for the blade (do I really want a $15K upgrade for an old 6516-GB blade?), or get a CFC blade (I do have a WS-X6724-SFP / WS-F6700-CFC blade I could reluctantly pull out of a core switch with some rearrangement), or get another 6724/CFC combination (interestingly enough, also $15K list). Or I'm tempted to hang a 3750E off the Sup's 10G port and use it for gig and to heck with the blade :) Can't seem to get a straight answer relative to the RP switching penalty here (an old Sup2 is handling the current traffic). Thanks, Jeff ___ 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] 6500/BGP/full route tables [even more] confusing...
On Sat, 26 Mar 2011, Jeff Kell wrote: I had a 6509/Sup2 (clearly can't do full tables) for some time, using various route-maps and filtering tricks to keep the IPv4 routes under 128K (which seems to be the magic number with uRPF enabled). If that is exceeded, it generates TCAM overflow errors and essentially the 6500 is bricked relative to passing traffic. Under 128K and it's fine. I intended to upgrade this to something suitable for full routing tables, and went for a Sup720/PFC3CXL. A million routes, right? Not really. The million routes thing is highly misleading. Received another WS-X6516-GBIC but with a DFC3A. Powers up, but switches everything to PFC3A mode: If you're not doing that much traffic, is removing the DFC from the WS-X6516-GBIC an option? -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] 6500/BGP/full route tables [even more] confusing...
On 3/26/2011 2:32 PM, Jon Lewis wrote: On Sat, 26 Mar 2011, Jeff Kell wrote: I intended to upgrade this to something suitable for full routing tables, and went for a Sup720/PFC3CXL. A million routes, right? Not really. The million routes thing is highly misleading. It at least depends on a whole lot of things. I'll settle for half. Just not 192K. Received another WS-X6516-GBIC but with a DFC3A. Powers up, but switches everything to PFC3A mode [192K routes]: If you're not doing that much traffic, is removing the DFC from the WS-X6516-GBIC an option? I don't know, that's why I'm asking, but if that's a viable option, will certainly give it a try. Jeff ___ 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] 6500/BGP/full route tables [even more] confusing...
As far as I'm aware there is no DFC in 6516, it's a legacy card with a single 8Gb (duplex) connection to the fabric. Your output actually confirms that, saying CEF256. Are there any other modules in the chassis? On Sat, Mar 26, 2011 at 8:05 PM, Jeff Kell jeff-k...@utc.edu wrote: On 3/26/2011 2:32 PM, Jon Lewis wrote: On Sat, 26 Mar 2011, Jeff Kell wrote: I intended to upgrade this to something suitable for full routing tables, and went for a Sup720/PFC3CXL. A million routes, right? Not really. The million routes thing is highly misleading. It at least depends on a whole lot of things. I'll settle for half. Just not 192K. Received another WS-X6516-GBIC but with a DFC3A. Powers up, but switches everything to PFC3A mode [192K routes]: If you're not doing that much traffic, is removing the DFC from the WS-X6516-GBIC an option? I don't know, that's why I'm asking, but if that's a viable option, will certainly give it a try. Jeff ___ 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] 6500/BGP/full route tables [even more] confusing...
Hi, On Sat, Mar 26, 2011 at 03:05:13PM -0400, Jeff Kell wrote: If you're not doing that much traffic, is removing the DFC from the WS-X6516-GBIC an option? I don't know, that's why I'm asking, but if that's a viable option, will certainly give it a try. Well, it will fall back to central lookup on the Sup720, which is (if I remember right) only a problem if the shared bus is full or your traffic levels are really high (more than 15Mpps) - but if you only have 67xx and 65xx cards in the system, the shared bus is only used for lookups and has plenty of capacity for that. (Saku Ytti will correct me if I'm wrong...) What I'm not sure right now is whether the 6516 needs a CFC as replacement for the DFC, or whether it's sufficient to remove the DFC. I think I've only ever seen CFC mentioned when 67xx cards are involved, but you might want to check cisco.com to be sure :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpDufakQ6Ovd.pgp Description: PGP signature ___ 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] 6500/BGP/full route tables [even more] confusing...
Hi Jeff, Removing the DFC from a 65xx card letting the PFC do the work is HIGHLY preferable to letting traffic punt for your shortest mask prefixes, which are the ones that won't get into the h/w if you blow out the FIB TCAM. In order of preference: * get an XL DFC, list price on a DFC3CXL is like $15000 * remove the DFC from the card. You can do this easily on a 65xx card (note that with 67xx cards you'd need a CFC around to replace it with). 65xx without DFC will use the bus to get central lookups by the PFC, will use the fabric for sending data traffic to the egress module. * just blow out the TCAM randomly and punt to the CPU. This is not just least preferred, it's bordering on downright insane. 2 cents, Tim At 12:05 PM 3/26/2011, Jeff Kell quipped: On 3/26/2011 2:32 PM, Jon Lewis wrote: On Sat, 26 Mar 2011, Jeff Kell wrote: I intended to upgrade this to something suitable for full routing tables, and went for a Sup720/PFC3CXL. A million routes, right? Not really. The million routes thing is highly misleading. It at least depends on a whole lot of things. I'll settle for half. Just not 192K. Received another WS-X6516-GBIC but with a DFC3A. Powers up, but switches everything to PFC3A mode [192K routes]: If you're not doing that much traffic, is removing the DFC from the WS-X6516-GBIC an option? I don't know, that's why I'm asking, but if that's a viable option, will certainly give it a try. Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ 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] 6500/BGP/full route tables [even more] confusing...
disregard =) On Sat, Mar 26, 2011 at 8:22 PM, Andriy Bilous andriy.bil...@gmail.com wrote: As far as I'm aware there is no DFC in 6516, it's a legacy card with a single 8Gb (duplex) connection to the fabric. Your output actually confirms that, saying CEF256. Are there any other modules in the chassis? On Sat, Mar 26, 2011 at 8:05 PM, Jeff Kell jeff-k...@utc.edu wrote: On 3/26/2011 2:32 PM, Jon Lewis wrote: On Sat, 26 Mar 2011, Jeff Kell wrote: I intended to upgrade this to something suitable for full routing tables, and went for a Sup720/PFC3CXL. A million routes, right? Not really. The million routes thing is highly misleading. It at least depends on a whole lot of things. I'll settle for half. Just not 192K. Received another WS-X6516-GBIC but with a DFC3A. Powers up, but switches everything to PFC3A mode [192K routes]: If you're not doing that much traffic, is removing the DFC from the WS-X6516-GBIC an option? I don't know, that's why I'm asking, but if that's a viable option, will certainly give it a try. Jeff ___ 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] 6500/BGP/full route tables [even more] confusing...
My bad. Somehow I've got the impression only 67xx using DFC. On Sat, Mar 26, 2011 at 8:32 PM, Tim Stevenson tstev...@cisco.com wrote: DFC is optional on CEF256 cards. CEF256 is just a family name. The dCEF under CEF mode indicates whether it's doing central or distributed (d = distributed, ie, DFC). sh module will clearly tell you whether a DFC is present or not, under the Sub-Module heading. Tim At 12:22 PM 3/26/2011, Andriy Bilous quipped: As far as I'm aware there is no DFC in 6516, it's a legacy card with a single 8Gb (duplex) connection to the fabric. Your output actually confirms that, saying CEF256. Are there any other modules in the chassis? On Sat, Mar 26, 2011 at 8:05 PM, Jeff Kell jeff-k...@utc.edu wrote: On 3/26/2011 2:32 PM, Jon Lewis wrote: On Sat, 26 Mar 2011, Jeff Kell wrote: I intended to upgrade this to something suitable for full routing tables, and went for a Sup720/PFC3CXL. A million routes, right? Not really. The million routes thing is highly misleading. It at least depends on a whole lot of things. I'll settle for half. Just not 192K. Received another WS-X6516-GBIC but with a DFC3A. Powers up, but switches everything to PFC3A mode [192K routes]: If you're not doing that much traffic, is removing the DFC from the WS-X6516-GBIC an option? I don't know, that's why I'm asking, but if that's a viable option, will certainly give it a try. Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ 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] 6500/BGP/full route tables [even more] confusing...
DFC is optional on CEF256 cards. CEF256 is just a family name. The dCEF under CEF mode indicates whether it's doing central or distributed (d = distributed, ie, DFC). sh module will clearly tell you whether a DFC is present or not, under the Sub-Module heading. Tim At 12:22 PM 3/26/2011, Andriy Bilous quipped: As far as I'm aware there is no DFC in 6516, it's a legacy card with a single 8Gb (duplex) connection to the fabric. Your output actually confirms that, saying CEF256. Are there any other modules in the chassis? On Sat, Mar 26, 2011 at 8:05 PM, Jeff Kell jeff-k...@utc.edu wrote: On 3/26/2011 2:32 PM, Jon Lewis wrote: On Sat, 26 Mar 2011, Jeff Kell wrote: I intended to upgrade this to something suitable for full routing tables, and went for a Sup720/PFC3CXL. A million routes, right? Not really. The million routes thing is highly misleading. It at least depends on a whole lot of things. I'll settle for half. Just not 192K. Received another WS-X6516-GBIC but with a DFC3A. Powers up, but switches everything to PFC3A mode [192K routes]: If you're not doing that much traffic, is removing the DFC from the WS-X6516-GBIC an option? I don't know, that's why I'm asking, but if that's a viable option, will certainly give it a try. Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ 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] Unknown unicast only occuring when a host is under attack...
On 3/26/2011 9:08 AM, Jeroen van Ingen wrote: Assuming the DoS attack is routed traffic (since it's in netflow) it won't cause overflows in L2 forwarding table CAM. Unless there's a layer2 device downstream from the router. Not even then. Layer 2 source/dest addresses are rewritten on every router hop. All traffic going through a router will have that router's MAC address as L2 source. So even if you have 400,000 packets coming through a router, each packet may have a different source IP but all will have the same source MAC. No matter how many Layer 2 devices are downstream: they won't alter the packets, won't look at the Layer 3 source/dest and will only look at the L2 source/dest (which are, in this case, router MAC as source and host under attack MAC as destination). Have a look with a packet sniffer (eg Wireshark) if you don't believe me :) Regards, Jeroen van Ingen ___ 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/ If the Host under attack doesn't have a gateway and is dependent on proxy ARP then it would be possible for the CAM to overflow. ___ 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] Unknown unicast only occuring when a host is under attack...
Hi, On Sat, Mar 26, 2011 at 03:51:02PM -0400, ML wrote: If the Host under attack doesn't have a gateway and is dependent on proxy ARP then it would be possible for the CAM to overflow. That would be such a serious misconfiguration that all ensuring pain is well-deserved. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp2vbv0FVLge.pgp Description: PGP signature ___ 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] Is this QoS config possible in 7600 with WS-X6724-SFP?
We usually use this QoS config to give voice traffic priority: class-map match-all VOICE match ip dscp ef policy-map BRANCH-WAN-EDGE_child class VOICE priority percent 10 class class-default fair-queue random-detect dscp-based policy-map BRANCH-WAN-EDGE_parent class class-default shape average 1 service-policy BRANCH-WAN-EDGE_child interface GigabitEthernet0/1.402 service-policy output BRANCH-WAN-EDGE_parent But now we have to do this in a 7609 with WS-X6724-SFP cards. The setup is that the WAN lines come in on a 3750 switch, and the 3750 switch is connected to the 7609 on two gigabit ports in different WS-X6724-SFP cards, combined by a port-channel. In the 7609 the WAN VLAN is terminated like this: interface Vlan402 bandwidth 10 ip address xxx All physical ports in the 7609 trust dscp: mls qos trust dscp Other than that we only have this QoS config in the 7609: mls qos mls qos map cos-dscp 0 8 16 24 32 46 48 56 I tried our usual config and some other variants, but the 7609 won't accept shaping or priority or hierarchical QoS. Probably because it doesn't have real WAN cards since the WAN lines are connected to the 3750. Is there any way to do what we want in the 7609? The only requirement right now is to give priority to traffic marked with dscp ef. We would prefer to configure this priority per VLAN if possible, but will do it on the physical interfaces (or maybe on the port-channel?) if that's the only way. A possible complication is that the WAN lines have different bandwidth. Usually 50 Mbps, but some are 100 Mbps. This is why priority configuration per VLAN is preferred. Thanks! -- Peter Olssonp...@leissner.se ___ 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] Unknown unicast only occuring when a host is under attack...
Hi, On Sat, Mar 26, 2011 at 03:51:02PM -0400, ML wrote: If the Host under attack doesn't have a gateway and is dependent on proxy ARP then it would be possible for the CAM to overflow. That would be such a serious misconfiguration that all ensuring pain is well-deserved. Agreeing with Gert on the fact that all pain resulting from proxy-arp is well deserved... only use it if you really know what you're doing (and if you know what you're doing, generally you don't want to use proxy-arp). With regard to proxy-arp and CAM table overflow: sorry, but I don't see that happening, not if we're still talking about CAM in the sense of layer 2 forwarding tables. With proxy-arp enabled, a router will reply to any ARP request for addresses in networks that are reachable from the router (possibly including default route). However, the router will reply with its own MAC address; both as L2 source which is relevant for any intermediate switches, and with its MAC in the ARP payload which is relevant to the host that did the ARP request. No matter how many times the router acts as a proxy (by replying to ARP requests for host addresses on other networks), the router will only use one distinct source MAC for all packets it sends into the VLAN. And only the source MAC in a layer 2 frame is considered when building L2 forwarding tables. Regards, Jeroen van Ingen ___ 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] Is this QoS config possible in 7600 with WS-X6724-SFP?
No. You need to research lan qos. That card is a LAN card. On Mar 26, 2011 6:56 PM, Peter Olsson p...@leissner.se wrote: We usually use this QoS config to give voice traffic priority: class-map match-all VOICE match ip dscp ef policy-map BRANCH-WAN-EDGE_child class VOICE priority percent 10 class class-default fair-queue random-detect dscp-based policy-map BRANCH-WAN-EDGE_parent class class-default shape average 1 service-policy BRANCH-WAN-EDGE_child interface GigabitEthernet0/1.402 service-policy output BRANCH-WAN-EDGE_parent But now we have to do this in a 7609 with WS-X6724-SFP cards. The setup is that the WAN lines come in on a 3750 switch, and the 3750 switch is connected to the 7609 on two gigabit ports in different WS-X6724-SFP cards, combined by a port-channel. In the 7609 the WAN VLAN is terminated like this: interface Vlan402 bandwidth 10 ip address xxx All physical ports in the 7609 trust dscp: mls qos trust dscp Other than that we only have this QoS config in the 7609: mls qos mls qos map cos-dscp 0 8 16 24 32 46 48 56 I tried our usual config and some other variants, but the 7609 won't accept shaping or priority or hierarchical QoS. Probably because it doesn't have real WAN cards since the WAN lines are connected to the 3750. Is there any way to do what we want in the 7609? The only requirement right now is to give priority to traffic marked with dscp ef. We would prefer to configure this priority per VLAN if possible, but will do it on the physical interfaces (or maybe on the port-channel?) if that's the only way. A possible complication is that the WAN lines have different bandwidth. Usually 50 Mbps, but some are 100 Mbps. This is why priority configuration per VLAN is preferred. Thanks! -- Peter Olsson p...@leissner.se ___ 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/
