Re: [c-nsp] To VSS or not to VSS
Hi Eric, We use it as a core and distribution switches in our campus, have about 5 VSS pairs, and so far it runs very fine and stable, have not had any issues with it. But we have fairly easy setup, no blades (FWSM, ACE) in the box, which makes things simple. Best Regards, Pavel Skovajsa On Sat, Nov 22, 2008 at 9:13 PM, Thomas Dupas [EMAIL PROTECTED] wrote: Hi Eric, The FWSM (or any service module) wasn't supported in a VSS setup until SXI. And I don't think that many people made the step yet to SXI on a production VSS system, but you never know. Overall I have had fairly good results with VSS in terms of throughput and stability, they were mostly used as distribution switches in the campus or bookshelf switches in the DC. The biggest flaw so far is the downtime when performing an upgrade, you fall back from SSO to RPR due to the IOS mismatches, and that means around 5 minutes downtime on failover. Same as you would have with supervisor redundancy in a single chassis They now have an eFSU (semi-ISSU?) in the SXI release, which should improve upgrade procedures (RPR+ in stead of RPR), but it's not really ISSU according to the specs. But I certainly want to try that (but then I need a next release to upgrade to :-)) Best Regards, Thomas Dupas On 22/11/08 21:01, Eric Cables [EMAIL PROTECTED] wrote: I'm working on a design which includes 2 pairs of 6509s w/ VS-S720-10G (one in each chassis). The VSS capable supervisor engines were chosen mainly for the 10G interfaces, but the more VSS documentation I read the more it seems like a great solution for added redundancy/bandwidth, while reducing complexity. As far as modules, all will be 6748s or 6724s, and the only service modules in the mix will be a pair of FWSMs in one of the VSS pairs. Can anyone provide any feedback on your VSS experiences? How have the FWSMs played with VSS? Any design considerations I should be aware of? Thanks, -- Eric Cables ___ 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/ ___ 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] ldp-igp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marlon, Hi - Does anyone know how LDP and IGP forwarding on 7600 series can be separated?I have OSPF as IGP and also LDP is advertising the same routes from the neighbors. well, LDP advertises label to FEC bindings, not routes It looks like that Cisco selects only MPLS (LDP based) forwarding path. How can I tell to use IP forwarding for some routes and MPLS for other. No RSVP (MPLS-TE) is enabled. The default behaviour is to advertice label to FEC bindings for ALL iGP learnt IPv4 prefixes. So: first disable the default behaviour R1(config)#no mpls ldp advertise-labels Then set for what PREFIXes advertise the labels to what PEERs R1(config)#mpls ldp advertise-labels ? forAccess-list specifying controls on destination prefixes R1(config)#mpls ldp advertise-labels for ? WORD IP access-list for destination prefixes; name or number (1-99) R1(config)#mpls ldp advertise-labels for PREFIXes ? to Access-list specifying controls on LDP peers R1(config)#mpls ldp advertise-labels for PREFIXes to PEERs When I run show ip route, only IP routes are shown. show mpls forwarding shows only MPLS routes. Is there any way that I can pick one vs the other for forwarding? How can I tell from a 'show ' command which one is used? show ip cef PREFIX detail will tell you if there are any MPLS labels attached to the IPv4 packet, when it will be send to the PREFIX destination. BRs, - -mat - -- pgp-key 0x1C655CAB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJKS5R+BuaDRxlXKsRAnf7AJ9vFZRvWLtcyqciGycBgs9VqAiLeQCfRq9c WGeXQApGzTErB16stzca/Pg= =7LoB -END 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] VPLS Question
Dear All i have a small question about VPLS , MAC address of remote CE hosts learned from remote PE are assigned the same VC label at local PE or each mac address has VC label assigned or each CE VLAN has the same VC label ? best regards --ibrahim ___ 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] VPLS Question
Ibrahim Abo Zaid wrote on Sunday, November 23, 2008 12:43: Dear All i have a small question about VPLS , MAC address of remote CE hosts learned from remote PE are assigned the same VC label at local PE or each mac address has VC label assigned or each CE VLAN has the same VC label ? labels are allocated/advertised for pseudowires, so all remote MACs sent over the same PW will use the same VC label.. oli ___ 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] 3550 CPU Usage IPSec
Oli, Another good idea. This switch does some Q-in-Q service, and its MTU is 1530 everywhere; unfortunately it is virtually fragment free: IP statistics: Rcvd: 2218345267 total, 62765867 local destination 52 format errors, 33 checksum errors, 16655618 bad hop count 0 unknown protocol, 17690 not a gateway 0 security failures, 0 bad options, 58045 with options Opts: 329 end, 35 nop, 0 basic security, 0 loose source route 0 timestamp, 0 extended security, 3 record route 0 stream ID, 0 strict source route, 57716 alert, 0 cipso, 0 ump 0 other Frags: 40 reassembled, 46 timeouts, 0 couldn't reassemble 78 fragmented, 0 couldn't fragment Bcast: 14256448 received, 40677 sent Mcast: 7140931 received, 817787 sent Sent: 57670558 generated, 1091620153 forwarded Drop: 41037866 encapsulation failed, 0 unresolved, 0 no adjacency 3872 no route, 0 unicast RPF, 706317 forced drop 0 options denied, 0 source IP address zero Since I'm plum out of ideas, I've already scheduled a time to switch this customer over to a different 3550 to see if the problem persists or follows him. I'll definitely post back with results. Cheers, Randal On Sun, Nov 23, 2008 at 6:59 AM, Oliver Boehmer (oboehmer) [EMAIL PROTECTED] wrote: I would check for fragmentation, as suggested by someone earlier in the thread. I didn't check, but I would suspect the 3550 doing fragmentation in software (i.e. within the interrupt context). How are your MTUs on your core interface up to (and including) the 3550? Check show ip traffic, fragmentations should show up there.. oli randal k wrote on Friday, November 21, 2008 23:18: Burton, There is already ~150mbps of other traffic flowing through this switch, all of which generates approximately zero CPU, which is how it looks for 11 other active 3550s, all pushing hundreds of mbps; they're extremely good at high pps layer 3 with very little CPU usage. Yes, cef is on everywhere. The thing that draws the attention here is that it is the only 3550 in our network that has more than 1-2% CPU. Of all of the customers attached to this switch, his is the only port whose graph is an exact match for the CPU usage, and his traffic is overwhelmingly IPSec. I guess I could move him to a different 3550 distribution switch and see if the problem follows. Thanks for your continued input - Randal On Fri, Nov 21, 2008 at 11:17 AM, Burton Windle [EMAIL PROTECTED] wrote: I could be very wrong here, but I'm thought that if the usage is in the interrupt, then the CPU usage is just because of the volume of traffic, not the contents. But don't quote me on that. Easy way to test would be to push a similar volume of non-IPSec traffic and see what the CPU does. -- Burton Windle [EMAIL PROTECTED] On Fri, 21 Nov 2008, randal k wrote: Excuse my typo, my original answer of IP Input was completely wrong, since it's pretty easy to get them confused. I'm looking at it now and it's purely Interrupt traffic. dist03.cos01#show proc cpu CPU utilization for five seconds: 26%/24%; one minute: 25%; five minutes: 26% No, I'm not running anything on the 3550, it's purely a packet pusher. It is a 3550-12T, and hanging off of it is the customer's 3560g-24TS and VPN3000. All of the tunnels terminate on the Concentrator - the 3550 just does some basic layer3 forwarding and has no features. Net -- 7206edge -- 6509core --- 3550dist --- 3560customer/VPN3000customer That's why I find it a little bit odd that just forwarding IPSec packets (not originating/terminating them) is hitting the CPU. Randal ___ 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] ldp-igp
Thanks Mat. That helps a lot. But is there any way to select IP instead MPLS for forwarding witout ACLs. Say that route x.x.x.x is received by OSPF and LDP (FEC mapping). Is there any way to enable forwarding only on IP and not MPLS for that particular route without ACLs. For example, changing preference (or administrative cost) of OSPF to a lower value than LDP - something like that but on a per interface basis. Or changing preference of LDP to a higher value on a global basis. Juniper for example can change preference of LDP. Thanks again, Marlon On Sun, Nov 23, 2008 at 2:19 AM, Mateusz Błaszczyk [EMAIL PROTECTED]wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marlon, Hi - Does anyone know how LDP and IGP forwarding on 7600 series can be separated?I have OSPF as IGP and also LDP is advertising the same routes from the neighbors. well, LDP advertises label to FEC bindings, not routes It looks like that Cisco selects only MPLS (LDP based) forwarding path. How can I tell to use IP forwarding for some routes and MPLS for other. No RSVP (MPLS-TE) is enabled. The default behaviour is to advertice label to FEC bindings for ALL iGP learnt IPv4 prefixes. So: first disable the default behaviour R1(config)#no mpls ldp advertise-labels Then set for what PREFIXes advertise the labels to what PEERs R1(config)#mpls ldp advertise-labels ? forAccess-list specifying controls on destination prefixes R1(config)#mpls ldp advertise-labels for ? WORD IP access-list for destination prefixes; name or number (1-99) R1(config)#mpls ldp advertise-labels for PREFIXes ? to Access-list specifying controls on LDP peers R1(config)#mpls ldp advertise-labels for PREFIXes to PEERs When I run show ip route, only IP routes are shown. show mpls forwarding shows only MPLS routes. Is there any way that I can pick one vs the other for forwarding? How can I tell from a 'show ' command which one is used? show ip cef PREFIX detail will tell you if there are any MPLS labels attached to the IPv4 packet, when it will be send to the PREFIX destination. BRs, - -mat - -- pgp-key 0x1C655CAB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJKS5R+BuaDRxlXKsRAnf7AJ9vFZRvWLtcyqciGycBgs9VqAiLeQCfRq9c WGeXQApGzTErB16stzca/Pg= =7LoB -END 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] ldp-igp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marlon, you have an option of 1) static labels 2) bgp advertised labels (neighbor X send-label) 3) TE (rsvp) advertised labels. or 4) LDP/TDP I don't know what Juniper can do for you. BRs, - -mat 2008/11/23 Marlon Duksa : Thanks Mat. That helps a lot. But is there any way to select IP instead MPLS for forwarding witout ACLs. Say that route x.x.x.x is received by OSPF and LDP (FEC mapping). Is there any way to enable forwarding only on IP and not MPLS for that particular route without ACLs. For example, changing preference (or administrative cost) of OSPF to a lower value than LDP - something like that but on a per interface basis. Or changing preference of LDP to a higher value on a global basis. Juniper for example can change preference of LDP. Thanks again, Marlon - -- pgp-key 0x1C655CAB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJKbfk+BuaDRxlXKsRAvOaAJ0bJwvt57kI4Cq+cFJUl7fZuLs4SwCeJfXb LNUrUxTjZ1tEGfSC6/PN6w0= =t14w -END 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] HSRP and routing asymmetry
On 21/11/2008, at 9:11 PM, Phil Mayers wrote: You can achieve this to a limited degree, but I'd think very carefully - is the minimal gain worth the hassle? We run a similar topology, and we just ignore it - let the traffic return via either path. Have to agree with Phil here - just ignore it. We run a dual 6500 agg layer as our standard DC deployment and having asymmetric traffic isn't an issue. David ... ___ 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] ldp-igp
On Monday 24 November 2008 03:41:07 Marlon Duksa wrote: Thanks Mat. That helps a lot. But is there any way to select IP instead MPLS for forwarding witout ACLs. Say that route x.x.x.x is received by OSPF and LDP (FEC mapping). Is there any way to enable forwarding only on IP and not MPLS for that particular route without ACLs. For example, changing preference (or administrative cost) of OSPF to a lower value than LDP - something like that but on a per interface basis. Or changing preference of LDP to a higher value on a global basis. Juniper for example can change preference of LDP. From your initial e-mail I could tell you were trying to do, in IOS, what JunOS does, i.e., treat LDP and RSVP as route sources and install forwarding entries into the routing table with preferences (administrative distance in IOS), e.g.,: [edit] [EMAIL PROTECTED] run show route table mpls mpls.0: 70 destinations, 70 routes (70 active, 0 holddown, 0 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 0 *[MPLS/0] 2d 07:17:30, metric 1 Receive 1 *[MPLS/0] 2d 07:17:30, metric 1 Receive 2 *[MPLS/0] 2d 07:17:30, metric 1 Receive 299776 *[LDP/9] 09:32:41, metric 1 to x.x.x.193 via ge-0/0/0.0, Pop to x.x.x.193 via ge-0/1/0.0, Pop 299776(S=0)*[LDP/9] 09:32:41, metric 1 to x.x.x.193 via ge-0/0/0.0, Pop to x.x.x.193 via ge-0/1/0.0, Pop 299792 *[LDP/9] 09:32:41, metric 1 to x.x.x.193 via ge-0/0/0.0, Pop to x.x.x.194 via ge-0/0/0.0, Pop to x.x.x.193 via ge-0/1/0.0, Pop to x.x.x.194 via ge-0/1/0.0, Pop 299792(S=0)*[LDP/9] 09:32:41, metric 1 to x.x.x.193 via ge-0/0/0.0, Pop to x.x.x.194 via ge-0/0/0.0, Pop to x.x.x.193 via ge-0/1/0.0, Pop to x.x.x.194 via ge-0/1/0.0, Pop I haven't had to treat them as routing protocols in JunOS, and just use them for what they are intended - life is simpler. Aside from what others have already mentioned in this thread, I'm not sure IOS treats these label distribution protocols as routing protocols. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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] ldp-igp
Mark Tinka wrote on Monday, November 24, 2008 03:05: On Monday 24 November 2008 03:41:07 Marlon Duksa wrote: Thanks Mat. That helps a lot. But is there any way to select IP instead MPLS for forwarding witout ACLs. Say that route x.x.x.x is received by OSPF and LDP (FEC mapping). Is there any way to enable forwarding only on IP and not MPLS for that particular route without ACLs. For example, changing preference (or administrative cost) of OSPF to a lower value than LDP - something like that but on a per interface basis. Or changing preference of LDP to a higher value on a global basis. Juniper for example can change preference of LDP. From your initial e-mail I could tell you were trying to do, in IOS, what JunOS does, i.e., treat LDP and RSVP as route sources and install forwarding entries into the routing table with preferences (administrative distance in IOS), e.g.,: [...] Aside from what others have already mentioned in this thread, I'm not sure IOS treats these label distribution protocols as routing protocols. No, it doesn't. To put is simple: if IOS installs a RIB entry and it finds a FEC binding in its LIB for the respective next-hop/oif, it uses it. If you don't want this to happen (for whatever reason), you can either filter the outgoing LDP advertisement downstream, or filter the LDP advertisement on the node itself (Inbound label filtering, mpls ldp neighbor x.x.x.x labels accept acl). Marlon: What are you trying to achieve? If you don't want to add a label to packets over a given interface, why did you enable LDP on it in the first place? oli ___ 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/
