[c-nsp] NATing guest VRF and default VRF on edge router
Folks, Long time no see! I'm back on c-nsp after a long hiatus with a question. I'm having trouble getting NAT to work in IOS on some CEs (2821 and 3925 running 15). The site has a VRF for guest traffic and uses the default VRF for corporate traffic. Previously they had a 3rd-party firewall between the PE and CE that did NAT for corp traffic on the Inside and NAT for guest on a DMZ interface. Basic setup. The 3rd-party firewall is gone now and we're trying to do all NAT and firewall functionality in the site router that also connects them to their MPLS WAN. The guest VRF only needs Internet access; there isn't a need to allow access between the VRFs other than to the Internet. Basic guest setup. I've gone through a number of config iterations here and can't get everything to work at the same time. I'm leaking a default route into the guest VRF pointed at the PE-facing CE interface with the next-hop being the PE. I have a NAT pool for guest, an ACL that matches all guest traffic, and then I use both the pool and ACL in a NAT overload statement for the PE-facing interface. That works fine. ip vrf guest-vrf rd 100:100 ! interface GigabitEthernet0/0 description TO PE ip address aa.bb.cc.230 255.255.255.252 ip nat outside ip virtual-reassembly in load-interval 30 duplex full speed 100 ! interface GigabitEthernet0/1.910 description Wired Guest encapsulation dot1Q 910 ip vrf forwarding guest-vrf ip address 10.5.1.129 255.255.255.128 ip nat inside ip virtual-reassembly in ! interface GigabitEthernet0/1.911 description Wireless Guest encapsulation dot1Q 911 ip vrf forwarding guest-vrf ip address 10.5.2.1 255.255.254.0 ip nat inside ip virtual-reassembly in ! ip nat pool guest-nat-pool aa.bb.cc.230 aa.bb.cc.230 prefix-length 30 ip nat inside source list nonat0_guest-vrf pool guest-nat-pool vrf guest-vrf overload ! ip route vrf guest-vrf 0.0.0.0 0.0.0.0 GigabitEthernet0/0 aa.bb.cc.229 ! ip access-list extended nonat0_guest-vrf permit ip 10.5.0.0 0.0.255.255 any ! That works fine. I've expanded upon that with a 2nd NAT pool for corp traffic (using the same IP), another ACL that matches the local corp subnets to ANY (since I'm NATing all traffic that traverses that interface, vs a NoNAT) and then another overload NAT statement for the same interface. I added the nat inside lines to the corp L3 interfaces and made sure the default route in the default VRF pointed to the PE. Guest still worked but only ICMPs on corp traffic worked. Any suggestions? This should be a relatively simple setup and for some reason I can't get it to work. Ie, NAT the default VRF and guest VRF to allow Internet access from both with the Internet edge being in the default VRF. I hate to rejoin the mailing list with a question on my mind but that's where I'm at today. Any tips would be much appreciated. Thanks Justin ___ 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] VTP war stories (was Re: EoMPLS or VPLS loop prevention/storm control)
On 2/10/2011 4:06 AM, Gert Doering wrote: Well, the point is that there are not enough saveguards in VTP v1 and v2 to require some more active wrongdoing to make it explode - and if it explodes, it usually requires walking to the some of the affected devices to get it fixed. Things like plugging in a switch that was used for lab purposes and after that nicely cleaned of all the VLANs configured on it, because it was only for labbing should never bring down a complete production network - and things like that just don't happen with the other protocols you mentioned. I couldn't agree more. Sure, if used in an exacting perfect way, VTP can be configured and used without incident. Make one simple little mistake and it will hand you your ass. I'd rather not have a hair trigger sitting on my network. Configuring VLANs on a dozen switches really is a trivial thing to do if you're organized about your VLAN numbering (basically not replicating VLAN IDs on disparate switches) and are organized about your up/down links. At that point copying and pasting in the basic VLAN config is a no brainer. conf t vlan 1234 name vlan1234.Math-Dept-Pub-Lab ! interface range gi0/1 - 2 ! Uplinks switchport trunk allowed vlan add 1234 interface range gi0/3 - 4 ! Downlinks switchport trunk allowed vlan add 1234 end wr How difficult is this really? And the bulk of that config is if you manually define an Allowed VLAN list on your trunks, something a lot of lazy admins don't do anyway. To me it doesn't matter if you have 1 switch or a dozen in a simple tree or ring topology. So on one hand you have something that should work but fails in a spectacular fashion to most all network engineers at some point in their career (and could be easily broken as part of a DoS without much of any effort), or you have the piece of mind created as part of a very simple process that should take a decent engineer very little time. Call me crazy but I'm going with the KISS theory on this one! Justin ___ 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] Hiding MPLS L3VPN hops from the CE
On 8/22/2010 6:31 AM, Peter Hicks wrote: Just out of interest - is this for marketing reasons, or technical? At my ISP it was for security reasons. Our infrastructure was privately addressed to limit exposure to the outside world. In theory, a true MPLS P core is analogous to a pure L2 switching core. There's no reason for anyone to ever know that those hops even exist. In addition, it also helps prevent a confused user from thinking something silly when they see a RFC1918 address in their traceroute. Oh the stories I could tell like the time a guy thought IANA had hijacked our network because their IPs appeared in the middle of our network. Classic... ___ 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] 3rd-party unofficial SFP support in 3560X/3750X switches
Does anyone happen to know if the 'service unsupported-transceiver' command still works in the new 3560X/3750X series switches? I have a need for super long-range single strand SFPs and would rather use switches over media converters if I can help it. Thanks Justin ___ 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] Self rebooting pix?
Jason Gurtz wrote: After each drop this counter returns to 0 which tells me the Pix is rebooting for some reason. [...] experienced this. The software rev is 6.3. We experienced this on a 515E running 6.3 code. A move to the 7.0 series solved this issue. Same thing here. It would crash about once a month on us but the duration was show short that it was seldom ever noticed. It only took 45 seconds to boot. We solved it by installing ASAs. :-) Justin ___ 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 (Sup7203-bxl / 6724-SFP) Input queue drops
joshua sahala wrote: drew, it may or may not be related, but...check the output of 'sh counter int int [delta]' and look at the qos[1-21][In|Out]lost counters. i was experiencing various drops due to the default interface (qos) buffer allocation: basically, all of my traffic was hitting the 76xx swouter in the q0 buffer and overrunning it (there were no drops in any of the other qos queues because no traffic was ever hitting them). i ended up having to rewrite the buffer mapping to allocate everything to q0 and the random discards stopped (at least the ones caused by this issue). I want to revive an old thread if I can. I'm facing a similar issue now. Gi1/1 on my 6724s in my core 7600s (3BXL) connect to one of my border routers, a 7206 G1. Both interfaces on both 6724s show large volumes of input drops and flushes. Gi1/2 on the same 6724s connect to a 3845 which is my other border and it shows significantly lower drops and flushes (4 digits instead of 7 or 8). All 4 links are SX. 'sh counters' didn't yield anything terribly interesting either. 7613-1.clr#sh counters interface gi1/1 delta | e = 0 Time since last clear - never 64 bit counters: 0. rxHCTotalPkts = 123760873738 1. txHCTotalPkts = 45947101814 2.rxHCUnicastPkts = 123747989684 3.txHCUnicastPkts = 45941233718 4. rxHCMulticastPkts = 12883997 5. txHCMulticastPkts = 5868073 6. rxHCBroadcastPkts = 57 7. txHCBroadcastPkts = 23 8. rxHCOctets = 101377579108374 9. txHCOctets = 16976124978053 10. rxTxHCPkts64Octets = 8893600878 11.rxTxHCPkts65to127Octets = 57698604883 12. rxTxHCPkts128to255Octets = 20633513794 13. rxTxHCPkts256to511Octets = 7123204457 14. rxTxHCpkts512to1023Octets = 6652027912 15. rxTxHCpkts1024to1518Octets = 26440990980 32 bit counters: 2.rxOversizedPkts = 2492150694 13. linkChange = 2 All Port Counters 1. InPackets = 123760839646 2. InOctets = 101377556782449 3.InUcastPkts = 123747955595 4.InMcastPkts = 12883994 5.InBcastPkts = 57 6. OutPackets = 45947087810 7. OutOctets = 16976121260975 8. OutUcastPkts = 45941219715 9. OutMcastPkts = 5868072 10. OutBcastPkts = 23 22. Giants = 2492143293 35. rxTxHCPkts64Octets = 8893600875 36.rxTxHCPkts65to127Octets = 57698582793 37. rxTxHCPkts128to255Octets = 20633505929 38. rxTxHCPkts256to511Octets = 7123201908 39. rxTxHCpkts512to1023Octets = 6652026348 40. rxTxHCpkts1024to1518Octets = 26440984821 44. OversizedPkts = 2492143293 The giants are explained by the MTU I have on those links. I run 9000 on all infrastructure links. Other than that I don't see anything else wrong. All the QoS Lost lines were 0. All infrastructure interfaces are also MPLS enabled. The 7206 carries the bulk of the Internet traffic as does 7600 #1 so it's not a big surprise to see its links affected much more so than the 3845 links. I'm graphing interface errors/discards with Cacti. I have to question the numbers it's giving me though. They have never seemed to be accurate to me on any of my interfaces. Are my queues not deep enough to carry the traffic flow? Peak Mbps on through the 7206 is about 120Mbps and if Cacti is right then we're also only talking about 17,000 pps on the upstream-facing interface of the 7206, most of which would come from 7600 #1. Thoughts? Thanks Justin ___ 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] Data Center cooling
scott owens wrote: Hello, Has anyone looked at using outside air to provide data center cooling during the winter season ? I am aware of Google and Intel research into this area but how about on a smaller scale ? How about raising ambient temperatures as well - do you keep your data centers at 65 or 80 ? The topic came up on NANOG several times in the past. I seem to recall someone saying that they used outside air as well since they were in very high latitudes. You might try searching those list archives. Justin ___ 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-IS Ethertype
Hey guys. I hope you all had a good holiday break. Does anyone know for sure what the Ethertype is for the CLNS packets? I've found a couple IEFT drafts that talk about it it to a degree: http://tools.ietf.org/html/draft-ietf-isis-ext-eth-01 http://tools.ietf.org/html/draft-ietf-isis-ext-eth-01 They imply that for packet sizes under 1500 that CLNS uses the standard IEEE 802.3 ethertypes. The drafts specifically address packets over 1500 bytes though. One suggests 0x8872 and the other suggests 0x8870. I can't find anything definitive though. I'm trying to think what all could affect the Ethertype for IS-IS. MPLS won't. LAGs might (I can't find anything about Ethertype for PAgP or LACP either). Nothing else comes to mind though. Can anyone tell me for sure what the Ethertype is on IS-IS packets? Thanks Justin ___ 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 logging commands
Henry-Nicolas Tourneur wrote: I'm not willing to use Tacacs+ because I'm setting-up a new server environment and I don't want to need to manually compile tac-plus and get broken dependencies after an upgrade. I've been using OSS tacacs+ daemons for nearly a decade and have yet to run into a situation where it suddenly broke due to a dependency issue created when I upgraded something else. This is coming from a person that compiles nearly everything on his servers from source including core libraries glibc, OpenSSL, etc. Static linking is the simple answer if that's your concern anyway just like with any other OSS tool. Using tac-plus from the APT would be far more easier, unfortunately, it's not available any more. And, we are not interested in purchasing a Cisco ACS product just for doing what tac-plus does. I vote for the Shrubbery.net version. Worked perfectly for me for many years. Also, here's some AAA config you'll need for tacacs to log ANYTHING that gets typed on the CLI in ANY privilege level, including typos: aaa accounting delay-start aaa accounting exec NETACC action-type start-stop group tacacs+ ! aaa accounting commands 0 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 1 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 2 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 3 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 4 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 5 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 6 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 7 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 8 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 9 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 10 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 11 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 12 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 13 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 14 NETACC action-type stop-only group tacacs+ ! aaa accounting commands 15 NETACC action-type stop-only group tacacs+ ! aaa accounting connection NETACC action-type stop-only group tacacs+ ! line vty 0 15 accounting connection NETACC accounting commands 0 NETACC accounting commands 1 NETACC accounting commands 2 NETACC accounting commands 3 NETACC accounting commands 4 NETACC accounting commands 5 NETACC accounting commands 6 NETACC accounting commands 7 NETACC accounting commands 8 NETACC accounting commands 9 NETACC accounting commands 10 NETACC accounting commands 11 NETACC accounting commands 12 NETACC accounting commands 13 NETACC accounting commands 14 NETACC accounting commands 15 NETACC accounting exec NETACC The syntax is new beginning with 12.4(24)T or thereabouts but the gist of it is the same. Just rewrite the 'aaa accounting commands' lines if you're using an older IOS rev. Couple that with your normal tacacs config and you'll log every single thing typed on the VTYs. Don't forget your other lines though. Justin ___ 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] ASR1004 vs 7606(RSP720-CXL)
Jason Plank wrote: Really. The product seems to be selling quite well. You are over stating. Keep it real. Hardly. It means that people are using the Nexus as a L2 switching workhorse and relying on additional L3 hardware to bring in the basic MPLS/VPN capabilities. Justin ___ 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] ASR1004 vs 7606(RSP720-CXL)
Lincoln Dale wrote: so some extent it depends on exactly how far 'down' into your DC you extend MPLS VPNs. for example, do you extend it down to the access layer? or at what point do you map a MPLS VPN into a VRF or VLAN? Our MPLS/VPNs stop above our top-of-rack L2 switches with VRFs mapped into VLANs from there on out. Our DC isn't just a colo but is primarily a hosting solution. The gist of the difference is that we're hosting the customer's network for them in our DC; not just a colo caged environment where the SP hands them a cable with Internet access at a given CIR and walks away. Our DC is an extension of the customer's private LAN, containing all their routes. Without MPLS/VPN customer prefixes would walk all over each other. Could we do it with multi-VRF? Sure, but it would be a bitch. CVPN, L2L and firewall services are in 7600s upstream of the DC (and miles apart). Getting them down to the DC would require either tunnels in VRFs or 1Q trunks with sub-ints or SVIs assigned to unique VRFs with a matching config on the far side. Routers at each level are paired and dual-homed to the opposing levels. It would be a configuration nightmare. And given Cisco's removal of BFD support on SVIs on 7600s, it would also be slow to converge during fiber cuts, interface failures or router crashes. because even without MPLS today, many folks with N7K quite happily make use of VRFs on N7K, although in cisco parlance you'd call it vrf lite. If we had N7Ks in our DCs it would be possible but I sure wouldn't want to be responsible for the multi-VRF config between redundant chassis. It would be just as bad reaching out to hardware VPN solutions since the only VRF-aware VPN solutions in Cisco's arsenal is either an IOS router with AIMs or VSAs (I think you can CVPN or L2L into a VRF on an ISR or 7200; never tried it), or the IPSec SPAs in 6500/7600s. ASA's aren't VRF-aware. On top of that you have a 2nd set of ASAs or some other firewall appliance for hosting customer firewall contexts and they too require more 1Q trunks with sub-ints or SVIs in VRFs on the N7Ks. You're right; you can use N7Ks in DCs and get around the lack of MPLS/VPN options but it greatly depends on the kind of DC you run and the services you provide. If it's a hands-off colo environment where the SP drops the customer Internet access and doesn't nothing else on the network then the N7K is an awesome fit (possibly even over kill, not that that's a bad thing). The customer can bring their own firewall or VPN appliance if the want and they provide their own local routing and switchports. If you're DC is more of a hosting solution and you provide other services to customers (CVPN, L2L, FW, IDS) besides raw Internet and cage space then the N7K in its current form is a problem to be overcome. You can either use it to drop raw Inet to those customer that only want that service and then use it as top of the line L2 switching solution with L3 tasks handled upstream, or you pick a platform that does everything in one fail swoop. A 65/7600 with IPSec SPAs, FWSMs 67xx 10G LCs feeding Nexus or 4900 top-of-rack switches would be such a solution. I would love to have the N7K or any of the Nexus switches in my DC for L2 switching over what I have today. I'm very eager to deploy the N1K in VMWare too. That would be very nice. one nice characteristic of NX-OS is that everything is vrf aware. i.e. there is no such thing as a global table, rather there is a default vrf where everything goes if you don't explicitly use vrfs. That would be a wonderful feature. So many things on vanilla IOS are still not VRF aware. Someday... SOME people use it for L2. the majority of deployments i've seen are making extensive use of L3. Like I said above I think there are cases where it definitely works and works well. But if you sell services that don't mess with the N7K then you either have a lot of admin overhead bridging multiple products together to build your solutions, you have to limit what you use it for (L2) and rely on other products to do other things (L3, special services), or you pick a solution that does everything in one box. Personally I like top-of-rack switches over the expense of populating a 65/7600 full of electrical Ethernet ports (and the nightmare of wiring it all back to one location and a mess of patchcords on the front of a large chassis) so I would chose to use a smaller 65/7600 and go with something else for the L2. When the Nexus platforms get MPLS they will be even more awesome than the currently are and they will have even more uses throughout the network than they do today. I look forward to that day. Justin ___ 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 a DWDM SFP a DWDM SFP?
Scott McGrath wrote: Or Cisco could do something RADICAL and actually support the industry standard optics model like they USED to for GBIC's I can understand their position on 3rd-party optics not meeting spec and not inter-opting well. I've seen that many times myself on 3rd-party optics. Sure there are standards but not everyone reads the standards in the same way and there isn't a CableLabs-like standards body to certify compatibility of optics that I know of. Still Cicso could pick a major vendor or two like Finisar or Champion and partner with them to produce 3rd-party optics that they'll allow in their chassis without the hack workarounds. Cisco doesn't make all the optics that I need. I need really long single strand optics and Cisco stops at 10k. I need 20k, 40k, and 80k at a minimum. I understand that those optics wouldn't be a huge seller for Cisco but at the very least they could partner with companies that make the optics that Cisco doesn't. By not doing this SPs are forced to cobble together workarounds using media converters or budget optic transport gear. Or pick another vendor that doesn't have a problem with 3rd-party optics and/or makes optics in the lengths SPs need. Otherwise what is the point of a standardized PHY - which ALL other vendors support, We might as well go back to the days of Cabletron MIM's and their ilk. Well, not all other vendors support 3rd-party optics. Fujitsu doesn't. During an RFP Tellabs told us that they don't. I've been told that Juniper is the same way. Cabletron. Now that brings back memories...from this past weekend trying to clean out my garage. Anyone want a good deal on some 2E42-27Rs? :-) Justin ___ 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 a DWDM SFP a DWDM SFP?
Bill Blackford wrote: I do not believe that Juniper keys their optics. My experience with this is limited though. I am able to get third-party optics to work just fine in EX switches. bblackf...@wsc-asw-02-1 show chassis hardware Hardware inventory: Item Version Part number Serial number Description ChassisBH0208188142 EX3200-24T FPC 0REV 07 750-021261 BH0208188142 EX3200-24T, 8 POE CPU BUILTIN BUILTIN FPC CPU PIC 0 BUILTIN BUILTIN 24x 10/100/1000 Base-T PIC 1 REV 04 711-021270 AR0209216364 4x GE SFP Xcvr 0NON-JNPR FFX20H700284 SFP-SX Power Supply 0 REV 02 740-020957 AT0508119769 PS 320W AC Fan Tray Fan Tray As you can see it identifies the Xcvr as non-Juniper. Yeah, my J knowledge is pretty much nill. I'm going on what people with Junipers have told me. I'd love to try it out in Olive though if I could ever find a source for JunOS code that wasn't pre-hacked. On the Cisco side, I have a Vertex 1310M GLC-LH-SM that is working fine in a 3560G. Vertex... I will have to do some research on them. Is that with or without the unsupported-transceiver hack? Thanks for the pointer. Justin ___ 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 - What determines whether certain traffic is punted or not?
Drew Weaver wrote: Hi, No HSRP, VRRP or GLBP on this box. #sh mac-address-table aging-time VlanAging Time -- Global 300 no vlan age other than global age configured Routed MAC aging time: 300 seconds This is on our core, though so there are no hosts connected here. Well, I guess the next step would be to identify the ingress and egress interfaces that for these example packets and dive into the interface config to see if something on the interface is causing the punting. Can you sanitize it and post it? I once saw a situation with netflow on an interface causing all packets ingressing or egressing that interface to get punted. Something in NF got screwed up. Removing it and reapplying it to the interface fixed the problem. Sometimes things just break.(tm) Justin ___ 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 a DWDM SFP a DWDM SFP?
Jeff Bacon wrote: Will the SFPs from the ONS systems work in a cat6500? There's a plethora of ONS-SC-2G SFPs out there, but not so many DWDM-SFP- modules. I'm guessing that the disparity in supply means they don't work, but would like some confirm. (Have a temporary need to run a gig over a DWDM wave, looking for the cheap way out.) I've been told no but it's worth trying. You might be able to use the unsupported-transceiver option too. rant I REALLY wish all Cisco BUs would pick a set of optics and make them universal across ALL Cisco product lines. This crap of some products supporting only GLC- or some only support SFP- or some only supporting ONS- optics is a damn joke. Yes I know that ONSs use optics with DOM support but now so are most other things too. Create an internal standards group, define what's needed, create 1 set of optics and make all BUs use those optics! /rant Justin ___ 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] New feature, can't find it documented - NTP using DNS
Oliver Boehmer (oboehmer) wrote: I think the config doesn't honor TTL, so the implementation is rather basic.. Would that be basic as in it only resolves the FQDN once when the config is entered, once per boot, or possibly on a schedule later on in the lifecycle of the router? I noticed other changes between 24T1 and 24T2 that bit me this weekend when I upgraded 2 routers that are my NTP servers. First off all the NTP config that was moved way up in the config in an earlier release suddenly got moved back to where it was. Not a big deal but it makes RANCID unhappy. Second, and this is a bad problem, it removed my ntp source int command from the config. I didn't notice until today that my NTP servers weren't syncing up right. Reviewing the RANCID diff pointed out the problem. This happened on both of the routers that I upgraded from 24T1 to 24T2. I haven't rebooted either router to see if the problem will happen after every 24T2 reboot or if it's tied to the moving around of the config between 24T1 and 24T2. My guess would be the latter, at least I hope that's the case. I've contacted TAC to report this bug. Justin ___ 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] New feature, can't find it documented - NTP using DNS
Jared Mauch wrote: On Nov 23, 2009, at 3:19 PM, Justin Shore wrote: I noticed other changes between 24T1 and 24T2 that bit me this weekend when I upgraded 2 routers that are my NTP servers. First off all the NTP config that was moved way up in the config in an earlier release suddenly got moved back to where it was. Not a big deal but it makes RANCID unhappy. Second, and this is a bad problem, it removed my ntp source int command from the config. I didn't notice until today that my NTP servers weren't syncing up right. Reviewing the RANCID diff pointed out the problem. This happened on both of the routers that I upgraded from 24T1 to 24T2. I haven't rebooted either router to see if the problem will happen after every 24T2 reboot or if it's tied to the moving around of the config between 24T1 and 24T2. My guess would be the latter, at least I hope that's the case. I've contacted TAC to report this bug. Cisco does not have a coherent config order that will be output. This is something people need to continue to repeat to Cisco that this stuff actually matters. The folks that do testing of software rarely perform anything from a non-console connection. This has implications on the ability for them to watch and control this. People don't understand that moving lines of code have real-world implication on diff based utilities used to manage routers. Yeah, I've noticed config lines move after code updates before too and it's really annoying. Usually it's something small like adding or removing exclamation points. Occasionally things get re-ordered. This was the first wholesale move of all related lines I've seen in a while. I talked with TAC about the problem. It took a while to get the engineer to understand the problem but I think we got there. If not I will requeue. He pointed me to a known bug: CSCsx21595. He kept saying that this problem was fixed in 24T2 and only affected 3800s. To the best of my knowledge the problem (removal of existing 'ntp source' config line) was created by 24T2. I never encountered it prior to that on any of my routers, including those running 24T and 24T1. I also experienced the problem on a 7206 (G1). Clearly this isn't isolated to just 3800s. I haven't had a chance to test it on anything else but I fully expect to see the same results on all routers I test it on. I have no reason to expect otherwise. Anyway, the problem is known. I'll give it a few days and push on it if nothing happens. To recreate the problem I imagine one would just need to have a basic NTP config with the ntp source interface defined as a virtual interface (the bug said it depended on that) so use an SVI or loopback. Then upgrade to 24T2. I suspect one would need to upgrade from 24T first and then upgrade to 24T2. I suspect the problem is in the parser when IOS first loads the config from the older release. I'd bet money that the startup-config was intact when I booted and that only the running-config was altered after that first boot. Justin ___ 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] New feature, can't find it documented - NTP using DNS
Mark Tinka wrote: Like when we moved from SRC3 to SRC5 earlier this month, RANCID reported minor but strange changes to the configuration order, e.g., the 'police' command under a policy-map has been given one extra TAB indent. This looks very weird if you also have a 'set mpls experimental' command right above it because it now looks like the 'police' command is a sub-command of the 'set mpls experimental' command: policy-map XXX-XXX-XXX-60Mbps description XXX XXX XXX class XXX-XXX-XXX set dscp 63 set mpls experimental imposition 0 police cir 6000 bc 1125 be 2250 conform-action transmit exceed-action drop violate-action drop Previously, as in the case of moving from SXH3 to SXI2a also, IPv6 static routing and ACL commands keep moving up and down the configuration. I wouldn't be surprised if this has been noticed and gets fixed in SRC6 or later, and then we have RANCID crying all over again. I forgot to mention the other non-NTP config change I noticed in 24T2. My IOS object-groups were changed. When I first created object-groups in IOS there wasn't an option to define just a single host. It was added in a later T release. To get around this I defined a range of a single IP (ie, 1.2.3.4 to 1.2.3.4). I never went back and changed them after the 'host' option was added. When I upgraded to 24T2 it changed all those range lines to host lines. Not a bad change but another unexpected one. Justin ___ 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] Anyone seeing excessive shipping delays on ASR1006 and Catalyst 4500 series equipment?
Jeremy Reid wrote: Hey Group, Has anyone recently been seeing unusual/extended delivery dates being provided on Cisco ASR1000 series or Catalyst 4500 gear? We've had some sizable orders in place since July and we keep getting the ship date extended out each time it approaches. Currently, shipping estimates are out yet another month, bringing this to a 4-5 month wait (should the latest estimate actually come in when promised). I have a 1002 on order. The shipping ETA was set at 2.5 months from my order date. We have to have it in hand this calendar year though. If it doesn't ship by 12/31 we're canceling it. We also ordered a 4948. It was set at nearly 4 months. Same thing with it. It either gets here in 2009 or it gets canceled. That's the downside of buying direct. There isn't a distribution buffer in the middle to stock up and deliver from stock. When you place an order for something like an ASR they give the order to manufacturing (heard this from our AM). Other items like a 4948 or ISR are filled as available. Call you AM and make big waves. Research other vendor's options and mention them when you call. Makes the waves a bit bigger. Good luck Justin ___ 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] reverse path filtering doesn't seem to work
Mike wrote: Yes it's enabled per the above. The drops only occur when I use: ip verify unicast source reachable-via rx However, I discovered that if I instead use: ip verify unicast source reachable-via any allow-default That seems to at least not drop packets, but I haven't tested to see wether it really will drop everything but the subnet routed down this link. If I can ask, you seem to have something more than 'loopback 0' - tell me, how are your routes configured - I am assuming you just have a static route pointing thru the interface and not at 'loopback' anything, yes? Lo197 is addressed with a /24. Each customer gets a /32 from that /24 via a static route pointing to the local PE interface (Se1/0/3:0 or Mu1000 for example). If the customer needs a larger allocation I route that to their /32 (could also route it to the local PE interface as well). In cases where the CE is managed I also route a private IP over to it and assign it to a local loopback on the CE. We use this for all management tasks and never use the CE's public IP. You're right; it is fairly simple. We're using this quite a bit these days. Some customers insist on a dedicated /30 but it doesn't gain them anything really. After explaining this they usually agree to a /32 instead. No sense in squandering a limited resource if we can avoid it. I'm leaning towards an IOS bug for your particular issue. Is you IOS release fairly modern? Justin ___ 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] [j-nsp] Network Liberation Movement???
William McCall wrote: Sorry to re-open. Good job to HP for generating noise. Anyone want to buy some procurve switches? I don't own a boat, hence no need for a boat anchor. Justin ___ 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] BDF over port-channels?
luismi wrote: I wrote it in a previous email but here is again :D 7200 npe-g2 and 7600 rsp720-pfc3 I am using 12.2SRC but it is not supported there an I would like to know if it is supported in another train. 12.2SR is all you can run on the RSP720. SX and SR will both run on the Sup720 but certain LCs are not supported in SR and visa versa. I only run and recommend 12.4T on 7200s so I can't speak to the 12.2 features for that platform. Justin ___ 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] how to make ASA vrf-aware / remote-access client VPN
Ge Moua wrote: C-NSP Wizards: Our Cisco account team seems to be touting the ASA appliance (in a cluster configuration) as the preferred solution for remote access client vpn (IPSec SSL); as such my question then is: Is it possible to make an ASA be vrf-aware? My suggestion may not be what you want to hear but I'll give it to you anyway. Forget the ASA cluster and implement it on VRF-aware hardware. You'll never see the end of problems with a cluster such as this and it will be a nightmare for troubleshooting. It will cost you more up front but it's worth doing it right. We use 7600s with FWSMs and IPSec SPAs to provide firewall services and VPN termination services to our Data Center. The FWSMs of course do not do VPN, only firewall services. The IPSec SPAs have their own quirks (see some of my earlier c-nsp posts) but they work fine once you know how to avoid those problems. This solution doesn't so SSL VPN though. The 7600s don't support the WebVPN module which is what you need for SSL VPN. However the 6500 does and also supports the FWSMs and IPSec SPAs. On a lower-end scale you can provide the same VPN services on ASRs, 7200s and even ISRs without having to fight the ASA nightmare. I would avoid the ASA solution at all costs. Duct tape is great until the sticky gives up in the middle of the night. Baling wiring rusts too. Stick with the right solution and you'll be fine. My $.02 (pre-2008 dollars) Justin ___ 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] show logging system ??
Jeff Fitzwater wrote: We had a module fail on a 6500, which reseating it cured it for now. Looking at the System Logs using the show logging system I see the following messages at the time of the failure.I have not found the explanation anywhere on the CISCO site for the values in these messages. Any ideas what they mean? The module is a 24 port 100M MM of which the first 12 ports failed. That's particular LC has 12 ports per ASIC: https://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hardware/Module_Installation/Mod_Install_Guide/02ethern.html#wp1047420 I would guess it was a bug that caused one of the ASICs to freak out or an ASIC that's failing. Justin ___ 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] Aftermarket/DIY mounts for Cisco ISR AIMs
Dale Shaw wrote: Hi, Long story short: we've got a bunch of VPN AIMs but no mounts (stand-offs/spacers). It happened 'cause a colleague removed them for government security compliance reasons, but left the mounts behind (still attached to the system board). It's not feasible to recover the mounts from the now-deployed devices. I've seen some pirates on eBay charging USD $24 per kit. I went into my local electronics bits n pieces store (Jaycar) and they didn't have any compatible stand-offs. I asked our Cisco distributor but they advised the OEM part is not available as a spare [and if it was, it'd probably make the eBay pirates look like animal rescue volunteers]. If anyone has had to do this before, please points me in the right direction. If anyone knows of a good online retailer that sells this sort of thing, I may get motivated enough to do some experimenting. Have you tried Mouser? http://www.mouser.com/ I bet they carry them. Order a catalog and call them on the phone. Justin ___ 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] Ignoring 7200 Bandwidth Points
I've got a 7206VXR w/ 4 PA-A3-OC3SMI PAs serving a couple thousand PVCs of RBE DSL. I have another 2x OC3s on a 3660 doing the same thing only with less PVCs. The 3660 crashed twice earlier this week in one day. Once was on its own. The second was in the middle of a sh tech. I sent the crashinfos to Cisco but didn't get much info back. The 3660 is EoS as of 12/08. There are problems on the 3660 and the 2 DSL systems that it served and the problems don't appear to be random. Some DSL customers (and these persist over time and through reboots) aren't able to get an IP. DHCP is on the 3660. In the debugs I see the DISCOVER come in and the OFFER get sent back out. Some time later (15-60s) I get another DISCOVER. It's as if the CPE never received the OFFER, timed out and sent another DISCOVER. The carrier equipment beyond the 3660 is AFC gear. They've rebooted DSL cards, CPUS, LETs, OC3 cards, etc but nothing fixed it. I rebooted the router in the end and the reports were that the problem went away. However the customers are now calling back in reporting issues again. And again I see OFFERs go out and never get a REQUEST back. One-way communication? I'm considering moving the OC3s over to the 7206 (NPE-G1). I'll have to pick up some PA-A3-OC3SMI PAs to do it. I believe my 4 existing OC3s put me at the max on bandwidth points. However throughput on them is very low. Average CPU on the G1 is less than 10%, throughput on the OC3s averages only 10-15Mbps with peaks maybe twice that. I believe I read that I can ignore the bandwidth points warning and load up the chassis if the PAs are running at sub-rates. Would 6x OC3 PAs running at the low rates I described be a problem for a G1? I can pick up a couple extra OC3 PAs and have them here in a few days if that's the case. Thanks Justin ___ 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] 12.4(24)T2 has been released
Just a reminder to all those who were waiting on the release of 12.4(24)T2 that addressed most of the bugs reported by PSIRT on 9/23, 24T2 was posted this morning. http://www.cisco.com/en/US/docs/ios/12_4t/release/notes/124TCAVS.html It's supposed to also address the bug that prevents NTP access-groups from working properly. Justin ___ 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] Inserting a default route into a MPLS/VPN pointing out of the VRF
Phil Bedard wrote: If you are already using a VRF to carry the default table you should be able to import a default route from that vrf into your customer vrf. You can use an import-map to select only the default. The only time I've implemented something similar to this I've used external firewalls which have their own trusted sub-int into the customer network and their untrust side connected to an Internet router. Similar to what you say you are doing on the datacenter side. You could do the same thing without a firewall, just need a dedicated trunk so you can bridge between the default VRF/global table and the customer VRF. Then just static routes out that interface. Thanks to all the replies. I didn't word my initial message very well. My Internet tables are in the default VRF (ie, the global VRF). I don't carry around Inet tables in dedicated VRFs (though I've been told by some that this is a good idea). My FWSMs provided me the same functionality as your external FWs. Unfortunately this is for raw, unfiltered and unprotected customer Internet access. I suppose a different technique would be to take these special customers and use routing to push traffic destined for the special peering network into that dedicated VRF and keep all their other traffic in the default VRF. While I can say that I can't envision a way to accomplish that. I think it's easier to start in the dedicated VRF and leak traffic out of it. I thought of a couple possible solutions last night. One was the use of the 'global' statement in the default route inside the VRF. It has the same problems as the static route to an interface. I want the core Ps to make a routing decision on the upstream exit point which I can't do if I'm setting the next-hop to be an IP on an upstream router or an interface facing an upstream router. The other option I thought of was to not inject the default on the core Ps but instead do it on PE1, the peering router to this special network. Ultimately PE1 will be dual-homed to P1 and P2. I could then set the next-hop for the default in the VRF on PE1 to be a FHRP floater on P1 and P2 and use that as the global IP. I think that would work too but haven't tried it. Another c-nsp reader gave me what I think will most likely be my solution. His suggestion was to use an import map on the VRD, a route-map and prefix-list to import a default route into the VRF that way. I'm sure that will work. I'm intrigued by the tunnel solutions too. PE1 will be replaced with an ASR in a few months so I may give that a try as well. It's good to know all the various ways to accomplish the goal in case I have to implement something different someday. Thanks for all the suggestions Justin ___ 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] Inserting a default route into a MPLS/VPN pointing out of the VRF
Brett Frankenberger wrote: Cisco has no support for: ip route vrf vrfX x.x.x.x/x next-hop next-hop vrfY where the traffic in vrfX matching that route would be sent over into vrfY (and then forwarded according to vryY's forwarding table). (Some other vendors can do that.) (In your case, you want vrfY to be global, but that's not doable either.) I cracked open my MPLS books last night and found a similar solution with an IP next-hop in the MPLS VPN Arch book. It set the next-hop to be an IP in the global VRF by using the 'global' keyword. ip default vrf VRFx 0.0.0.0 0.0.0.0 1.2.3.4 global It has the same problems as the other solution I found for setting the next-hop to be an exit interface. I want the Ps to make a routing decision to determine the exit path for the packet, not hardcode it to go one way or another (and possibly have a iBGP-meshed BR1 decide that the better exit point would be another BR and route that back to the core P to get to BR2. This is why I was wondering if the target interface or IP could be a loopback on the Ps. I really need to lab these ideas. The only clean way is to connect via an interface. For example, connect a cable from GIa/b to GIc/d and then configure: int GIa/b ip address x.x.x.1/30 int GIc/d ip vrf forwarding vrfX ip address x.x.x.2/30 ip route vrf vrfX 0.0.0.0/0 GIc/d x.x.x.1 (obviosuly I'm not using exact IOS commands above, but you get the idea.) I thought about that and I could do that. It's an added expense though. On some platforms, this can be done with tunnels instead of physical interfaces to avoid using two physical ports and dealing with the risk that those ports might fail: int lo1 ip address z.z.z.10/32 int lo2 ip address x.x.x.20/32 int tun1 ip address x.x.x.1/30 tunnel source lo1 tunnel destination x.x.x.20 int tun2 ip vrf forwarding vrfX ip address x.x.x.2/30 tunnel source lo2 tunnel destination x.x.x.20 ip route vrf vrfX 0.0.0.0/0 tun2 How well this works depends on how tunnels are implemented on the platform you're using. It works fine on software-based routers. ASR1000s worked OK in my testing. Never tried 6500/7600s. This is a thought. I haven't tried it on 7600s either but it's worth trying to see if it would work. Note that the suggestion to leak default from your global table into the VRF potentially fails on two accounts. First, you might or might not have a default in your global table. Second, if you do, leaking that would direct all internet traffic to follow the default route, and, assuming you have default plus a lot of more other routes in your global table, you wouldn't want traffic covered by a more-specific in the global table to follow the default if it originated in vrfX. That is, with a global table of: 100.0.0.0/8- A 0.0.0.0/0 - B if you import only 0.0.0.0/0 into a vrf, then all traffic matching the default in that VRF will be sent to B, even traffic traffic to 100.0.0.0/8. I originate a default in my IGP on each BR currently. I'm thinking about moving that into iBGP though. I'll originate a default on the Ps in the VRF with MP-iBGP. This touches on the problem I outlined above talking about the Ps making the decision on exit path. My Ps are part of the iBGP mesh with full tables from the BRs. In theory they should make the same routing decision for a given packet that a BR will do when it receives that same packet milliseconds later. I'm going to try the importing of the default in the VRF statement. I think that will work but I'll find out for sure with my testing. If it doesn't then I may have to try the tunneling solution. I may have to settle for inefficient routing for a few months until the ASR comes in and then do tunnels on it. Either way I think I'm on the right track. Thanks for the insight Justin ___ 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] Inserting a default route into a MPLS/VPN pointing out of the VRF
I'm having to rush a MPLS/VPN into service this week. Certain customers will connect into this MPLS/VPN on PEs facing L2 switches with sub-ints in the correct VRF, MLPPP bundles, direct connect to PEs, etc (lots of variety down the road). Simple so far. The majority of the traffic will exit our network out another PE at a peering point across our network, exiting out another interface also assigned to the same VRF. Still simple. I'm doing similar things today to support our data center and some other L3VPNs. Easy stuff. The problem that I'm faced with is figuring out how to insert a default route into that MPLS/VPN. I do this today with the data center VRFs with the assistance of a FWSM in our core. I insert a default route pointed to the backside of the customer's context on the FWSM; that route is a static in the VRF. The FWSM bridges the gap between my MPLS/VPN and my default VRF quite nicely. However in this situation I can't use the FWSMs. I need to extract traffic from the VRF for the private network and out into the default VRF on my core where I keep my Internet routes. Longest-match will take care of the MPLS/VPN routes to properly route traffic to my peer. Everything else needs to get out of the VRF and to the Internet. At my main POP I'm planning on inserting 2 default routes, 1 from each core router with different weights. My daul core routers are homed to both of my border routers. Here's the simplified topology: BR1 BR2 | \/ | | /\ | | / \ | P1P2PE1--Peer | | | | PE2 PE3 | | CE1CE2 There are more Ps and PEs but this gets the general idea across. I've come across route-leaking examples but they all require me to point traffic to an outward-facing interface. Ie, I can't just point the default route to a specific upstream-facing interface. Is there another way? I can't see a solution with importing routes at the route-target level. Can I point it to a loopback outside of the VRF? http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml This is probably a simple process but I haven't had to do it before without the FWSM which made it trivially easy. What simple solution have I overlooked and will kick myself for missing later? Thanks Justin ___ 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] Unable To Use T3 Card (PA-MC-2T3-EC)
Gert Doering wrote: I am currently running (C7200P-SPSERVICESK9-M), Version 12.4(4)XD10 ... it might be that this software just doesn't know about this specific PA (which is very new, and anything based on 12.4(4) is a few years old now regarding hardware support). C7200P smells like NPE-G2, so you don't have that many options - I'm no NPE-G2 expert, but I think all you *can* use is 12.4T or 12.2SR - so I'd pick a recent one of either IOS versions and try that. Or go for 15.0(1)M, which might or might not be less bugged than 12.4(max)T. I agree. Dominic is running a code train that was put out just for the initial release of the NPE-G2. He's running a code train that's slated for death essentially and should move into a regular train such as 12.4 mainline, 12.4T or 12.2SR since G2 support has been rolled into them. I haven't yet loaded 15.0 on a G2 but I am running on one on 24T1 and that box has a PA-MC-2T3-EC in it. It of course has the NTP bug (and several others) that require 24T2 or 15.0 to fix. 12.4T has been fairly stable for me though. Justin ___ 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] Anomaly Detection Module/Anomaly Guard Module
Drew Weaver wrote: I was wondering if anyone has any experience working with the Cisco ADM AGM modules for the 6500s and how they compare with external appliance based solutions for DDoS mitigation. Anyone have any opinions on these? It seems like it would be nice to just drop these into a few systems but I'm just trying to avoid caveats that mitigate (pun intended) the usefulness of these products. If you try to buy the LCs your account team should try to convince you to go with the appliances instead. My account team told me that they LCs are being terminated at some point in the future and replaced with the appliances so if you buy the LCs today you will most likely run into software limitations down the road as appliances get all the good stuff and the LCs get bug fixes only (at some point in their life at least). I'd go with the appliances. Justin ___ 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] Problem encountered while securing NTP
Kevin Graham wrote: CSCsw79186. Its broken more than the bug suggests; both v3 and v4 clients are get applied only to the 'peer' access-group. I had meant to bring this to PSIRT's attention when the advisory went out, but got distracted by something shiny. Excellent catch. I tried to search the BugToolkit today for anything related to NTP and couldn't get it to work. I rebooted the router tonight and bumped the rev to 24T1 in hopes that it would fix the issue. It didn't. Clearly this problem isn't fixed as the BugToolkit indicates since there isn't a T-train release with the alleged fix in it. I'll hammer on them later today about this. I don't think that the severity of the problem is moderate as the bug notes indicate. For me it's severe since it's affecting NTP from our VoIP phones and soft switch. I think the PSIRT folks would also disagree with a failure of NTP being only a moderate issue too since logging with accurate timestamps is essential to any security model. Justin ___ 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] Problem encountered while securing NTP
Given the recent NTP PSIRT from Cisco (cisco-sa-20090923-ntp) I decided to spend the morning revisiting my NTP practices to lessen the chance of getting kicked in the teeth by this router-crashing bug later on. In my networks I usually have a pair (or more sometimes) of border routers as local NTP servers, advertising themselves internally as stratum-3. They use stratum-1s on the Internet in geographically diverse areas. The local network devices are configured to use both of the local NTP servers with authentication. Here's a border router's config: ntp authentication-key 1 md5 BLAHBLAHBLAH 7 ntp authenticate ntp trusted-key 1 ntp source Loopback1 ntp access-group peer 5 ntp access-group serve-only 6 ntp master 3 ntp update-calendar ntp server a.a.a.a prefer ntp server b.b.b.b ntp peer LOCAL.BORDER.RTR.TWO key 1 ntp server c.c.c.c ! access-list 5 remark NTP Peers access-list 5 permit 127.127.7.1 access-list 5 permit a.a.a.a. access-list 5 permit b.b.b.b access-list 5 permit c.c.c.c access-list 5 permit LOCAL.BORDER.RTR.ONE access-list 5 permit LOCAL.BORDER.RTR.TWO access-list 5 deny any log ! access-list 6 remark NTP Serve-Only access-list 6 permit LOCAL.NETWORK.MANAGEMENT.PREFIXES x.x.x.mask access-list 6 permit LOCAL.RIR.ASSIGNED.PREFIXES x.x.x.mask access-list 6 deny any log Here's a client device's config: ntp authentication-key 1 md5 105D020D0619061B4851 7 ntp authenticate ntp trusted-key 1 ntp clock-period 17179513 ntp source Vlan224 ntp access-group serve-only 6 ntp server 64.71.98.51 key 1 ntp server 64.71.98.59 key 1 ! access-list 6 remark NTP Serve-Only access-list 6 permit LOCAL.NETWORK.MANAGEMENT.PREFIXES x.x.x.mask access-list 6 permit LOCAL.RIR.ASSIGNED.PREFIXES x.x.x.mask access-list 6 deny any log (Same as above for simplicity's sake) That's my standard NTP config that I run on several networks without any real problems, normally. There may be other or better ways to help secure NTP that I either haven't implemented yet (iACLs, CoPP) or don't know about but I'm always open to suggestions. The problem I'm running into today is that the 'access-group peer' statements on the NTP servers are matching local clients with ACL 6 as well as configured stratum-1 peers (successfully matching the peers at that). The local clients should be matched with the 'access-group serve-only' ACL 6, but for some reason they are not. Strangely enough I have ACE counters increasing on ACL 6's lines that correspond to my network infrastructure, even though the 'deny any log' ACE in ACL 5 is also reporting denied hits for the very same subnets. It's as if I've freaked out NTP. I made changes to the ACL earlier today as part of my initial review. Then NTP for the network infrastructure stopped working. Could this be an IOS bug by chance? My next step is to blow away the NTP config from the borders, hopefully killing the NTP process at the same time, and re-add the config. Thoughts before I blow away the config and start over? Justin ___ 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] Will UDLD work with converters ?
Mark Tinka wrote: We've seen strange issues with converters were providers were unable to guarantee Jumbo frame MTU sizes because the media converters don't support them - what the hell... This happened to me with Versitron MCs. I had a set in production that worked perfectly fine. Then one day BGP started flapping. A lengthy period of time for troubleshooting later it was finally determined that the damn MCs suddenly started filtering jumbos in only 1 direction. I hope that doesn't hold true for some of my other more important Versitron GigE links where I have 8 of the very same model back to back... Justin ___ 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] Will UDLD work with converters ?
Jeff Fitzwater wrote: Is there any issues with running UDLD with TX to Fiber converters at each end of a gig cisco to cisco link? We are just over the distance budget with the 10KM optics. 6500 TX port--- to fiber converter--- 18KM fiber--- to converter--- back to TX port on 3750. Should work fine. I'm doing the same thing over several back to back media converters with 80k optics. I'd love to replace the MCs with something better but otherwise UDLD works fine over them. We are looking at the converters because the Cisco ZX optics are very expensive and the converters with 30KM optics are much cheaper than the 60 KM ZX optics. Agreed. This is on my list of major Cisco gripes. 10km is laughable in the SP world. Where are the 20k and 40k optics? Where are the 80k and 110k optics? Cabletron had 110k optics a decade ago. The single-strand Cisco GigE optic is limited to 10km too. Single-strand optics are critical in the SP world. Not everyone has excess bundles of dark fiber to play with to turn up a simple GigE link. I understand that Cisco wouldn't sell a lot of these since most of their business is enterprise. I get that. I would suggest that they pick a well-known and reliable SFP manufacturer like Champion and support their optics. Fill in the void with someone else's gear if you don't think the cost would justify the benefits of doing it yourself. There are other ways to do things besides doing it all in-house. Another major Cisco SFP gripe I have is that some BUs require optics that no other BU supports which makes common sparing across your product lines impossible. The ONSs require specific optics. The GLC- and SFP- that the switches and routers support don't work in ONS's LCs like the XPonder. We've found that the SFP- optics aren't supported in some switches with older code. DOM isn't universally supported so why pay for thee DOM optic when your switch or linecard doesn't support it. DWDM SFP support was added to some switches in the later 12.2(40+)SE releases such as 12.2(46)SE for the ME3750. However it wasn't added to all switches such as the 3560, 3750, or 2960 but it was added to the 3560/3750 E series. The beefy 4948s and monster 4900Ms are still out in the cold on DWDM support for SFPs too (I know that the 10G X2 optic supports DWDM). It seems to me that there should be a standards body within Cisco that should mandate certain minimum requirements of all product lines. If and when there is the ability for BUs and product lines to share common and trivial products like SFPs then they should require it. It would save them RD and QA money if nothing else. Back to your question though, yes UDLD should work fine over MCs. Justin ___ 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] Will UDLD work with converters ?
Nick Hilliard wrote: [100% agreed on rant. ghods, it is so depressing to fork out for cisco optics and find that they don't work on other cisco gear]. Yeah, it's awful. We're looking at ONSs right now and are faced with the penalty (I think that's the appropriate word) of having to spare a completely unique set of GigE optics just for the ONSs. I can understand to a degree Cisco only supporting Cisco optics but not even all of Cisco supports all of Cisco's optics. That's the worst part about it. On 02/10/2009 15:27, Justin Shore wrote: Back to your question though, yes UDLD should work fine over MCs. as someone else noted, only for optical transceivers. TX does not support UDLD (which was what the original poster was wondering about). I saw that as well and that's curious because I'm doing it today on TX interfaces. Been doing it for years and it works great. It's even served it's purpose on one occasion when a 80k single-strand optic in a series of back to back MCs partially failed and was transmitting but not receiving. Locating the 1 bad optic was a PITA but at least it brought the link down so my alternate routing paths picked up the load with minimal loss. 7613-1.clr#sh int gi9/9 capabilities GigabitEthernet9/9 Model: WS-X6748-GE-TX Type: 10/100/1000BaseT Speed: 10,100,1000,auto Duplex:half,full Trunk encap. type: 802.1Q,ISL Trunk mode:on,off,desirable,nonegotiate Channel: yes Broadcast suppression: percentage(0-100) Flowcontrol: rx-(off,on,desired),tx-(off,on,desired) Membership:static Fast Start:yes QOS scheduling:rx-(2q8t), tx-(1p3q8t) CoS rewrite: yes ToS rewrite: yes Inline power: no SPAN: source/destination UDLD yes Link Debounce: yes Link Debounce Time:no Ports on ASIC: 1-12 Port-Security: yes 7613-1.clr#sh udld neighbors Port Device Name Device ID Port IDNeighbor State --- - ----- Gi9/90169D2180B4 1Gi1/1 Bidirectional Gi9/9.40 0169D2180B4 1Gi1/1 Bidirectional 6524-1.brd#sh int gi1/1 capabilities GigabitEthernet1/1 Model: ME-C6524GT-8S Type: 10/100/1000BaseT Speed: 10,100,1000,auto Duplex:half,full Trunk encap. type: 802.1Q,ISL Trunk mode:on,off,desirable,nonegotiate Channel: yes Broadcast suppression: none Flowcontrol: rx-(off,on,desired),tx-(off,on,desired) Membership:static Fast Start:yes QOS scheduling:rx-(1q2t), tx-(1p3q8t) QOS queueing mode: rx-(cos), tx-(cos) CoS rewrite: yes ToS rewrite: yes Inline power: no Inline power policing: no SPAN: source/destination UDLD yes Link Debounce: yes Link Debounce Time:no Ports on ASIC: 1-12 Remote switch uplink: no Dot1x: yes Port-Security: yes 6524-1.brd#sh udld neighbors Port Device Name Device ID Port IDNeighbor State --- - ----- Gi1/1 0187425650 1Gi9/9 Bidirectional Gi1/1.4010 0187425650 1Gi9/9 Bidirectional Perhaps TX UDLD is only available on certain platforms. Justin ___ 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] Will UDLD work with converters ?
nick hatch wrote: I get that too, but I strongly disagree with the strategy. In this part of the world (Whatcom/Skagit county, Washington state), dark fiber is cheap and readily available for about the cost of a T1 in many locations. (If buildout is required, it's often subsidized into the MRC.) Unfortunately where I'm at in the Midwest there is no dark fiber to be had. None of the large local LECs are willing to even carry a wavelength for a customer. There simply isn't anyone in the areas that I'm located to in offering wavelengths or dark fiber as a product to force the other players to compete. Now in KC, Denver, Lincoln or OKC it's different story. There are enough people willing to do it there that the other LECs have all fallen into step and also offer the service. Many are the very same LECs that refuse to do so here. My network at $dayjob is hardly big enough to be considered enterprise (our fanciest piece of kit is a 3560), yet for branch locations we still have the need to use unsupported 70km and single-strand optics. I'd love to have the potential to lease dark fiber like that. It would make my life much easier. Surely the world has other communities like this, with cheap plentiful fiber? $4k for a ZX transceiver with the right logo on it is laughable. It depends on the market but it's not available everywhere. Forbes rated a city 15m away from our HQ (and one of the towns we CLECed) in the top 10 of IT meccas in the US and yet it's still not possible there. Go figure. The state independent telcos are working together to build a state fiber network to provide low-cost transport across the state, like what they did in Indiana and Texas. It's a few years out though. Justin ___ 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] Hardware for 'managed firewall'
David Hughes wrote: Interesting. I thought NSM was much better than Cisco's CSM (and a hell of a lot cheaper). You should really take a look at the new ADSM releases for the FWSMs. It's actually pretty good. You have full control of all contexts if you aim ADSM at the admin context. Of course I never use the GUI anyway so what does that matter? As for FWSM's, after spending months trying to debug early versions that did random very bad things with traffic when in the same chassis as CSM linecards we decided never to touch them again :) I don't have those LCs so I can't speak to that. They work fine with ACE's though. We have only had 2 problems with the FWSMs. The first was caused by IOS on the RP getting confused over which VLANs it was supposed to be passing the FWSM (firewall-group). A reboot of the RP was needed to fix it. The second was a FWSM that failed after a lightning strike this past summer. DC power to the chassis wasn't ever lost and none of the other LCs ever showed any signs of not working right. However that LC failed within minutes of the power failure that the strike caused so I think it has to be related. That required an RMA. Other than that they've worked great for us. We supply crypto in our 7600s for the data center with SSC-400 2G IPSec SPAs. Now if you want to talk about a funky LC, let's talk about those damn things. Our 3 biggest outages of our entire phone system (ILEC and CLEC) were thanks to those damn IPSec cards. The AS SMEs that configured them initially screwed up the config which caused 2 of the outages. The 3rd one was a similar repeat thanks to the default VLAN list being allowed on both virtual interfaces at once. Watching a RP crash under the load of a single HSRP packet repeated several million times per second is surreal at best. I spent 13 hours Sunday-Monday morning troubleshooting a new problem with those LCs. Apparently the crypto engine can't accept MPLS-labeled packets and route them properly. A TCAM lookup sends them to the RP which drops them saying that it can't do crypto. My TAC engineer is telling me that the features enabled on the outward-facing interfaces are causing this. He's saying that the interfaces can't have either MPLS enabled or have a service-policy. How in the world do they expect a SP to use these things if that's the case. Every interface in a SP environment will have a service-policy on it and all interfaces except the CE-facing ones are MPLS-enabled. Baffling. Justin ___ 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] Smartnet pricing?
Steven Saner wrote: Is this really available? I was asking a SmartNet rep about this once and was led to believe this isn't an option. Maybe it wasn't then and is now? Maybe they were pulling my leg? Sure. For a 7206VXR the part number is SP-SW-7206VXRN. However I don't generally recommend people buy it. The software-only version doesn't come with any sort of hardware replacement. For a wee bit more you can get the RTF SmartNet (SP-RR-7206VXRN). That's Return To Factory 10-day turn around service. That's what you should get if you're implementing a sparing strategy. List on the SP-SW for a 7206VXR is $2688. List on the SP-RR is only $2895. So for a 7.7% increase in costs you can get a hardware replacement option. 8x5xNBD adds another $400 to the cost. 24x7x4 is nearly double the SP-SW option. The only time SP-SW makes sense is if you have an extremely large network and decent sparing strategy, where having a 1% hardware failure rate and eating the cost of the failed router (to replace it with a spare) costs you less than SP-RR coverage on all devices. It's also good if you have a huge inventory of spares for a given model to back you up in case the covered unit shoots craps on you. Personally I've taken my SP down the path of buying RTF coverage for everything that has a backup (hot or cold) and then putting either 8x5xNBD (AR1) or 24x7x4 (AR3) on the devices that I don't have a good backup for. The money saved was put towards buying more spares. The collection of spares also gives me a lab to work in. With those spares I can have a failed device replaced in an hour or two vs a minimum of 4 hours plus however long it takes for TAC to decide that a RMA is needed. Justin ___ 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] Smartnet pricing?
Gert Doering wrote: How do people get these part numbers? For our smartnet contracts, getting the right numbers for various 6500+sup720 combinations seems to be nearly impossible. Gert, Two ways that I can think of. The first is from the Global Price List on cisco.com: https://tools.cisco.com/qtc/pricing/MainServlet Or by way of the Dynamic Config Tool when you build a quote: https://apps.cisco.com/qtc/config/jsp/configureHome.jsp I'm assuming that all registered users have access to that information. My CCO has several entitlements added to it so it's possible that other CCOs can't access the same data. Your AM should be able to get the GPL added to your CCO though. Justin ___ 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] Hardware for 'managed firewall'
Dave Weis wrote: We want to provide a hosted/managed firewall service for our MPLS customers. Is a pair of ASA's with multiple contexts the best way to do this or would something else work better? I'm not concerned with the customers being able to make changes themselves. We do this with a pair of FWSMs in a pair of 7600s. Customers in our data center reside in MPLS/VPNs. The FWSMs upstream in the network are their ticket out of the MPLS/VPN and out to the Internet. Each customer is in their own context. Not too difficult. We could have done this with ASAs but they do not scale as well. If you want to start cheaply then yes you can use ASAs but research their limitations (especially, # of context and throughput vs price). Also be sure that you understand that you can not use VPN on a ASA with multiple contexts. If you need to terminate VPN services (L2L or client) and put them into isolated customer environments on the secured side of the network then you need to look into a router-based platform. So you know, no Cisco firewalls are MPLS-aware; that includes the FWSM. However you don't really need it since you only need to map VLANs to it. The VLANs themselves can be in the necessary VRF, thus making that context partially in that VRF. ie, VLAN 100 is in the privately-addressed customer VRF and is assigned to the context and used as the inside interface. VLAN 200 is publicly-addressed, not in a defined VRF (default VRF or wherever you keep your public Internet at), is assigned to the context and is used as the outside interface. The customer can manage their own context if they want but we don't yet have any that do this. You could let customers bring their own FW if they want by mapping the inside and outside VLANs to switchports in your data center (one on the public side and one in the customer VRF) and letting the users use those. Justin ___ 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] Another bughunt, this time VRF PBR
David Freedman wrote: wonder if anybody has come across this before, in 12.4(15)T, configuring a virtual-access per-user such: I hate to suggest the obvious but since there are so many bugs in 12.4(15)T have you considered bumping that to the latest minor rev? I think they're up to T7 or T8 now (must have been some bug list). Justin ___ 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] Power Issue
Mohammad Khalil wrote: We have Cisco device cisco ME-C6524GT-8S (R7000) processor (revision 1.3) with 458752K/65536K bytes of memory. now the issue is that we have in each site a device like the mentioned and a WiMAX RAS , all is functoning on DC power now the issue is that we are experiencing Traffic down (coz of RAS down) even that no interface on the switch went down nor something mentioned in the switch i want to know where can i resolve this issue can i monitor the power ?? i tried to use snmpwalk but didnt get any result , is that due to an IOS version ?? which keeps the ME6524 If I understand your query correctly, your RAS is going down and the ME6524 isn't getting a link down. Is that correct? When you say that the RAS is going down are you saying that it's powering down and that there should be a link down on all interfaces connected to it, or are you saying that internally the RAS is not passing traffic for whatever reason (config error for example) but its Ethernet links are staying up which lets the ME6524 keep sending traffic towards the RAS? If the links aren't going operationally down then the ME6524 really isn't to blame if it keeps on sending traffic out those links. Is the connection to the RAS a routed connection (interface) or a switchport? If the WiMax is used as a backhaul link between 2 sites and the interfaces of the routers on each end are routed interfaces then you could use BFD to ensure that L3 connectivity is up across the path. If it's a switchport on each end but otherwise has the same network scenario (backhaul, not CE-facing) then you might be able to accomplish something similar with UDLD. You could probably get fancy with IP SLA and some static routes to create some similar as well. Be forewarned, if you're still using the initial code release for the ME6524 (12.2(ZU)) and you implement BFD on a SVI then you will lose that working feature when you upgrade to SXH. You can search the list archives for numerous posts regarding that change. If I've completely misread your query and you are in fact asking about DC power in the ME6524 and are trying to figure out how to query it via SNMP to see if a power supply has failed, then I have no idea. My ME6524s are also DC-powered. Do you have 2 separate DC buses connected to each ME6524? Is the RAS on one of the same buses? Does it have dual power supplies with dual buses connected to it as well? Justin ___ 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] ASA5520 which image should I use?
Antonio Soares wrote: Stay away from 8.2. We are experiencing crashes since July (TAC case involved). Tomorrow we will install 8.2.1-10 to see if finally we get rid of this. I've had good luck with 8.2.1-3 for our purposes. Any 8.2 prior to that has that nasty coredump feature that writes to flash every time you do a 'sh run' (RANCID users beware). Justin ___ 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] ASA5520 which image should I use?
nm...@guesswho.com wrote: Justin, I believe I saw your posts on the RANCID list and although the 8.2 coredump problem can be a pain you can modify your rancid script to ignore the coredump file when rancid does a show flash. I do this for dhcp snooping since the db is small enough that I can keep it in flash. (Yes I know about the warning that they give when you configure like this) Every time a lease expires or a new lease is distributed the file is updated which would make rancid grab the change. Nick, I could have modified a copy of the RANCID scripts to just use to work around the problem but that only addresses the RANCID problem. I kicked it around and ultimately decided to just slow down the rate that RANCID checked that device while I worked with Cisco on a solution. Modifying the RANCID scripts doesn't help address the bigger picture. The DE who programmed that feature to rewrite the file on disk with the exact same information each and every time the running-config was generated made a beginner programming mistake. CF has a lifecycle of approximately 10,000 writes. Running RANCID hourly (everybody picks their own times but we run hourly) results in CF module failure in about 14 months. It's hard to believe that something as simple as polling a router for some info can cause it have a hardware failure but in this case that's how the cookie crumbles. The fix on Cisco's end was very simple and they had the bug addressed and rolled into an interim release in about 3 weeks (far exceeding my expectations so kudos to Cisco on that). I will definitely keep in mind that possibly modifying the scripts if I ever have to write to flash regularly. Hopefully I can avoid it though. Justin ___ 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] Download manager hell and latest Windows VPN Client?
Justin M. Streiner wrote: My main argument against the download manager applet is that I hate dealing with several layers of dependency hell with Java. Does the download manager work with the Java plugin in my web browser when that plugin is based on different JRE versions? Also, there seems to be this movement by some vendors to replace simple processes (an HTTP or FTP download) with something bulkier, like a Java applet, presumably because it looks prettier. Putting my business hat on for a second, I don't understand the value proposition. I've been in situations where I had to download an IOS image with the el cheapo browser in my data phone that does not have Java support, save it to the MicroSD card and then use a card reader to transfer that to my laptop so I could fix a critical network issue. Java isn't a universal way of leveling the playing field. It's the bastion of lazy programmers and buzzword-loving PHBs. Justin ___ 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] Download manager hell and latest Windows VPN Client?
Gert Doering wrote: I really can't understand what is so hard about FTP access. Fill in a web form once, claim yes, I'm no terrorist!, and then the FTP servers put you into a he's no terrorist, may download crypto software group... This is really Internet 0.9 knowledge. Or if they are concerned about encrypted data paths they could use SFTP or FTPS (greatly prefer SFTP). I've said it before and I'll say it again. Forward-facing product pages can have all the marketing fluff to help sell the product. Once we own the product we users and customers of Cisco use the support pages. There should be absolutely no marketing fluff on any of those pages, ever. Technical supports resources should border on the verge of being called ugly. Don't waste my time as a technical admin with your marketing fluff Flash and Shockwave animations. Give me what I need so I can keep your product up and running and my management happy. If they aren't happy we aren't buying any more of your product. It's not rocket science. Justin ___ 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] Download manager hell and latest Windows VPN Client?
Brian Landers wrote: Same reason that e.g. Vandyke requires an eligibility declaration before downloading SecureCRT. Yes, but even Vandyke now lets you answer the question once and no longer have to answer it again. (Saying this as I'm downloading the SCRT 6.2.3 upgrade right now with my licensed user account...) Justin ___ 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] modular code for the 6500
harbor235 wrote: Is anyone out there using 6500 modular code? Is it stable? I have a 6509 with 720-3B, I would like to use the modualr code but also do not want instability, any thoughts/experiences would be appreciated. If you go the modular route make sure you use the Feature Navigator to compare modular and non-modular release to find the feature differences. One would think that they'd be the same or very close. They are not. I don't know why that happened either but there's probably a reason. Just make sure you look before you leap. http://www.cisco.com/go/fn/ Justin ___ 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] OSPF to ISIS migartion
jack daniels wrote: Hi all , I have got a project for an ISP ( also LDP configured ) runnning OSPF to migrate to IS-IS. I was planning to runnn dual IGP , as ospf with AD 110 and ISIS with AD 115 , OSPF will always be preffered. I was planning the challenges for migration, below are the ones which I could think of , please give your inputs on WHAT CONSIDERATIONS TO KEEP IN MIND BEFORE MIGRATION. Also request you to share some docs for migration of OSPF to ISIS 1) MEMORY/CPU utilisation 2) no. of routes in routing table and database 3) harware of the cisco devices ( 7206/12K) Vijay from AOL did such a migration. If memory serves me correctly he migrated all of AOL in 2 days. Day 1 was the migration of their test POP. Day 2 was everything in production. http://www.nanog.org/meetings/nanog29/abstracts.php?pt=Njg2Jm5hbm9nMjk=nm=nanog29 Here's another NANOG IS-IS presentation. http://www.nanog.org/meetings/nanog24/abstracts.php?pt=OTA2Jm5hbm9nMjQ=nm=nanog24 If you search NANOG's resources page you'll find several IS-IS presentations. http://www.nanog.org/resources/tutorials/ How many routes does your IGP carry today? Perhaps you should first move your customer routers into iBGP before you proceed with the IGP change. That will ensure that your IGP is small. Unless it's extremely large or your edge routers are on the verge of collapse, I wouldn't worry about the size too much. You need to make sure that IS-IS is supported on all your current platforms. There are some that you may currently utilize that don't support IS-IS at all. For example most fixed configuration Cat switches don't support it, though a few do (ME3750 for example). You may need to bump featuresets to get full IS-IS support in some cases as well so definitely make use of Cisco's Feature Navigator. Also, and I'm speaking from my own experience with a thoroughly messed up OSPF deployment to a flat L2 IS-IS deployment, when you start the migration don't stop until the migration is complete. Do not leave bits and pieces of the network unmigrated, assuming that you'll come back later and fix it. I made that mistake. I guarantee you that dualing IGPs and/or redistribution will bite you in the ass. There is nothing quite like the look on one's face when you discover that the routing between your core routers happens to get routed through a stack of EMI 3750s that is connected to both core routers. Oh yeah. Not pretty. Don't make the same mistake. Do it Vijay's way; all at once. Best of luck Justin ___ 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 TAC issues - can someone from Cisco enlighten meon this?
Daniska, Tomas wrote: (btw - asking for requeue to bru is what everybody reasonable at Cisco recommends to do - of course for europe...) Does anyone know what the equivalent would be in the states? I try my best to open cases first thing in the morning (CST) when I'm likely to get someone in the states. That said I've still had my share of communication problems to overcome. I had actually had to requeue cases twice because of communication issues. I hated to do it but I needed help and I needed it right then. I couldn't spend 3 or 4 times as much time trying to overcome that hurdle. I had a case routed to Australia a few weeks ago. I was thinking that this would be fine. As it turns out she had one of the thickest accents I've ever heard. She was not from Australia. Fortunately she went on leave part way into my case (which was good because all I ever got from her was form letter replies, nothing helpful). So I requeued on a Friday. I got an engineer from SJC. That Monday he sent me some more info and then also went on leave. So I requeued for a 3rd time. That engineer was very helpful and we managed to resolve the issue. He went on leave as the case was wrapping up. I wish I worked at Cisco and had all that PTO! :-) Steve and everyone else: when you feel like you're getting the run-around from TAC (it happens from time to time, even with the best of engineers) you need to ask for the Duty Manager. If the TAC engineer won't connect you with that person or doesn't know who it is grab another phone and call back into Cisco. Give the case dispatch person your SR and ask for the Duty Manager. Explain what you think is going off track with the case and what you feel would be the appropriate way to proceed. They should be able to help; it's their job. I've had to involve the Duty Manager a couple times on highly complex issues that involved multiple technologies. For example I'm calling in about an IPSec SPA issue in a 7600 and because it's a 7600 I got routed to the switching group. I need people from both groups and then some to effectively troubleshoot the problem. After a few hours of the switching person beating on the problem it was clear to me that he didn't have the skills needed to troubleshoot the IPSec SPA. Unfortunately he didn't want to involve the other group. I didn't have time to wait for him to come to the same realization that I had so I had the Duty Manager do it for him. The VPN Specialist that they got on the phone was extremely helpful in troubleshooting the problem. We'd have hours waiting on the switching guy to escalate the problem if I hadn't escalated the case to the duty manager. Sometimes we engineers are reluctant to ask for help. On the whole I usually have good luck when I call TAC. Here lately I haven't had as good of luck but usually it's not a problem. The engineer frequently leads me to discover what the problem is; I just needed someone to bounce ideas off of and talk the problem out. Occasionally I'll get an excellent engineer who is extremely deep in the technology at hand and he quite literally schools me. That happens far less often I'm afraid. Justin PS== Ask for the Duty Manager ___ 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] Comparison of T3 and T1 PAs?
Does anyone know of a good article, table or chart that compares the various T3 and T1 PA options? I've found a variety of docs but nothing of them giving a clear and concise list of differences between the PAs (features, chassis support, NPE support, etc). PA-T3 PA-T3+ PA-MC-T3 PA-MC-T3+ PA-MC-T3-EC PA-8T PA-MC-8DSX1 PA-MC-8T1 PA-MCX-8TE1-M I found this doc on the T1s which helped a little but not much. http://www.cisco.com/en/US/docs/interfaces_modules/port_adapters/install_upgrade/multichannel_serial/multichannel-dsi.pri_install_config/3525over.html I've found all sorts of docs on the DS3s but again nothing terribly concise or a clear-cut comparison between the different models. For example I know that the PA-MC-T3-EC can do MLPPP in hardware but not on the PA-MC-T3+. We bought the EC model for our T1 delivery service on 7200s (G2) but is it really needed? A fully-loaded 7200 with PA-MC-2T3-EC modules only puts 12 DS3s in a chassis. At full line-rate that's just shy of the throughput limit on a G1 and still half that of our G2. Now I'm sure if all our DS1s were in MLPPP bundles that this would certainly add load to the CPU but we're 25/75 CC DS1s and MLPPP bundles at this point. I could probably buy used PA-MC-T3 cards and do what I need if only I knew what the feature differences were. One thing I need to know is on which T1 PAs is MLPPP supported. I need to know if MPLS (core-facing) would be supported on a bundle of T1s. I need to know which DS3 modules support core-facing MPLS. I have an application that requires me to place a PE at a customer site to drop Internet and private WAN service and connect to it via T1s. I've contemplated ISRs and MFT VWICs and HWICs. I'm also looking at used 7200s which uses T1 PAs or a M13 and a used DS3 PA. I can come up with the 7200 solution far cheaper than the ISR and new MFT solution. Unfortunately I'm not terribly familiar with older DS1/DS3 PAs or NPEs or controller cards prior to the G1. So, does anyone know of a good comparison between the assorted DS1/DS3 PAs? Thanks Justin ___ 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] Out of order queuing
chris.f...@yahoo.ca wrote: Hello, We have a customer with load-balanced path to us. TCP throughput is affected by some out-of-order packets, and we were looking for a way to queue the interface in order to try and mitigate this. Is it possible to use any queueing mechanism to re-order packets received from this customer before transmitting them, even at the cost of latency?! I tried experimentation with CBWFQ with little to no success. Any tips? Is a different load balancing algorithm possible here? Perhaps flow-based load-balancing instead of packet-based would solve the problem. Less throughput achieved per flow but it should balance itself out when you factor in all the other flows. Plus no out-of-order packets. Justin ___ 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] Enhanced download procedure
Jay Hennigan wrote: What the #$^$...@# is going on with Cisco's download site? It completely hangs Firefox with some shopping cart java thing. And this is downright scary: http://www.west.net/~jay/images/cisco-wants-root.png Enhanced downloads, brought to you by the same people who brought us enhanced interrogation? Is there a workaround? What happened to our friend kobayashi ? I have a solution. Each and every time you want an IOS image contact your account team and ask them to send it to you. Do this every single time you need an image. When I'm upgrading code I may do this for a dozen different models in a given day. Don't forget the FPM, bootroms, etc. Annoy the living shit out of your account team and let THEM put the pressure on the fucknuts who run cisco.com. It's clear that they could care less what we customers think. Perhaps if their own coworkers bitch and moan about being made to do additional work something might change. Justin ___ 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] Enhanced download procedure
Dale W. Carder wrote: Is there a workaround? I found a workaround. I couldn't download a file due to some stupid java error, so I opened a tac case for them to give me the file. Maybe after this happens enough times and costs them real money it will get fixed. That's even better than my idea of asking your account team to get you the files. Genius! I feel a rash of network upgrades coming next week. Unfortunately I'm afraid that I may be forced to open several TAC cases to support my needs. Pity. Justin ___ 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] SP-grade Ethernet over TDM
Does anyone have any suggestions for providing Ethernet links over bonded T1s? We originally looked at Overture. They claimed that their product used standard MLPPP and interoped well with 7200s. They sent out a tech to help configure it in a lab. As it turns out they also require the use of BCP (Bridging Control Protocol). To use BCP on a 7200 step #1 is to disable IP routing (literally, 'no ip routing'). That is required to facilitate bridging VLANs over MLPPP bundles. Needless to say this wasn't an option since our router was doing more than just terminating EoTDM connections. If we had an old 7200 sitting around we probably could have pulled it off. Alternately, if we have a 7600 in that colo with DS3 SPAs we could have done the same thing without disabling routing. I'm considering replacing that 7200 with an ASR in the future so perhaps this will become possible once again down the road, but not today. I've also been looking at Adtran's Ethernet over TDM products. It looks like you have to use their Total Access 5000 at the hub and then use their NetVanta 800 series as the CPE. I don't know anything about the Total Access 5000 and can't access their documentation without an account (hard to sell the product when you won't let people access the docs beforehand). Overture's CPEs for this application are the 140 and 180 models. The price is right but the product just doesn't have a production SP-grade feel to it. Management has to be done locally. There isn't a CLI option which I would think would be a requirement for SPs wanting to either script changes or backup configurations. It just doesn't feel production grade or SP-grade by any means. It's not like their 2200 or 5000 products which are much better. I've always heard good things about Adtran and that they are Cisco-like but I've never actually used them. What I'd like to find is a device that can bond multiple DS1s together with standards-based MLPPP and then bridge that to an Ethernet interface behind it. I imagine that this would interop with our 7200s nicely. It would be nice if there was some mechanism for in-line management as well, though I'm not sure how that would work short of pulling out a DS0 for management access. Does anyone know of such a product? Does anyone know of any other ways of accomplishing that same or similar thing? I don't know of any cisco products that can do this. I could foresee a situation where I need multiple VLANs at the customer premise so the Adtran solution would likely fit in better with this potential need. Thanks Justin ___ 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] Cat 4948 NAT support
Dan Benson wrote: I have a 4948 that I was hoping to upgrade a few systems with but I am dead in the water as it seems it does not support NAT. I don't have any idea how to make it work but I do question doing NAT on a CAT to begin with. Even if it did support NAT it would be done in software. Someone firing up a simple BitTorrent client would likely be enough to bring it to its knees. It's like doing NAT on the Sup in a 65/7600. A few Mbps is enough to bring the box down. If NAT is a requirement then I'd look at doing it with a firewall or real router. Best of luck Justin ___ 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] 3750 - power AC / DC
Vikas Sharma wrote: Hi, Is there any command on 3750 (e and non-E) switches which can tell whether the power is AC or DC in the box? Like in 7206 we have sh environemnt.. Something along this line? me3750-1.dc#sh ver | i IOS Cisco IOS Software, C3750ME Software (C3750ME-I5K91-M), Version 12.2(50)SE1, RELEASE SOFTWARE (fc2) me3750-1.dc# me3750-1.dc# me3750-1.dc#sh env power POWER SUPPLY A is DC OK POWER SUPPLY B is DC OK I don't know if that's dependent on a certain software rev or newer. I tend to keep the MEs close to the most recent. Justin ___ 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 Security Advisory: TCP State Manipulation Denial ofService Vulnerabilities in Multiple Cisco Products
Antonio Soares wrote: Hello group, What actions are you taking ? What is the real risk ? http://www.cisco.com/warp/public/707/cisco-sa-20090908-tcp24.shtml If I'm reading the notes correctly, to exploit the problem the attacker must be able to complete a TCP 3-way handshake. That would imply that the attackers packets can either get through iACLs or that there are no ACLs in place. This will mainly affect those people with unsecured TCP-based services such as telnet, SSH, RSH, SCP, HTTP, and HTTPS. Routers providing WebVPN services are at risk and need to be upgraded to fix the problem since disabling WebVPN is probably not an option. Other TCP services like BGP and LDP shouldn't be affected unless one of your configured neighbors is going to exploit the vulnerability. If you can't trust your own equipment or your peers to not exploit vulnerabilities on your equipment So the hundreds of thousands of under-managed IOS devices out there that have the default config with TCP services like HTTP and telnet enabled are going to suffer. All the more reason for Cisco to change the default configuration to default to having all services disabled out of the box. Make the admin turn on features themselves that compromise their security. No reason to compromise their security for them. Fixing this would require implementing security basics such as creating a VTY ACL, creating a HTTP/HTTPS ACL or disabling it altogether if it's not used, implementing CoPP, iACLs, etc. Usual stuff. It looks like I'll be doing a round of upgrades in November. It's time anyway. Justin ___ 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] CALEA was Re: OT - Dark Fiber
Scott Granados wrote: Why does anyone comply with CALEA? Especially after the abuses of the last 8 years and probably a lot farther back than that? I've been reading about the requirements and the idea that ISPs cooperate with law enforcement really makes me uneasy on a civil liberties basis. Does Uncle Sam scare tactic people in to compliance? There's just something about making things easier for the NSA and any number of alphabet soup agencies that strikes me as unamerican (to use their own phrase against them) and wrong. Or was it created simply to create a new space for security products and C, J and the others were really good at lobbying? Since it doesn't require the ISP to break open encrypted traffic it almost makes me think a public key system that lets the end user encrypt everything from phone to television with their own keys makes some sense so there's nothing left in the clear for entertaining the James Bond crowd! Probably not practical at all but this thread just convinced me not to use split tunneling.;) Well, probably because it's REQUIRED BY LAW. Not complying is a felony, not just a simple civil offense. They go after company officers. Try convincing your company officers not to do it; see if they want to take the chance. All SPs were required to officially respond to the FTC with a plan for how they were going to make their network CALEA ready. Not replying was not an option. Politics of the last administration aside, it's not a bad thing that SPs be able to assist law enforcement. Telcos have been required to do so for longer than most people on this list have been alive. As voice traffic moves off the PSTN to the Internet logically CALEA has to follow. Does that mean that the intelligence agencies will follow the letter of the law and not abuse it? Certainly not. The FBI has already shown that they will abuse it with National Security Letters. That will happen under any administration though. Hopefully it will be reduced under the present administration and the process will be tuned and refined. Intelligence agencies (IAs) will always want more data and consumers and their SPs will always want to give up less. The way we help limit the IAs is through the political processes, not through non-compliance. An individual's civil disobedience seldom works. Try non-compliance with the tax man and see how far you get. Justin CALEA-compliant since 2007 ___ 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] Options for customer prefix injection into iBGP at the edge
I'm soliciting suggestions on the pros and cons on the assortment of ways to inject customer routes into iBGP at the edge. One could simply reference prefix-lists in the BGP config on a per-neighbor basis (or peer-group). The downside to this is that prefix-lists can't haven't inline comments for storing information about the individual prefixes. As the prefixes on the edge grow I would think that admin overhead and potential for errors would grow as well. I could reference route-maps in the BGP config as well (per neighbor/peer-group). I'm doing this today, matching against a prefix-list to get my routes. The upside is I add a new sequence to the route-map per customer and create a uniquely-named prefix-list per customer. This of course requires more config and more potential typos but makes changes as customers come and go much more clearcut (ie, there is no question which prefixes belong to which customer). Another upside is that I can also put specific communities on prefixes with a route-map. I'm not doing this today but I plan to in the future as my BGP community design progresses. A third option is redistributing statics into BGP. This gives me the opportunity to tag specific prefixes and filter them with a route-map so I only redistribute the prefixes that I want redistributed. I can also name static routes. I need a static route anyway to tack up the route for outbound advertisement and to prevent loops. The downside is that I hate using redistribution. I'm not a big fan of it. I've been bit too many times to consider redistribution a good method of doing anything. It will also result in higher CPU load as the RIB is frequently parsed for statics and processed with the route-map if I'm not mistaken. Correct? A fourth option would be to use distribute-lists. I can use remarks to label my individual prefixes in the ACL which is good but I end up with one large distribute-list ACL for all my customer prefixes. That means any errors could affect all customers at once. I also don't end up using route-maps so I don't get to set communities on advertised prefixes. And finally I could use a combination of any of the above to accomplish my goals. What methods do my SP colleagues prefer to use when managing the injection of customer routes into iBGP? I'm open to suggestions. I've tried both of the first 2 options and lean towards the 2nd. It's time I get the remaining customer routes out of the IGP but unfortunately I can't see far enough ahead to decide which method is best. I can't help but to think that there must be a better way to accomplish my goals without increasing my work load too much and without increasing the likelihood of making major mistakes. Thanks Justin ___ 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] do i *need* DFCs on the 6500?
You eluded to one of my strongest selling points on DFCs though I don't think you made that particular connection yet. DFCs offload QoS to the LC as you said. That also means that CoPP is also handled in hardware if you have DFCs in place since it requires MLS QoS on that platform. Ie, if your 6500/7600 is going to be publicly-accessible on the Internet in any capacity and you want it to be able to use CoPP to withstand a targeted DoS attack then DFCs are not optional, they're critical. The others on the list can probably give you much more in-depth views on the other aspects of the card but I found CoPP to be a big enough selling point. It wouldn't be good is a simple little DoS attack took down my core 7600s. Justin Alan Buxey wrote: hi, okay, from the background of I know what the DFC is and how it operates etc... i know I want them - however, I need to justify the upgrade/part cost to sort out a couple of 6500's. in some of our 6500's, the 10G blades have DFCs already...but several 6724's dont (they just have CFC). ...as i said, I want them, but need to get some management/funding buy-in - and they dont want the 'what it does' information - they want some hard and fast facts that Cisco dont sem to want to tell me . so, the question is 1) is there any way of showing the sup720 strain/utilisation...particularly is there a way of showing DFC usage on the blades where we have them? 2) it offloads IPv6 and QoS - we're into both of those (and more so over the next year) - any particular insights into QoS performance/issues without DFC ? any throughput figures for IPv6 ? (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps per blade with DFC) ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) alan ___ 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] Multiple power supply failures. Advise needed
Michael Ulitskiy wrote: As for grounding lug I would gladly add it to 6500 chassis if that was the only problem. Running it to every piece of equipment which count about 50 pieces at the moment wouldn't be fun at all... Doh... I hate to say it, but the devices shouldn't have gone into production if the installation wasn't complete. Proper grounding is part of a correct installation. I can't count the number of network engineers I've worked with over the years that did absolutely no grounding whatsoever. I can name 1 engineer that will never turn up a device without proper grounding; me. Not to beat a dead horse but perhaps a newbie reading the list might take this to heart... Justin ___ 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] Multiple power supply failures. Advise needed
Michael Ulitskiy wrote: I forgot to mention that after the 1st wave of failures we have installed tripp lite surge protectors on all circuits. These last failures happened with tripp lites installed, so it shouldn't be transients. The events are random. Happened during daytime, night-time, weekdays, weekend. I can't see any pattern. Moving out is a last recourse which I hate to think about, but sure is an option that's being considered. Just been there half a year ago. Here's a little secret about surge protectors. Most of them flat out suck. Most of them are of no use unless the surge is extremely large such as what you'd expect from a lightning strike. In reality a surge protector should clamp down at 150v or less. I saw a demo once of several different brands of surge protectors that we supplied to a distributor of another brand. Most of the ones we'd supplied had apparently already been hit and had blown the pot. A few were actually good. 200+ volts passing through them and they still hadn't tripped. The APC actually melted in the demo (which explained the concrete board they laid on our table under the surge strips). Then the reseller brouht out a Panamax surge protector. He started walking up the voltage from 110. At around 140v it tripped. Walked it back down and the surge strip came back on. It doesn't fry itself tripping like most of the other brands do. Then he walked it down from 110v. At around 90v it tripped as well. It cuts off for under-voltage which is a major problem in the rural areas I come from. http://www.panamax.com/Products/Floor-Models/M8-EX.aspx I would highly recommend Panamax brand surge protectors to anyone. Not all of them cut off for under-voltage so look at the specs carefully. The one I linked to does of course. It's worth the slight premium to buy the good stuff. I don't buy anything else anymore. We didn't test Tripp Lite so I don't know how they stack up. For $40 you can be sure though with a good Panamax. One thing that you might consider is placing a decent manageable UPS in your rack. You don't have to put a load on it. Use it to monitor the line condition for irregularities. Manageable UPSs tend to be much cheaper than commercial power quality monitoring equipment. With that data in hand you can approach your colo provider. Justin ___ 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] Multiple power supply failures. Advise needed
Unless you scrapped the paint off of every joint between the chassis through the mounting brackets to the rack then you aren't guaranteed a good connection. That's why most telco screw kits come with the star washer to help scrap the paint of the rack and why most telco equipment frames and mounting kits are a non-painted alloy. Data equipment isn't generally made to the same standards. So for example if you rack up a 3750 you're using non-painted mounting brackets on a painted 2-post. The chassis is also painted so you most likely aren't making a connection between the chassis and the bracket and thus not the 2-post. The ground in the power plane should never be connected within the chassis to the chassis itself. The power plane should never share anything common with the chassis. The chassis should always be grounded separately. Now beyond the panel at the site ground they'll likely meet up again but within the powered equipment they should never touch. Ie, the ground conductor in the L5-20R that your colo provider dropped in your cage should not internally connect to the chassis of the device. The electronics within the device should be insulated from the chassis and the chassis should have an external ground connection that you connect either to the frame or to a ground bar on the frame. Depending on the equipment (thinking telco for a minute) the equipment is sometimes insulated from the frame and connects to a ground bar that is also insulated from the frame as well. There are a lot of telco standards out there that are meant for specific applications. Bottom line, always ground the chassis with the supplied hardware either to a grounded frame or to a ground bar within the frame that goes back to a site ground bar. Not all manufacturers adhere to those standards though... Justin Michael Ulitskiy wrote: Sure, but what the proper grounding is? Does it mean that I have to run a dedicated grounding wire to every piece of equipment? The racks are properly grounded (according to provider) and every server is screwed to them. The power is provided via NEMA L5-20P twisted lock connecter with proper grounding (according to provider). There I currently have tripp lites followed by managed APC PDUs. All equipment is plugged in into APC grounded outlet. Does it not qualify for proper grounding? I also personally went there with a voltmeter and check for voltage between metal parts per Seth Mattinen suggestion and I found 0 voltage. This may sound silly, but I'm taking any chances. What else I can do? ___ 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 QoS
Randy McAnally wrote: We got minor packet loss and noticeably slower speeds off the bat with 'mls qos' enabled with all defaults, even with only 40-50% interface utilization. In fact it took a while to figure it out. Be very careful when you enable it if even minor packet loss will be an issue. I'm neck deep in a similar configuration. I'm hoping that I don't run into similar issues. Justin ___ 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] BFD on 7600
MKS wrote: Can you share your experience with BFD on the 7600 platform and sw release? I use it and like it. However beginning with SRB2 Cisco removed support for running BFD on SVIs. To date there is no workaround and the feature hasn't been added back to SR. Otherwise it works fine in my experience. The document hints that BFD runs in hardware on the following modules,but does not explicitly say so. Can someone clarify this for me? To the best of my knowledge BFD is 100% software driven. Generating echo requests, processing those requests, receiving the echo replies and processing them aren't things that ASICs are suited for I don't believe. I could be mistaken and someone else may chime in with more detailed knowledge, but I wouldn't expect something like BFD to be handled in hardware. That's not necessarily a reason to not use BFD. BFD is meant to be lightweight. That may be a reason not to run several thousand instances of it on a single router of course... Justin ___ 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] Order of Operations for processing a packet (ingress and egress)
Does anyone have any good links to an order of operations for what happens in what order on the assorted types of Cisco interfaces in both the ingress and egress directions? I found one that touchs on the QoS order of operations: http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080160fc1.shtml I'm interested in fairly detailed things like at what point does a vanilla IP packet go through the MPLS label imposition process (on ingress as it's received or egress onto an MPLS-enabled interface). Or at what point is a packet encapsulated on a GRE interface. I'm looking for a reference that talks about router ports, WAN LAN ports on a Cat routing chassis like the 7600, basic LAN switchports on Cat switches, etc. I've never seen a doc that put it all together and I seldom come across docs that even talk about small portions of the order of operations. Any references would be much appreciated. Thanks Justin ___ 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] Question for PA OC3 guru?
Security Team wrote: I have a telco that wants to hand me an OC3 on which there will be 3 DS3's, all doing different things. One will be a clear channel (pt-pt) DS3, one will contain 28 T1's in the DS1 time slots of the DS3, and one will be unused for the time being. CJ, I'm going to agree with those that proposed the external OC3 mux. It really is your best bet. It also gives you the most long-term options. The Adtran OPTI-3 mux will be able to do the heavy lifting on your OC3. http://www.adtran.com/web/page/portal/Adtran/product/1184003L1/270 It supports protection too so you can insist that your provider give you a protected OC3 if they want to cram an OC3 down your throat. With that mux you have the option to terminating the CC DS3 and channelized DS3 on different devices if you so choose (now or in the future). That really is the best option. The other thing you might consider is replacing or adding to your router collection and getting an ASR (or other router that supports SPAs like the 7600). The ASR has a channelized OC3 module that could do what you want. List on the dual channelized DS3 SPA is $30k. List on the channelized OC3 is only $36k. The channelized quad-DS3 is $60k. The OC3 is a good deal on that platform if you don't mind buying the external OC3 mux. That's what I'll be doing in the future. I'm replacing my Widebanks with Adtran MX2820 M13s. Then I'm going to mux them with the OPTI-3 and terminate it in an ASR with the channelized OC3 SPA. My $.02 Justin ___ 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] Feedback on Bug Toolkit (BTK), IOS Software Download Planner, etc...
Rodney, Do you think you might be able to gain the ear of someone responsible for the CSCC? I've had ongoing issues with it ever since it was introduced. I raised those concerns several times and they were never resolved. Now that SCC has been completely deleted and replaced with CSCC I have no way to work with my contracts. I tried to use it again today and it listed dozens upon dozens of devices that I don't own, never have. It also didn't list dozen upon dozens of devices that I do own and are under contract. Very flaky Another great pair of ears to locate would be whomever is responsible for the DCT Dynamic Config Tool (DN) that let's you build device BoMs and the Feature Navigator (FN). I have feature requests for both and a sanity request for the DCT. Thanks Justin Rodney Dunn wrote: Ok...the first list is this. Use Wilson Shiu (wshiu) ws...@cisco.com as the contact for: Bitswapping Tool Bug Tool Kit Cisco Notification System Command Lookup Tool Error Message Decoder File Exchange IP Subnet Calculator MYTECH Support Output Interpreter Product Alert Tool SNMP Object Navigator Special File Access TAC Case Connection TSRT Voice Codec Bandwidth Calculator I'm getting the contact for the Software Center stuff and will report back. Rodney Rodney Dunn wrote: I'm getting that for clarity. I'll respond back. Tony Varriale wrote: Rodney, Do you have an official list of items/tools that feedback can be provided on? Or, should we ping Wilson? tv - Original Message - From: Rodney Dunn rod...@cisco.com To: cisco-nsp@puck.nether.net Sent: Thursday, August 13, 2009 9:01 AM Subject: [c-nsp] Feedback on Bug Toolkit (BTK), IOS Software Download Planner,etc... I got involved through a few channels and encouraged the teams responsible for some of the Cisco.com Support tools to leverage this forum directly for feedback. They were very interested in the idea. Can those of you that care enough to give direct feedback based on the past threads around IOS Upgrade Planner, Bug Toolkit, etc. please take a few minutes and compose an email directly to: Wilson Shiu (wshiu) ws...@cisco.com He is the point of contact for feedback. They are eager to listen so now is a good time to get involved. I encourage you guys to take advantage of this. Thanks Rodney ___ 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/ ___ 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] EEM applets and conditional statements
I'm having trouble figuring out how to use the conditional capabilities of EEM applets to do something fairly simple. I'd like to check for DHCP conflicts on a schedule and if any exist I'd like to generate a syslog message and send an email. What I can't figure out how to do is parse the output of 'sh ip dh con' and if then perform an action if there are any conflicts (ie, more than just the single header line in the output). I've gone through some of the EEM community scripts but they all seem to be full blown TCL scripts. I'm thinking that I can handle this with a simple applet. The applets have if, for, and while capabilities but I haven't figured out how to apply them to parsing command output? Any suggestions or pointers? Example scripts that demonstrate how to use the EEM logic capabilities would be fine too. I can build off that to do what I need. Thanks Justin ___ 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] Policing on a 3560
I'm getting pushback from TAC on this. They're telling me that using class-default is unsupported and they pointed me to the config guide for the platform as proof: http://www.cisco.com/en/US/partner/docs/switches/metro/catalyst3750m/software/release/12.2_50_se/configuration/guide/swuncli.html I haven't gotten an actual answer from my engineer yet on what I'm doing wrong. I thought policing was simple and that this would be a simple fix. Justin Sigurbjörn Birkir Lárusson wrote: Why not use class-default? Kind regards, Sibbi ___ 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] Policing on a 3560
I'm having a little trouble doing something that should be simple. I'm using a 3560 as a CPE to break up multiple services and bind them to unique switchports. I don't normally use 3560s for this. The port in question is for a 10Mbp PtP with no SLA across our backbone. What I currently have is apparently not doing anything and I fail to see the flaw in my logic: class-map match-all ALL ! ! policy-map Re-color-BE description Police to 10Mbps CIR - Re-color ALL to BE class ALL police 1000 8000 exceed-action drop set ip dscp default This is my QoS trust boundary so I'm re-coloring to 0 and setting muy CIR to 10Mbps. The switch wouldn't let me define 'match any' in the class-map. I suspect that I'm not matching anything because of that. I want to match anything coming in that interface and police it to the CIR and drop everything else. I must be missing something but I'm not sure what it is. Is there something unique about this platform? The IOS is 12.2(50)SE1. Thanks Justin ___ 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] BFD + BGP on 7600 SRC or SRD
The response I got when I asked was that it was an unintended feature. That may be the case but it was working just fine. I wish they'd add the feature. It's really important for 7600s that serve access functions along with core/distribution functions. The only other solution is to burn additional ports to separate the 1Q trunk between pairs of chassis for access VLANs (running a FHRP across the pair of 7600s) and a separate pair of interfaces for the L3 relationship between the chassis. Justin Dean Smith wrote: So I can only have BFD + eBGP if its on a physical port ? Does the same apply to SVI + OSPF ? Any known reason for this limitiation ? (Waiting for my test 7606s to arrive!) Dean - Original Message - From: Justin Shore jus...@justinshore.com To: Walter Keen walter.k...@rainierconnect.net Cc: cisco-nsp@puck.nether.net Sent: Thursday, July 30, 2009 4:27 AM Subject: Re: [c-nsp] BFD + BGP on 7600 SRC or SRD Walter Keen wrote: Hi, I'm looking at using BFD with BGP on 7600's (rsp720's and sup720-3b) and was wondering if there were any known issues with certain IOS's in the SRC or SRD train. BFD support for SVIs was removed with SRB2 if that's something that you think you'll need. Justin ___ 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/ __ NOD32 4289 (20090729) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ 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] BFD + BGP on 7600 SRC or SRD
Walter Keen wrote: Hi, I'm looking at using BFD with BGP on 7600's (rsp720's and sup720-3b) and was wondering if there were any known issues with certain IOS's in the SRC or SRD train. BFD support for SVIs was removed with SRB2 if that's something that you think you'll need. Justin ___ 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 AS5300 Shuts Down Abruptly
Jon Lewis wrote: If by shut down, you mean all the lights go out, fans stop, etc., then it sounds like you may have a power supply gone bad. If you mean it stops working, but lights are on, fans are spinning, just the software's locked up, then it be all sorts of things. If it's doing either of things with ethernet and PRIs disconnected, it's almost certainly a hardware/power issue...and not a software one. You're probably going to have to replace the unit. I took down a 5300 that had been running for several years to move it out of the basement under our CO to the actual CO itself. I hate doing that because that's when most hardware fails. Once I had it reracked and cabled again I tried to power it on to no avail. It would come on but would more or less sit there dumb as a post. Ultimately I determined that the board with the 8x PRI interfaces had gone bad (I forget the 5300 terminology and LC names; my therapist has done a good job of repressing those memories). New LCs couldn't be purchased any more. Official refurbs weren't availble. SmartNets could no longer be purchased either. In the end I spent $34 and bought a 4x PRI replacement LC on eBay. The 5300 has been working ever since. Our dialup numbers have dwindled so low since that box was maxxed out (2 5300s were maxed out at that POP back in the days) that no one even noticed the loss of modem capacity. I almost wish that the box had completely baked itself so I could justify killing off the service. I dread getting a call about a dialup problem. You have dialup and you live in town? Down the street from the CO? #$%%^* Justin ___ 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] Humor: Cisco announces end of BGP
Hank Nussbacher wrote: I just got this product alert from Cisco: From: cisconotificationserv...@cisco.com To: h...@efes.iucc.ac.il Subject: Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT Cisco Notification Service Alert: Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT End-of-Sale and End-of-Life Announcements-Border Gateway Protocol (BGP)-07/27/2009 08:44 GMT-07/28/2009 07:35 GMT What exactly does Cisco have planned as a replacement? :-) -Hank Full tables in IS-IS of course! ___ 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] Humor: Cisco announces end of BGP
According to a Pannaway SE who visited us a few years ago, he'd seen SPs many times our size who used static routes for everything. He said we weren't big enough to need a routing protocol. Of course he also said that our pipes weren't saturated so we didn't need QoS and that IPv6 was just a fad and would never be adopted in the US. *sigh* Ivan Pepelnjak wrote: Gentlemen, you forgot about IDRP (http://www.javvin.com/protocolIDRP.html). You can already transport IPv4 and IPv6 over CLNS, this is the next logical step :D ___ 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 Catalyst 2960PD-8TT-L
Dracul wrote: Hi All, I can't seem to find more information of this model in the datasheets. Can anyone confirm if this switch (Cisco Catalyst 2960PD-8TT-L) has CLI and SNMP? The only Cisco-branded switches in the product line that won't have have a CLI are the Express switches. This of course means that the LinkSys switches won't have a Cisco CLI (if they have one at all which I doubt). The Cat Express switches are now EoL (EoL the day before the announcement was made; nice, eh?). The replacements are either the Linksys Business switches, or for the larger Express switches, a 2960. Justin ___ 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 Catalyst 2960PD-8TT-L
Nick Hilliard wrote: On 27/07/2009 17:39, Justin Shore wrote: The only Cisco-branded switches in the product line that won't have have a CLI are the Express switches. This of course means that the LinkSys switches won't have a Cisco CLI (if they have one at all which I doubt). http://lcli.wikidot.com/ Interesting. So they don't have a Cisco CLI but they have an otherwise limited CLI if you know the tricks to get into it. I don't think that will be helpful in RANCID though. I don't think I can make it jump through all the hoops necessary to get logged in or pass meta control characters. Interesting nonetheless though. Thanks Justin ___ 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] 7206 NPE-G2 crash caused by a bouncing DS1
Has anyone out there experienced any 7206 crashes when they have a bouncing DS1 on a PA-MC-2T3-EC? We've had 2 crashes in about 3 weeks time. They've both generated crashinfo files. The first auto-rebooted itself. Yesterday's did not. System returned to ROM by error - a SegV exception, PC 0x349404 at 16:27:25 UTC Tue Jul 21 2009 The G2 is running 12.4(24)T. I'm working with TAC who's escalated it to the developers. They're thinking that it's an IOS bug that's being set off when a DS1 flaps (though not every time of course). I don't know if severe and lengthy flapping is necessary or if a single instance could happen at just the right time to make it crash. Both times though a DS1 was bouncing every second or two and had been for days. Both DS1s were members of MLPPP bundles at the time too. Has anyone else experiences similar issues? Thanks Justin ___ 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] 7206 NPE-G2 crash caused by a bouncing DS1
The MLPPP interface was part of a VRF, had an IP and had uRPF configured. Other than that no L3 IGPs. I do use BGP dampening but I'm distributing this route into iBGP. MP-BGP to carry the MPLS/VPN vpnv4 routes but not using BGP for ip4 address-family routes. I should also mention that there are 2 DS1 in the bundle and that the other DS1 did not go down (until the crash) to the best of my knowledge. So the bundle should have stayed up even though one DS1 was flapping in the breeze. Justin Brad Hedlund wrote: Justin, Just curious, was the DS1 participating in a routing protocol, and if so did you have IP event dampening and/or BGP dampening configured? ___ 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 MTU / Jumbo frames etc.
Brandon Applegate wrote: I think I figured (part of) this out. Packets to the router != packets through the router. Trying to ping something on the far side with packet size of 9188/9216 gets me the expected icmp frag @ 9212. I still think I'm going to proclaim that jumbo == 9000 to make it easier for server / storage guys to remember anyway :) I used to use 9216 across my network until I ran into some devices that couldn't do 9216. I forget what they were but I ended up lowering it all to 9000 after that. I don't expect to ever send frames that large anyhow but I wanted to lay the groundwork for it early. Justin ___ 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] edge router BGP
Gert Doering wrote: Hi, On Thu, Jul 16, 2009 at 04:20:50PM -0500, Justin Shore wrote: It has 5x the backplane to boot plus it's hardware forwarding. The only real downside IMHO is that the unit uses SPAs which require SmartNets per SPA (per license and per a lot of other things for that matter too). Uh. Could you elaborate on that? Especially the per-license and a lot of other things bit? We have no ASR1k yet, but if something like the ES20 extra license for IPv6 *per ES20 card* is going to come back, this would be a strong reason to finally go to the Vendor J camp. You can see the prices in the Dynamic Config Tool on cisco.com when you build an ASR. I just built a 1002 in the DCT as an example. I added a couple SPAs and licenses. On the summary page there are SmartNet line items for: ESP Chassis IOS SW Redundancy Right-to-Use License Crypto Right-to-Use License Each SPA And the IOS itself So for a $95k chassis @ list I have $5800 in SmartNets (8x5xNBD) @ list per year. Fire away... Justin ___ 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] edge router BGP
Mark Tinka wrote: I was thinking more, ASR1000 series. Will do wire rate, has a large enough control plane to handle multiple full tables to customers, is the natural progression from the 7200-VXR platform, e.t.c. I second (third?) the ASR 1002 suggestion. @ list price the 5Gbps ASR 1002 is only a few $k more than the 7206VXR w/ the NPE-G2 or the 7201. It has 5x the backplane to boot plus it's hardware forwarding. The only real downside IMHO is that the unit uses SPAs which require SmartNets per SPA (per license and per a lot of other things for that matter too). Still it's a much better box for a little bit more up front. I plan on replacing my 7206 border routers with ASR 1002 or 1004s when the time comes. Justin ___ 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] SNMP OID to see if a Tn interface is looped up?
Does anyone happen to know if there's an SNMP OID that one can query to see if a standalone T1, T1 channelized inside of a T3 or OC3, or a high-capacity TDM interfaces like a T3 is looped up at the CSU? I've had an occasion where a T1 was left looped up by the local-loop provider that I didn't discover until troubleshooting the downed circuit the next day. I'd like that type of event to be a warning-level event in Nagios (that gets made critical after a handful of hours in that state). All I have to work with right now is down-when-looped which makes the NMS report that there's a full blown problem when in fact the interface is merely looped up for testing. This data is reachable via show commands but I haven't had any luck with SNMP OIDs at this point. It would take a hefty script to pull out loopback data from the controllers I imagine. My Google-fu is failing me on this one. Anyone have any SNMP suggestions? Perhaps I can generate a SNMP trap for such an event. I'm sure I'm not the only one worried about this or who's already faced it. I don't want to be the one who accidentally forgot to loop down a CSU when my testing was complete. This isn't really limited to TDM circuits now that there is support for Ethernet loopbacks as well (though I'd like to think that it would be harder to forget about Ethernet loopbacks than remotely-requested TDM loopbacks). Thanks Justin ___ 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] SNMP OID to see if a Tn interface is looped up?
Ryan West wrote: Justin, Give this a shot: http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=enstep=2mibName=CISCO-ICSUDSU-MIB That MIB contains values for different loop codes. Ryan, That looks like a very useful MIB. I'll give that a try. I looked at the source of the check_snmp_int.pl script for Nagios as well and noticed that it was built to handle 3 response codes: up, down and testing. On a hunch I looped up an unused T1 on a T3 controller and hit it with a snmpwalk. Sure enough it listed the looped interface as testing: IF-MIB::ifOperStatus.28 = INTEGER: testing(3) check_snmp_int.pl also correctly detected the situation: Serial1/0/10:0:TESTING: 1 int NOK : CRITICAL So it looks like that plugin will do what I need if I can figure out how to make it only give a warning if the interface is in testing and not a critical alarm (warning for say 1hr; then escalate it send our alerts). I want it to warn with no email for about an hour. Then escalate it and send our the alerts. Should be doable. Thanks Justin ___ 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] Give Cisco your feedback on the new download experience at tacwebsur...@cisco.com (was: several heart-felt flames regarding the mess that is the Cisco.com download experience)
I received this message from Cisco yesterday. I found the timing to be rather ironic. I've munged the survey URL; I'm going to fill that out. I would encourage EVERYONE to participate in this process by sending a letter to tacwebsur...@cisco.com to let them know how they really feel about the quality of download experience that can be had on cisco.com. Justin Dear Justin, Last Friday, you visited Cisco Systems' on-line Technical Support Documentation Website. Our records show that you accessed the following: tools.cisco.com/support/downloads/go/DownloadImage.x Customer loyalty is Cisco's top priority. To ensure that we continually measure our performance in meeting your needs, we have partnered with Walker Information to conduct a survey regarding our Technical Support Documentation Website on Cisco.com: http://www.cisco.com/techsupport. Please accept my invitation to participate in this survey by visiting this URL http://survey.walkerinfo.com/ If you are unable to click on the link, it can be copied and pasted into your browser. This is a newly updated short survey that takes about 3 minutes to complete. I ask that you provide honest feedback, not only on our performance to date, but also on how we can better meet your needs going forward. Your valuable input will help establish continued improvement of the Technical Support Documentation Website. If you have any questions about this study, please feel free to email your comments or requests to tacwebsur...@cisco.com . If you have any difficulties gaining access to the survey, please contact supp...@walkerinfo.com for technical assistance. On behalf of Cisco Systems, thank you for being our customer and for participating in this survey. Sincerely, Julie Larsen Sr. Director, Technical Support Website Team Cisco Systems, Inc. To remove from all future surveys conducted by Walker Information, follow this link: http://survey.walkerinfo.com/remove.cfm?code= If you have any questions, please send an email to supp...@walkerinfo.com. Walker Information, Inc. 301 Pennsylvania Parkway Indianapolis, IN 46280 United States ___ 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] Give Cisco your feedback on the new download experience at tacwebsur...@cisco.com
You might Google for a list of negative adjectives to keep on hand for the call. If you can't find a list online I'm sure you know some people who can help contribute to one just for this occasion. Justin Jared Mauch wrote: I'm having a call with some people in a few minutes, I will share what is feasible to share once it's completed. - Jared ___ 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] Disallowing sw tru all vlan X w/o add or remove (was: Maximum spannig tree instances)
Gert Doering wrote: Now: what happens if the TACACS server is unavailable? The way we currently run the shop is there is a local username configured as fallback if TACACS doesn't respond - and people know that they get slapped if they use this user without good reason. How would command authorization work in that case? I think it would once again require the mighty hand of the Gert to slap his underling back into line. I believe you can create an authorization list locally that simply permits all commands. Then set that list as the backup to tacacs in the AAA config. Like you said before, this is the backup plan in case the world is coming to an end. I don't do AAA authorization yet but I do use TACACS and I fall back to a local user for authentication. It's very handy. That userid passwd don't stray far from my hands. I wouldn't make it something that's known to everyone though. It would be a very select list. Justin ___ 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] Baseline CoPP policies?
One thing that the documentation always lacks is sufficient info on handling IS-IS with CoPP. The inability of IOS to match IS-IS traffic without using class-default is a major problem. Of all the people that would need CoPP (people with publicly exposed routers like SPs) one would think that IS-IS support for CoPP would be a big deal. Is there a specific dev group within Cisco that I can point my account team to that would be the one to consider my feature request. Justin Siva Valliappan wrote: Hi Drew, have you looked at the following docs: http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html and http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html ___ 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] PIX/ASA Change Control
Like Ryan said, clogin takes care of it. The only problem I've run into is with v8.2 of the ASA code. Some nimrod programmer thought it would be a good idea to store config related to the new core dump option in v8.2 in a text file on the flash volume. The programmer also decided to update this file every time 'sh run' is executed. So every time RANCID would run against at v8.2 ASA it would execute 'sh run' (write term actually) which would cause the text file to be regenrated (though nothing in the file changed) with a new timestamp; then when RANCID extracted the contents of 'dir all' it would alert you that a timestamp had changed on a file on the flash volume. Genius! I worked with TAC to get that identified as a bug. Earlier this week my TAC engineer posted a interim release that is supposed to fix the issue. I haven't had a chance to apply it just yet. If anyone wants the BugID so you can request the fixed image from TAC let me know; it hasn't been rolled into a publicly-accessible interim release yet. Other than that RANCID is fantastic. I unleash RANCID on my equipment once an hour. In a way it's also like a TripWire check for my network devices. If something changes that I know I didn't change then I have cause to investigate. This actually led me to discover a compromised router about 3 years ago. Someone set up a GRE tunnel out of a router I'd recently taken control over (but hadn't migrated AAA yet or hardened to my standards). The tunnel hit a server in Korea. They pointed several statics across the tunnel including some that covered Paypal and Amazon. I'm assuming they were trying to steal credit card info. I found the RANCID diff emails the next morning when I got to work and had the router cleaned up inside of an hour. RANCID has been an absolute life saver for me several dozen times. Justin Ryan West wrote: It handles it fine. This is basically all you have to do to get it work with ASA/PIXen: add user customer-fw1 admin add password customer-fw1 mypasswordmypassword add autoenable customer-fw1 0 add method customer-fw1 ssh telnet We did a very minor tweak to allow netscreen's to be backed up and parsed as well and configured cvsweb to manage the diffs / revision control. -ryan -Original Message- From: a.l.m.bu...@lboro.ac.uk [mailto:a.l.m.bu...@lboro.ac.uk] Sent: Thursday, June 25, 2009 12:39 PM To: Sigurbjörn Birkir Lárusson Cc: Ryan West; William; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] PIX/ASA Change Control hi, regarding RANCID and Cisco ASAs - are there common scripts etc for logging/scraping such devices as there are for cisco (clogin), foundry (flogin) etc ___ 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] Sup720 vs RSP720 - Difference?
Tom Lanyon wrote: Does anyone know how the newer architecture of the ASR1k ESP compares to a 7200 NPE-G2 in regards to 'all services enabled' performance? If I recall previous discussions on this list, it's fairly easy to overload the CPU on the NPE when you start enabling QoS, NetFlow, WCCP, FPM, etc. Do the ASR1k ESPs do this any better? Since the ASR does most things in hardware, most of the basic features shouldn't hit the RP unless something is configured wrong. Normal QoS and NetFlow shouldn't be a strain on the RP (except for Netflow exporting). I don't know about the more unusual features like WCCP. You would probably fair far better on the ASR than the 7600 or 7200 for those I imagine. That's my limited understanding of the ASR though. I'm looking at them as a replacement/upgrade for a few 7200s on our network. Justin ___ 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] BGP quandry
Peter Rathlev wrote: Core #2 doesn't have route-reflector-client configured towards the new router, so it only sends it's own prefixes and prefixes from any RR clients of it's own. That seems to make sense to me too. It does now that I've thought about it. With iBGP not forwarding on updates it learns from other iBGP speakers, the only way I was receiving the routes in the existing environment was with the RR config. That makes sense. So now I'm building a full mesh between all the speakers. I haven't done a great deal of RR work so I always have to stop and research RRs when I work with them. I was pretty sure that I couldn't pull an eBGP confederation speaker off of the RR client which is why I was pushing everything back towards the full mesh. AFAIK you always have to activate the specific peers in the VPNv4 configuration for VPNv4 functionality. I.e. : VPNv4 and IPv4 mixes fine, but the activation is seperated so you can run some IPv4 only peers, some VPNv4 only peers and some mixed peers. That's good to know. I assumed that the I could make the change en mass by using the peer-group but adding individual activations will work too. That's probably a good thing so I can be more flexible with my peer-group use. Thanks for the input Justin ___ 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] BGP quandry
I'm scratching my head on a BGP problem. I have a pair of core routers and a pair of distribution routers in our data center. The DC routers each have a single connection to the core routers (1 connection per pair). Previously the DC routers were configured as route-reflector clients with a route-map stripping out all ipv4 routes but the default. The links are MPLS-enabled and I have production MPLS/VPNs on the links currently that are working fine. It's fairly straightforward. Upstream of the core routers are a pair of border routers. The border and core routers are in a full mesh. Now I'm trying to hang a new router off of one of the data center routers and extend our BGP environment to it. I've configured it to be part of a confederation (that router will ultimately have a direct Internet peer and will need full routes). I'm currently hopping over the DC router and going straight to a core router for that eBGP confederation connection. However I now need to access a MPLS/VPN from the new router in our data center. So it basically looks like this: A B |\ /| | \ / | | /\ | | / \| C-D | | E F | G A Border 1 B Border 2 C Core 1 D Core 2 E DC 1 F DC 2 G New Router A-D are currently a full mesh and I'd like to extend that to A-F. G is the beginning of a confederation and new AS. I'm taking the opportunity to go back and eliminate the RR design from the DC and make those 2 routers part of the full mesh with the core and border routers. I've removed the RR config from one of the DC routers and its directly connected core router and replaced it with my standard ibgp peer-group. The session comes up but I'm not getting any vpnv4 routes over the session. I can't figure out what I'm overlooking. Core: neighbor ibgp-peer peer-group neighbor ibgp-peer remote-as 65001 neighbor ibgp-peer transport path-mtu-discovery neighbor ibgp-peer password 7 monkey neighbor ibgp-peer update-source Loopback0 neighbor ibgp-peer version 4 neighbor ibgp-peer send-community neighbor ibgp-peer soft-reconfiguration inbound neighbor ibgp-peer maximum-prefix 35 80 warning-only neighbor 10.64.0.34 peer-group ibgp-peer neighbor 10.64.0.34 description iBGP to 7201-1.dc (65001) neighbor 10.64.0.34 default-originate ! address-family vpnv4 neighbor ibgp-peer send-community extended neighbor 10.64.0.34 activate exit-address-family I added the last activate for grins but it didn't help. peer-groups are auto-activated which is why it's not explicitly spelled out in the vpn4 statement. DC: neighbor ibgp-peer peer-group neighbor ibgp-peer remote-as 65001 neighbor ibgp-peer transport path-mtu-discovery neighbor ibgp-peer password 7 monkey neighbor ibgp-peer update-source Loopback0 neighbor ibgp-peer version 4 neighbor 10.64.0.20 peer-group ibgp-peer neighbor 10.64.0.20 description iBGP to 7613-2.clr (65001) ! address-family ipv4 neighbor ibgp-peer send-community neighbor ibgp-peer soft-reconfiguration inbound neighbor ibgp-peer maximum-prefix 35 80 warning-only neighbor 10.64.0.20 activate exit-address-family ! address-family vpnv4 neighbor ibgp-peer send-community extended exit-address-family I've removed several things of course. Does anything jump out at anyone? I'm having difficulty finding a command to see what prefixes I'm advertising inside of a vrf to the remote peer. All I get on the DC router is the connected and static prefixes. Do peer-groups and vpnv4 routes not mix? Thanks Justin ___ 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] BGP quandry
Justin Shore wrote: Core: ! address-family vpnv4 neighbor ibgp-peer send-community extended neighbor 10.64.0.34 activate exit-address-family I added the last activate for grins but it didn't help. peer-groups are auto-activated which is why it's not explicitly spelled out in the vpn4 statement. DC: neighbor 10.64.0.20 peer-group ibgp-peer neighbor 10.64.0.20 description iBGP to 7613-2.clr (65001) ! address-family vpnv4 neighbor ibgp-peer send-community extended exit-address-family So I did a little more playing around and found that if I added an vpnv4 activate on the DC #2 router for core #2's IP I got my vpnv4 routes. I only got those connected to core #2 though. I had to add another activate for core #1. I'm assuming that core #2 sent those BGP routes that it learned via iBGP from core #1 to DC #2 because of the RR config. Since I'm eliminating the iBGP RR config I have to complete the full mesh to get the full set of routes. That makes sense. One thing that doesn't make sense at this point is why the ibgp-peer peer-group config in the vpnv4 address-family wasn't sufficient enough to enable the learning of vpnv4 routes. Do peer-groups and vpnv4 config not mix? Trying to add the command neighbor aaa.bbb.ccc.ddd send-community extendeded to any of the routers involved (where aaa.bbb.ccc.ddd is a configured member of a peer-group) results in the error: % Invalid command for a peer-group member To me that implies that some sort of interaction exists between vpnv4 config and peer-group config. Can anyone add any input to this? Thanks Justin ___ 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] OT: 871W config
Thanks for all who replied on and off-list. I see a few things in the configs that were sent to me that I overlooked, like the 'bridge # route ip' commands. That could very well be the problem. All of the configs sent were using only a single default VLAN whereas I've disabled VLAN 1 and am trying to use 3 other VLANs to manage security and dedicate a VLAN to voice. That may complicate things more. I will see if I get a working config and then I'll share the relevant config with the list. Thanks again Justin Ziv Leyes wrote: Why do you think this is off topic? This is a config sample of I'm using at home and it's working great, of course you need to change some of the settings to match your needs. ! bridge irb bridge 1 protocol ieee bridge 1 route ip ___ 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] OT: 871W config
I've got an off-topic plea. I'm trying to configure a simple little 871W as a CE that I need to deploy next week. The wifi on this thing is kicking my ass. 881Ws are completely different than their 871W ancestors. 881Ws have a logically separate internal AP that you basically session into. The 871W's radio is integrated into the router's config itself. I can't for the life of me get wifi sub-ints to bridge onto the SVIs that I'm using on the wired side (3x VLANs: data, voice, and guest). I found a config guide online that showed SVIs configured with nothing but the bridge-group commands, BVIs corresponding to those bridge-groups where all the L3 config now resides, and then normal Dot11Radio sub-ints with matching bridge-groups. However doing this and putting the bridge-group commands on the SVIs breaks the wired connectivity (and doesn't make wifi work anyway). Does anyone have a working config for a 871W that they wouldn't mind sharing off-list? This should be a trivially minor config and for some reason it's thoroughly stumping me. Thanks Justin ___ 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] OSPF fast convergence
Phil Mayers wrote: Justin Shore wrote: Phil Mayers wrote: Common advice seems to be to make actual link-loss detection fast, in preference to using BFD. That said, I know some people use BFD. Assuming you're using LAN cards, you may want to see if you can make router links as routed rather than SVI interfaces. Though routed interfaces are implemented internally as VLANs, presentations I saw from Cisco claim that this: I prefer to use BFD personally. Link failure detection without BFD will be slow no matter what you do. FRR doesn't gain you much if it takes you several seconds to realize that a link dropped. Seconds? Wow. I'm curious - under what circumstances are you seeing such length link-loss detection times? On our 7600s today. We drop a link to one of them and the thing is oblivious to the drop for 2-3 seconds. Dumber than a post... L3 is waiting on L1 to wake up before it can start tearing down routing relationships and pulling routes. I'm running SRB1 on my 7600s right now so that I can run BFD. I'm trying to get my account team to carry my BFD on SVI request to the DE team for BFD or the product manager. Unfortunately I think I'm throwing pennies into a blackhole. Justin ___ 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/
