Re: [c-nsp] MPLS down to the CPE
We distribute the larger aggregation nodes to various sites and then generally have access rings with access nodes hung off of those. Are the access rings in a separate area/level or running a separate igp, or how do you scale your backbone IGP please? adam -Original Message- From: Phil Bedard [mailto:phil...@gmail.com] Sent: Monday, July 08, 2013 8:23 PM To: mark.ti...@seacom.mu Cc: Adam Vitkovsky; Andrew Miehs; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] MPLS down to the CPE On 7/8/13 11:14 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Monday, July 08, 2013 12:33:36 PM Phil Bedard wrote: XR supports it in the latest revision, didn't know about the 3600 support. I guess this is the C-NSP list. We have thousands of non-Cisco nodes deployed using RSVP-TE in the access layer but it requires stitching at the service layer to scale. It has shown to be scalable at least for us. You're brave. We, at the time, opted to wait for IP LFA since RSVP-TE in the Access (even just to the adjacent PE routers) just didn't look administratively feasible, let alone scale :-). I'd be glad to hear more about your experiences. It really depends on how things are deployed and how distributed they are. We distribute the larger aggregation nodes to various sites and then generally have access rings with access nodes hung off of those. We typically do not have too many nodes on a single 1GE ring, they are balanced using passive CWDM/DWDM. Each access node has a single TE LSP to each aggregation node over which all services ride. With access rings with less than 10 nodes you have a low number of actual LSPs. The agg nodes might terminate 20-30 access rings resulting in most cases well under a thousand LSPs, which isn't really a big deal for modern equipment. The services are generally either terminated or stitched at the agg node, so it does result in quite a few unique LDP sessions, but the scale of those are in the thousands today. It's also not terribly difficult to add more agg nodes but to date we haven't had to do that. I can think of high density situations where this model probably wouldn't work out due to control plane scale issues. Unified/Seamless MPLS has been around for years and would be ideal but the end nodes have traditionally had poor BGP support. The agg nodes will do BGP-LU to LDP translation but the LFIB capacity is fairly small. Requires using something like LDP DOD to really work. The nodes support using an aggregate or default prefix for the LDP IGP route. MPLS-in-the-Access has been around for a long time, but only if you were prepared to spend a lot on big boxes in order to have good support. Some folk decided to put in the 7604's or MX240's, but those were all simply still too big. Luckily, we waited long enough until the Brocade CER/CES, the Cisco ME3600X/3800X and the Juniper MX80 started to materialize. Each of these has great all-round support (including QoS in the ME3600X/3800X, which has always been a turn-off in Cisco switches), and we went for the ME3600X. So, now at least, operators have a real shot at extending MPLS into the access for the price, without compromising features. Mark. We have been using ALU gear in that capacity for going on 4 years now, but they have only had nodes capapable of doing a 10G ring and drop for about a year now, but that was a very small part of our overall business. Cisco and Juniper didn't even make it past the early RFP stages because at the time they had no comparable equipment. I'm not going to say the gear is perfect, and has been lacking things like H-QoS until very recently, but all of their boxes have had feature sets for years that Cisco/Juniper are only now getting to. Now their boxes support things like RFC3107/LDPoRSVP/PBB even on the access nodes. Phil ___ 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] ASA 5585-X SSP-10 multi-context failover not stateful with IPv4
Do you have logs associated with the problem ? Did you see something like no valid adjacency ? Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: vinny_abe...@dell.com [mailto:vinny_abe...@dell.com] Sent: segunda-feira, 8 de Julho de 2013 20:11 To: amsoa...@netcabo.pt; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] ASA 5585-X SSP-10 multi-context failover not stateful with IPv4 No, just static routes in this environment. And I'm running a version that is already supposedly fixed, 9.1(2) as this was fixed in 9.1(1.1), But thanks. -Original Message- From: Antonio Soares [mailto:amsoa...@netcabo.pt] Sent: Monday, July 08, 2013 10:46 AM To: Abello, Vinny; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] ASA 5585-X SSP-10 multi-context failover not stateful with IPv4 Are you running OSPF ? If yes, check this bug: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fet chBugDetailsbugId=CSCuc12967 Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of vinny_abe...@dell.com Sent: segunda-feira, 8 de Julho de 2013 14:58 To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASA 5585-X SSP-10 multi-context failover not stateful with IPv4 Hi all, I have a bizarre situation that isn't making sense to me. I have two ASA 5585-X firewalls with SSP-10. They are in an Active/Standby configuration and running in multi-context mode. I have replication of state information between them working just fine. We're running both IPv4 and IPv6 and have the latest 9.1(2) code loaded. The problem is if I force a failover from the system context, any open connections over IPv4 coming in the outside interface of a context via a NAT translation seems to get lost during the failover. I'm not positive if it's the state table or the NAT table that is having an issue or if they are one in the same on the ASA. The interesting part is my IPv6 connectivity persists without any problems during the failover. I can be transferring a file via FTP or stay connected via RDP to the machines behind the firewall (Windows servers) over IPv6 and everything is seamless as it should be. If I am connected via RDP over IPv4, the connection hangs, eventually resets and reconnects. Nothing looks out of the ordinary as far as I can tell. This is the first environment I've worked on with the ASA's in multi-context mode. From the system context, this is the failover configuration: failover failover lan unit primary failover lan interface failover GigabitEthernet0/7 failover replication http failover mac address GigabitEthernet0/0 acf2.c5f2.d301 acf2.c5f2.d302 failover mac address GigabitEthernet0/1 acf2.c5f2.d311 acf2.c5f2.d312 failover mac address GigabitEthernet0/2 acf2.c5f2.d321 acf2.c5f2.d322 failover mac address GigabitEthernet0/3 acf2.c5f2.d331 acf2.c5f2.d332 failover mac address GigabitEthernet0/4 acf2.c5f2.d341 acf2.c5f2.d342 failover mac address GigabitEthernet0/5 acf2.c5f2.d351 acf2.c5f2.d352 failover mac address GigabitEthernet0/6 acf2.c5f2.d361 acf2.c5f2.d362 failover mac address TenGigabitEthernet0/8 acf2.c5f2.d393 acf2.c5f2.d394 failover link failover GigabitEthernet0/7 failover interface ip failover 172.16.255.1 255.255.255.0 standby 172.16.255.2 At first I thought it was some type of ARP issue which is why I have configured the mac addresses for primary and secondary units. I read the following in the Active/Standby guide: If you do not configure virtual MAC addresses, you might need to clear the ARP tables on connected routers to restore traffic flow. The ASA does not send gratuitous ARPs for static NAT addresses when the MAC address changes, so connected routers do not learn of the MAC address change for these addresses. That is the reason for the MAC address configuration above but it didn't seem to help. All interfaces show Normal (Monitored) both in the system context and in the context in question. Stateful update statistics show the following in the system context: Stateful Failover Logical Update Statistics Link : failover GigabitEthernet0/7 (up) Stateful Objxmit xerr rcvrerr General 45334 0 141772620242 sys cmd 31679 0 31678 0 up time 0 0 0 0 RPC services0 0 0 0 TCP conn9634 0 1012694327 UDP conn2055 0 196454 0 ARP tbl 8330 87033 0 Xlate_Timeout 0 0 0 0 IPv6 ND tbl 9160 89861 280 VPN IKEv1 SA0 0 0 0 VPN IKEv1 P20 0 0 0 VPN IKEv2 SA0
[c-nsp] Best Support of Tier 1 ISP
Hello Friends, We are going to establish a new 10GE circuit as a UP Link. So what you suggest a best Tier 1 ISP that provide high level of support ? Right now we have TATA,Cogent,Interout, Turktelecom and Level3. Thanks, ___ 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] MPLS down to the CPE
It very much appears they used IGP to propagate labels, they are just called segments. Looks like it's using the same computations as rLFA in order to build the tunnel towards the protection node. Now with this and routing-header in IPv6 do we really need LDP for IPv6 (other than the targeted LDP sessions)? I'd like to play with this adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saku Ytti Sent: Monday, July 08, 2013 5:32 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] MPLS down to the CPE On (2013-07-08 17:14 +0200), Mark Tinka wrote: We, at the time, opted to wait for IP LFA since RSVP-TE in the Access (even just to the adjacent PE routers) just didn't look administratively feasible, let alone scale :-). Even tLDP needed for rLFA is less than desirable, additional states seemingly arbitrarily signalled up and down. Segment routing[0] provides 100% coverage for LFA like functionality without any additional signalling between the devices. [0] http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-use-cases-00 #section-3 EFT program exists for IOS-XR/ASR9k at least. -- ++ytti ___ 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] Drop rule at the end of CoPP conflicts with MAC learning
Hello, exactly that was the plan. We keep CoPP a bit open until the next bigger maintenance work and then will try another IOS. regards Rolf I would try switching code versions. It sounds like you are hitting a bug. Given the fact that other boxes running different code are behaving normally, The only conclusion is that it is a software issue. Keep in mind that TAC may not have it listed as a known bug even though it was fixed. LR Mack McBride Network Architect -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rolf Hanßen Sent: Monday, July 01, 2013 6:44 AM To: Nick Hilliard Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Drop rule at the end of CoPP conflicts with MAC learning Hi, If I had a support contract for that box I would open a tac case now. ;) kind regards Rolf On 28/06/2013 17:55, Rolf Hanßen wrote: does not look like this is a general hardware version issue. mmm, ok. I would: - run a context diff on the configuration on each of these machines to ensure that there are no syntactic differences - disable and then re-enable copp on the affected box to ensure that it's reprogrammed correctly into the hardware (sometimes things get messed up on the way down to the line cards) - compare the output of show mls rate-limit on all machines - check your platform acl tcam capacity using show platform hardware capacity acl, to ensure that you still have some acl tcam space available for your copp config. If this doesn't point towards a resolution, I'd open up a tac case. Nick But I found a box with the same hardware versions: Mod Port Model Serial #Versions -- --- - 52 WS-SUP720-3B ### Hw : 5.3 Fw : 8.4(2) Sw : 12.2(33)SXJ Sw1: 20.1(1)SXJ WS-SUP720 ### Hw : 2.6 Fw : 12.2(17r)SX7 Sw : 12.2(33)SXJ WS-F6K-PFC3B ### Hw : 2.3 This box also works as soon as I enter mls rate-limit unicast cef glean 500. kind regards Rolf Any further ideas except hardware failure, buggy software or try rebooting it ? Could be a hardware issue. As someone else mentioned (Phil?), this particular feature is hardware revision dependent. What hardware versions are each of your SUP720s (show module)? 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/
[c-nsp] Cisco IOS XE
Hi/I am trying to upload the Cisco CSR 1000 ova image , have anyone found a solution for the below message? %IOSXEBOOT-4-BOOT_HALT: (rp/0): Halted boot due to missing CPU feature requirement(s) Thanks ___ 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] Static Route
I know why we use dynamic routing protocols for but it's case we faced when practicing some HSRP configuration and related that to IP SLA so I asked about it Date: Thu, 4 Jul 2013 20:05:32 +0100 From: n...@foobar.org To: gunner_...@live.com CC: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Static Route On 04/07/2013 13:03, M K wrote: I have two routers connected to each other , I have configured a loopback interface on The second router and configured a static route to reach it , now when i shutdown the loopback interface the static route is still in the routing table , how can i remove that route automatically when i lose reachability to the loopback interface ? should i use IP sla ? this is what we use dynamic routing protocols for. 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/
Re: [c-nsp] MPLS down to the CPE
On (2013-07-09 13:30 +0200), Adam Vitkovsky wrote: Now with this and routing-header in IPv6 do we really need LDP for IPv6 (other than the targeted LDP sessions)? If you do kompella eompls and you don't do mLDP, you can throw LDP out the window, labeled IPv6 will work with or without 6PE. I'd like to play with this Ping your account team. -- ++ytti ___ 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] Best Support of Tier 1 ISP
Hi, On Tue, Jul 09, 2013 at 02:09:45PM +0300, Ahmed Hilmy wrote: We are going to establish a new 10GE circuit as a UP Link. So what you suggest a best Tier 1 ISP that provide high level of support ? Right now we have TATA,Cogent,Interout, Turktelecom and Level3. We have been most happy with NTT so far. As in everything was way better than our experience with other uplinks has led us to expect. Like, no mandatory conference calls to get a circuit activated (as Global Crossing used to do), but a mail with here's your IPv4 and IPv6 address for the link, please configure at your convenience and tell us when we should turn on BGP. Or, after an external DoS hit their Frankfurt node which we're connected to, we received an unsolicited e-mail we had a DoS here, leading to some packet loss. Problem has been fixed, our apologies. We didn't even notice up to that point... experience with other carriers is more along the lines of we call them, tell them there's packet loss, and they won't find anything and close the ticket. So, yes. Happy customer. 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 pgpTzB4hXLFVW.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] Best Support of Tier 1 ISP
On 9/07/2013 10:32 PM, Gert Doering wrote: Or, after an external DoS hit their Frankfurt node which we're connected to, we received an unsolicited e-mail we had a DoS here, leading to some packet loss. Problem has been fixed, our apologies. We didn't even notice up to that point... experience with other carriers is more along the lines of we call them, tell them there's packet loss, and they won't find anything and close the ticket. So, yes. Happy customer. +1 here. Happy ex-customer (only because I changed job) after a similar couple of DDOS incidents. We also had both an international MPLS circuit as well as Internet transit based out of Sydney, Australia. NTT have a pretty decent IPv6 backbone too, FWIW. Reuben ___ 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] Best Support of Tier 1 ISP
Hi, On Tue, Jul 09, 2013 at 10:42:56PM +1000, Reuben Farrelly wrote: NTT have a pretty decent IPv6 backbone too, FWIW. Yeah, didn't mention that, but indeed - IPv6 is not something considered experimental, no support, or whatnot, but a commercial product fully supported and on par with IPv4. As it needs to be. 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 pgpIl1pcs2H06.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] privilege exec ... unexpected behaviour
Hello, Following Setup: I created a User with no privileges and want to allow some commands. I configured: privilege exec level 0 show bgp ipv6 unicast privilege exec level 0 show bgp ipv4 unicast privilege exec level 0 show ip bgp privilege exec level 0 show ip route All commands were accepted by the cli. I then access the device with the limited user. Those commands work fine: show ip route 1.2.3.4 show ip bgp 1.2.3.4 But the sh bgp ... commands fail: Routershow bgp ? all All address families ipv4 Address family ipv6 Address family l2vpn Address family nsap Address family rtfilter Address family vpnv4 Address family vpnv6 Address family Routershow bgp ipv4 ? % Unrecognized command Routershow bgp ipv4 The Config file also does not list the commands. Router#sh running-config | inc privilege exec privilege exec level 0 show bgp privilege exec level 0 show ipv6 route privilege exec level 0 show ipv6 privilege exec level 0 show ip bgp privilege exec level 0 show ip route privilege exec level 0 show ip privilege exec level 0 show Is there some additional config needed or is it some kind of restriction/limitation ? Hardware is Sup2T Software is 15.0(1)SY2 kind regards Rolf ___ 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] Best Support of Tier 1 ISP
We've been extremely happy with Internap's support. It is not uncommon to call them and have the person who answers the phone be able to give you fairly complex answers to routing and bgp questions. Every other provider we've used, and currently use, the most you get out of the initial phone call is here's your ticket number and someone will call you back soon if you're lucky. David -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ahmed Hilmy Sent: Tuesday, July 09, 2013 7:10 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Best Support of Tier 1 ISP Hello Friends, We are going to establish a new 10GE circuit as a UP Link. So what you suggest a best Tier 1 ISP that provide high level of support ? Right now we have TATA,Cogent,Interout, Turktelecom and Level3. Thanks, ___ 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] Cisco 6500 mounting with cables
Let me know where you find those Cat6 rated Amphenol cables at. That's the reason I've heard behind the demise of RJ21 connectors. No need for Cat6. 1000BASE-T only calls for Cat5, same as 100BASE-TX. Heck, it's right in the title of 802.3ab. I'm curious whether folks here have found any benefit in using Cat5e or Cat6 over Cat5 for Ethernet. Is there any? It's almost hard to find Cat5 these days - what's driving the demand? Surely people aren't buying Cat6 with TIA TSB-155 in mind, so why is the market flooded with better-but-not-meaningfully-so cable? Maybe there's a significant non-Ethernet use, like analog video transmission? ___ 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] Cisco IOS XE
The CPU on the system you are trying to run this on is not new enough. On Jul 9, 2013, at 6:53 AM, M K gunner_...@live.com wrote: Hi/I am trying to upload the Cisco CSR 1000 ova image , have anyone found a solution for the below message? %IOSXEBOOT-4-BOOT_HALT: (rp/0): Halted boot due to missing CPU feature requirement(s) Thanks ___ 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] MPLS down to the CPE
On Tuesday, July 09, 2013 10:43:20 AM Adam Vitkovsky wrote: Are the access rings in a separate area/level or running a separate igp, or how do you scale your backbone IGP please? We kept them in the IS-IS level (i.e., L2-only), as Inter- Area MPLS-TE is not supported without resorting to deploying expanded loose hops for RSVP-TE sessions (p2p and p2mp). The upside, simplicity and not running around troubleshooting potential adjacency problems caused having some routers being in the area a la L1 IS-IS. The downside, NLRI changes in the IGP happening in one end of the network would be heard by a router in another part of the network that is not generally interested in them. The weakest link was the smaller CPU's on the ME3600X, but those are not that bad to be honest. We opted to do that until the industry catches up with scaling methods that aren't as complex as BGP Label Unicast. 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] MPLS down to the CPE
On Tuesday, July 09, 2013 01:30:02 PM Adam Vitkovsky wrote: It very much appears they used IGP to propagate labels, they are just called segments. Looks like it's using the same computations as rLFA in order to build the tunnel towards the protection node. Now with this and routing-header in IPv6 do we really need LDP for IPv6 (other than the targeted LDP sessions)? I'd like to play with this Yeah, me too :-). 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] Cisco IOS XE
Or the CPU is new enough, but Virtualcenter has EVC (Enhanced vMotion Compatibility) set to something earlier than Nehalem. From: cisco-nsp [cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike Hyde [mike.hy...@gmail.com] Sent: Tuesday, July 09, 2013 8:22 AM To: M K Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco IOS XE The CPU on the system you are trying to run this on is not new enough. On Jul 9, 2013, at 6:53 AM, M K gunner_...@live.com wrote: Hi/I am trying to upload the Cisco CSR 1000 ova image , have anyone found a solution for the below message? %IOSXEBOOT-4-BOOT_HALT: (rp/0): Halted boot due to missing CPU feature requirement(s) Thanks ___ 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] MPLS down to the CPE
Just pinged my SE asking why on earth am I not in the EFT team already :) adam -Original Message- From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: Tuesday, July 09, 2013 4:12 PM To: cisco-nsp@puck.nether.net Cc: Adam Vitkovsky; 'Saku Ytti' Subject: Re: [c-nsp] MPLS down to the CPE On Tuesday, July 09, 2013 01:30:02 PM Adam Vitkovsky wrote: It very much appears they used IGP to propagate labels, they are just called segments. Looks like it's using the same computations as rLFA in order to build the tunnel towards the protection node. Now with this and routing-header in IPv6 do we really need LDP for IPv6 (other than the targeted LDP sessions)? I'd like to play with this Yeah, me too :-). Mark. ___ 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] Best Support of Tier 1 ISP
Let me know what is deficient with our IPv6 as I would like to improve. Jared Mauch On Jul 9, 2013, at 8:42 AM, Reuben Farrelly reuben-cisco-...@reub.net wrote: NTT have a pretty decent IPv6 backbone too, FWIW. ___ 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] Cisco 6500 mounting with cables
On 9 July 2013 14:35, Chris Marget ch...@marget.com wrote: It's almost hard to find Cat5 these days - what's driving the demand? Surely people aren't buying Cat6 with TIA TSB-155 in mind, so why is the market flooded with better-but-not-meaningfully-so cable? I've always put it down to FUD by cabling installation companies. I had a conversation with our building facilities people recently who'd been advised by their cabling subcontractors that they needed to rip out the obsolete cat5e from the office and run cat6a to the desktops. They even want to renew last year's cat6 in the computer room since 6a is the new standard. No technical justification, but I suspect the CEO of the cabling company fancies a new yacht. Aled ___ 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] MPLS down to the CPE
hey, We kept them in the IS-IS level (i.e., L2-only), as Inter- Area MPLS-TE is not supported without resorting to deploying expanded loose hops for RSVP-TE sessions (p2p and p2mp). FYI, starting from R11, ALU supports automatic ABR selection for inter-area RSVP LSPs. You don't need to manually specify loose hops any more. -- tarko ___ 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] Cisco IOS XE
What processor do you have. 1000v only supports Intel Nehalem based chips https://www.cisco.com/en/US/docs/routers/csr1000/release/notes/csr1000v_3Srn.html#wp3017606 On Tue, Jul 9, 2013 at 7:53 AM, M K gunner_...@live.com wrote: Hi/I am trying to upload the Cisco CSR 1000 ova image , have anyone found a solution for the below message? %IOSXEBOOT-4-BOOT_HALT: (rp/0): Halted boot due to missing CPU feature requirement(s) Thanks ___ 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] MPLS down to the CPE
On 7/9/13 10:10 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Tuesday, July 09, 2013 10:43:20 AM Adam Vitkovsky wrote: Are the access rings in a separate area/level or running a separate igp, or how do you scale your backbone IGP please? We kept them in the IS-IS level (i.e., L2-only), as Inter- Area MPLS-TE is not supported without resorting to deploying expanded loose hops for RSVP-TE sessions (p2p and p2mp). The upside, simplicity and not running around troubleshooting potential adjacency problems caused having some routers being in the area a la L1 IS-IS. The downside, NLRI changes in the IGP happening in one end of the network would be heard by a router in another part of the network that is not generally interested in them. The weakest link was the smaller CPU's on the ME3600X, but those are not that bad to be honest. We opted to do that until the industry catches up with scaling methods that aren't as complex as BGP Label Unicast. Mark. In our case we are using separate OSPF areas for the access elements, IS-IS wasn't supported when we started doing the deployments. Depending on scale sometimes an entire agg location may use the same subtending area, sometimes there are more than one, sometimes an area per access ring. The agg/core nodes of each local network sits in OSPF Area 0, and the different network islands are tied together using CsC over a common MPLS core. Right now using LDP/OSPF handoffs since there were previously some issues with doing RFC3107, but now should really should be migrated to RFC3107. If traffic levels increase enough we will build direct circuits between the islands and use IS-IS as a core IGP, leaving OSPF only in the access. I've never liked the idea of doing inter-as RSVP-TE except in unique situations, I'd rather use areas/levels and hierarchy than a stateful session across boundaries. At the ABR all of the L2VPN services are stitched since you are entering a different RSVP-TE/MPLS domain, the L3VPN configuration exists on these nodes with the access nodes using L2 pseudowires into virtual L3 interfaces. Cisco talks about a similar architecture in their Unified MPLS for Mobile presentation from the last Cisco Live. Cisco has always called these ABR/agg nodes the PWHE or pseudowire headend since they aggregate a large number of pseudowires. Long-term there are various options to eliminate the stitching and associated configuration, although we've got it pretty automated at this point. RFC3107 down to the access nodes will work but may overwhelm routing tables if you have thousands of potential endpoints. You also run into scale issues with terminating BGP sessions from access nodes to RRs or ABRs. Another option is have the ABR do RFC3107 to LDP translation (supported today) and have the access nodes setup in Downstream on Demand mode so they request labels only for the destinations they need. The vendor (A) supports longest-prefix match for LDP, including the default route, so you don't need to carry /32s in your IGP anymore. Odd Juniper wrote the RFC on that but (A) is the only vendor to implement it. Phil ___ 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/
