Re: [c-nsp] How to terminate 100.000 IPsec VPN clients?
Florian Bauhaus f.bauh...@portrix-systems.de wrote: What would be the best way to terminate 100k IPsec VPN clients? I probably would not skin this cat with Cisco, but with Linux. Find something embedded-esque box with a crypto accelerator; such as: http://www.globalscaletechnologies.com/p-35-openrd-ultimate.aspx IIRC I tested an OpenRD ultimate to 70MB/s with AES/MD5...not bad for ~$250, using 11W of electricity and takes up the space of a hardback book. Then the rest is strongSwan and a pile of scripting templates; or backend RADIUS whatnot. We (a small-medium sized UK university) use these OpenRD's for lots of things at work (RADIUS, syslog, DNS, etc). I already got a few ideas on how to do this but I would like to know if someone else got experience with this and could help me out a bit. I would be keen to help out, but then it depends on the objectives of the project. Cheers -- Alexander Clouter .sigmonster says: BOFH excuse #105: UPS interrupted the server's power ___ 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] Performace - IP DHCP Snooping
Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: havent noticed any issues with having DHCP snooping enabled - performance wise the access layer seemed to be the same with or without it (its very quick and easy for these switches to see particular bits of packets). We have been using it for at least three years with no noticable performance problems on our ~80 C3750's (~25 stacks) at the access layer. Two gotchas: * 'ip dhcp snooping database flash:dhcp-snoop.db', so that if the switch reboots all the clients do not get locked out * do not encourage your MS Windows hosts to do a DHCPRELEASE[1] (by default it does not, I got stun for being 'clever'). It is helpful that a lease continues after the workstation shuts down and powers up say the following day. At my workplace, for central London you would have expected a non-third world mains supply but that's probably just Estates, staff generally shutdown workstation at night...power failure occurs taking out the DHCP server (failover fails too), workstation turns on...switch refuses to let them on as the workstation has not got a valid lease. If the lease is not released, then the workstation is permitted to continue using it after a reboot and the Windows DHCP client seems to try to use the old one if it is still valid. We cover all our VLAN's (the DHCP enabled ones), our 'template' edge configuration looks like (includes MAC-auth/802.1X VLAN assignment): http://www.digriz.org.uk/lanwarden Remember on your uplinks: int Po1 [snipped] ip arp inspection trust ip dhcp snooping trust Cisco also have a very good presentation[2] on this. Cheers [1] http://msdn.microsoft.com/en-us/library/cc227278(v=prot.10).aspx [2] http://www.cisco.com/web/DK/assets/docs/security2006/Security2006_Eric_Vyncke_2.pdf -- Alexander Clouter .sigmonster says: Thufir's a Harkonnen now. ___ 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] Performace - IP DHCP Snooping
* Andrew Miehs and...@2sheds.de [2011-08-14 17:20:35+0200]: On 14/08/2011, at 12:56 PM, Alexander Clouter wrote: Two gotchas: * 'ip dhcp snooping database flash:dhcp-snoop.db', so that if the switch reboots all the clients do not get locked out I don't understand why you would require storing this data? The dhcp servers are on the trusted ports - and clients are all on untrusted. What more information needs to be stored? http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/snoodhcp.html#wp1090370 Switch reloads occur for many reasons (power failures, IOS updates, etc) and you do not want all the workstations hanging off that switch being dead in the water when/if they do not renew their lease... Cheers -- Alexander Clouter .sigmonster says: Computers are not intelligent. They only think they are. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] best way to get around IPSEC subnet Conflicts.
Brent Roberts brent...@wirezsound.com wrote: I am looking for the best way to get around IP conflicts (On the Far Side) in fully redundant Hardware solution. I am working in a large Scale Hosted application environment and every 5th or so customer has the same RFC1918 Address that every other small shop has. Depends on how involved you are at the client end, but if this occurs regularly and is a pain, maybe getting some IPv6 in there might help? Unique address space is afterall one of it's biggest selling points and at the client end you do not even have to make it Internet routable; just an internal LAN/VPN deployment. As you have not mentioned what the application is (developed inhouse?) then I have no idea if this is a silly option, but if you are considering a pile of 6500's and what-not...the IPv6 route might actually be cheaper and cause a lot less damage to your brain being forced to think about VRF + IPSEC + NAT + OSPF + pile-of-likely-hacks-needed. Just putting it out there... :) Cheers -- Alexander Clouter .sigmonster says: Serfs up! -- Spartacus ___ 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] No warning in conf t ?
Phibee Network Operation Center n...@phibee.net wrote: I want know if it's possible to say at the IOS that don't sent Warning. Ex: C7606(config)#no interface Serial0/1/0.1 multipoint Not all config may be removed and may reappear after reactivating the sub-interface I want don't see Not all config may be removed and may reappear after reactivating the sub-interface that he delete the interface without errors because it's a perl script. I want remove all config systematiquely This is the sort of thing you can trivially do with Expect[1] in Perl; which I hope is what you are using to interact with the device? Cheers [1] http://search.cpan.org/~rgiersig/Expect-1.21/Expect.pod and http://search.cpan.org/~bnegrao/Net-SSH-Expect-1.09/lib/Net/SSH/Expect.pod -- Alexander Clouter .sigmonster says: A lack of leadership is no substitute for inaction. ___ 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] ipv6 IOS SLB workaround question
Dave dcostell-cisco...@torzo.com wrote: Since the IOS SLB is not slated to work with IPv6 does anyone have any ideas about a work around for this ? I was trying to figure out a way to send traffic for a specific IPv6 address to a vserver IPv4 address, anyone have any ideas ? For example: DNS for www.slbtestsite.blah is 2001:db8::216 the SLB vserver ip is 192.0.2.216 if someone hits www.slbtestsite.blah how could we map this space to use the correct vserver and serverfarm to respond ? Depending on what your web clusters run, you could anycast[1] 2001:db8::216 on a node or two of your webfarm (try to keep three router hops between them if possible) and then have Apache-mod_proxy/*inetd/Squid/etc loop back to your IPv4 SLB vserver address 192.0.2.216. This would not be a 'least-conn' for the IPv6-IPv4 conversion, but that is a very low cost operation, as it's just gluing two TCP sessions together and shuffling opaque bits'n'bytes, I suspect you will not have any problems. It is too early in the morning for me to think about if you could run into any nasty IPv4 ICMP corner cases; but I think you will be safe. This would help you get by with using Cisco's IOS SLB, but this could be a sign that the writing is on the wall and it no longer is going to be meeting your needs. Cheers [1] http://www.digriz.org.uk/ha-ospf-anycast -- Alexander Clouter .sigmonster says: Expense Accounts, n.: Corporate food stamps. ___ 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] tftp woes
Dan Letkeman danletke...@gmail.com wrote: I think the server might be over utilized as well, because if we are imaging off of one server and then we tftp off of another, things are faster. So that to me says that its a server problem and not a network problem. Yes we multicast as well, but sometimes the guys who do the imaging want to unicast instead for what ever reason. Our guys need the same (they rarely use the multicast functionality although they do still need it) as we unfortunately have to use FreeGhost, well I guess it's better than that 'other' ghosting tool. Anyway, I remember duct taping the problem by configuring SFQ on the Linux host in the egress direction to stop the unicast NFS flows saturating the link and preventing the TFTP flows from being starved. Not perfect, but it was good enough as a quick fix. Cheers -- Alexander Clouter .sigmonster says: Are you a turtle? ___ 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] Cat4500 High CPU with Multicast Stream
Antonio Soares amsoa...@netcabo.pt wrote: I have a customer with a few 3560/3750's and one 4500/SUP5 acting as the core switch. For some reason, when a user start one multicast stream, the 4500 suffers high cpu utilization and the network is affected. Only the 4500 suffers of this problem, the 3560/3750's don't have any complaints. I see that the 4500 is a CEF based platform and I know that IP Multicast is not supported in the CEF path. So I was expecting to have this traffic switched in hardware or fast-switched. But a packet capture shows me that the traffic goes to the cpu. I used this debug and output to confirm this: debug platform packet all receive buffer show platform cpu packet buffered The processes that eat most of the cpu are Cat4k Mgmt LoPri and Cat4k Mgmt HiPri. We thought this could be a bug and we upgraded the 4500 to the latest release but the problem is exactly the same. The multicast stream is processed by the cpu. Anyone has seen this before ? Is this normal behavior of the 4500 ? Usually the multicast streams are destined to 224.x.x.x. The end users do not respect the 239 rule. Sounds like the following might help: http://www.gossamer-threads.com/lists/cisco/nsp/128799?do=post_view_threaded It's the following lines you might need: mls rate-limit multicast ipv4 non-rpf 100 10 mls rate-limit multicast ipv4 partial 250 100 Or something similar to them. Cheers -- Alexander Clouter .sigmonster says: I'm not tense, just terribly, terribly alert! ___ 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] Brute Forcer [Slightly OT]
James Bensley jwbens...@gmail.com wrote: I've had a play with Hydra which can brute force a Telnet session to a Cisco device. The problem is Hydra (as far as I can tell) only uses dictionary attacks. Does anyone know of a tool that will brute force Telnet and/or SNMP communities when given a typical brute force character set like a-zA-Z0-9 etc and length, instead of a dictionary. pipe your community list into xargs calling snmpget (wrapped in sh) and check the return code to decide to echo 'HIT!'. Tweak timeouts and make use of xargs '-P' to make things faster. Bonus points for anyone that can recommend a tool they have actually used and not just read about and have had success with said tool :D Bonus points for making it a shell one liner? This unit works for beer. Cheers -- Alexander Clouter .sigmonster says: Captain's Log, star date 21:34.5... ___ 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] VSS - Horror stories, show-stoppers, other personal experience?
* Murphy, William william.mur...@uth.tmc.edu [2011-06-21 12:43:24-0500]: We have been using L3 access for a couple of years and it does work quite well, but we are migrating away from it due to the fact that IPv6 forwarding in hardware is not doable on our access-layer switches, and it'd cost a bundle to upgrade everything. For one of my larger buildings, upgrading to VSS and moving routing to the distribution was a lot cheaper than buying 45 Sup7's for my 4500 access-layer switches so I can do IPv6 in hardware... Ah, we have C3750's at the edge and soon to move to C3750X's. Part of the reason to move to L3 was the ~80 IPTV channels we have, and to banish spanning-tree from our network as best we could. Other people I notice seemed swayed to VSS to get the high port density (datacentre reasons) which simply does not apply to us. Cheers -- Alexander Clouter .sigmonster says: First Law of Socio-Genetics: Celibacy is not hereditary. ___ 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] VSS - Horror stories, show-stoppers, other personal experience?
Murphy, William william.mur...@uth.tmc.edu wrote: We are running VSS for distribution layer switching in a campus environment and have been quite pleased with it... Benefits for us are simplification, faster convergence and better performance (distribution of traffic)... Only curious, VSS we (a small university) felt was way to expensive to do and did not give us many benefits. No more STP blocking ports, MCE to access-layer so both links are utilized, faster convergence, no need for HSRP, also our two 10G uplinks are equal-cost even though they are connected to separate chassis... Would you say it's easier than just running an IGP (OSPF, EIGRP, ISIS or iBGP) and pushing L3 to the access layer of your network, or has VSS really made things a lot simpler? Only asking you as I know no one nearby who went the VSS route and unfortunately the only people raving about it are sales people, hardly a great frame of reference :) I can see VSS helping out when you have VLAN's spanning buildings[1], and it be a real uphill struggle to get the sysadmin's of the systems on those VLANs to use localised subnets instead, but surely it's more cost effective and does not limit your future options to do a migration to L3 up to the access layer everywhere than deploy VSS? Plus, the cynic in me is more interested in the failure modes. If everything goes horribly wrong, I am more comfortable pulling apart OSPF/EIGRP frames rather than some new fango Cisco thingy mcwhatsit :) Cheers [1] once TRILL comes along, what else does VSS offer? -- Alexander Clouter .sigmonster says: Do you guys know what you're doing, or are you just hacking? ___ 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 CPU spikes, an academic question
Peter Rathlev pe...@rathlev.dk wrote: I know a single 5 second interval of 100% CPU utilization now and then is rather irrelevant seen from an operational perspective. That's probably even more true when looking at a 600 MHz MIPS on a Sup720. This thing has me puzzled though. :-) A burst of SNMPv3 with cryptographic operations can hurt a poor MIPS chip. We run torrus[1] and it took me a while to realise the obvious that polling all our kit 3DES/MD5 was probably bad idea (it was brutal enough to the system that was doing the polling) so when with just SNMPv2c. The following is the output from show proc cpu (slightly reformatted) from a device that exceeded a 90% warning threshold we've configured. You really want to be looking at the '5min' sorted graph. CPU utilization for five seconds: 100%/0%; one min: 10%; five min: 4% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min Process 8 870373628 51977035 16745 1.27% 0.59% 0.64% Check heaps 48720306096 67521163300 0.15% 0.04% 0.04% Port manager per 29688 5187559 1 0.07% 0.00% 0.00% Load Meter 35818902200 40236967469 0.07% 0.03% 0.02% CEF: IPv4 proces 2385574908 641372631133 0.00% 0.12% 0.08% IPC Seat Manager 51 111228136 4913752 22636 0.00% 0.07% 0.05% Per-minute Jobs 27228800268 228265577126 0.00% 0.10% 0.07% IP Input 56155288392 590654988 93 0.00% 0.13% 0.09% ISIS Adj 57816540192 166947095 99 0.00% 0.05% 0.04% HSRP IPv4 I've excluded processes with 0% utilization for all three periods. To me the above means that 0% time (?) was spent interrupt switching, ...in the previous 5sec interval. The spikes do not seem to correlate with a lot of traffic, neither traffic for the RP nor traffic generally being forwarded by the box. It also does not correlate with IGP or BGP events or anything I'd consider relevant. Even the odd loop or ridiculous multicast flooding dosn't tax the CPU under normal circumstances. multicast from a directly connected VLAN at the router with the TTL of the packets set to 1 is how you can multicast 'attacks' on routers. Might be something occasionally firing up (Norton Ghost) probbing for a suitable TTL to put in it's multicast payload...but this I would expect to appear in your ring buffer. What puzzles me is: What causes the RP to max out at 100% utilization in a case like this? Should I just ignore it altogether? The sysadmin in me says look at the *runtime*/*uSecs* columns. Good Hunting. [1] http://torrus.org/ -- Alexander Clouter .sigmonster says: pain, n.: One thing, at least it proves that you're alive! ___ 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] NetFlow for billing on 6500/SUP720-3B
TCIS List Acct lista...@tulsaconnect.com wrote: We have traditionally used mirror ports in a L2 switch attached to a FreeBSD box with NICs in promisc. mode to do our traffic accounting (monitoring the traffic to/from the edge and ignoring local traffic). However, with the new 6509 platform, we are hoping to use NetFlow v9 instead and get rid of the sniffer box. Our hope is that we can monitor each customer port (which is configured as a L3/routed port) and export only the flows to/from the edge to our collector, and then use that data for billing purposes. You will have to configure a seperate instance for each user, but if you have DFC3B's (3A's have borked counters apparently, well ours do) you can configure a NOOPing PBR route-map on each customer. Have a common ACL for all your 'local' traffic and a catchall route-map rule for everything else. The script up something to SSH in (might be possible via SNMP), 'show route-map' and yank out the packet/byte counters. Profit! Have fun. -- Alexander Clouter .sigmonster says: Happiness is a hard disk. ___ 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] Advice on Core Swithes / Routers
Phil Mayers p.may...@imperial.ac.uk wrote: SLB on the 6500 (as opposed to with an ACE module) has caveats; it's slow (as initial packets are punted to CPU) and Cisco don't really support it AFAICT. SLB on our 6500 gave us more trouble than good; it would randomly stop working and was a right pain to diagnose (is any load-balancing reliable, compliant and easy to diagnose?). I moved to anycast'ing which has worked out far better for us and is a far simplier system to understand: http://www.digriz.org.uk/ha-ospf-anycast Cheers -- Alexander Clouter .sigmonster says: Death is nature's way of telling you to slow down. ___ 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] Catalyst reloads (was Re: Is Cisco equpiment de facto for?you?
Jeff Kell jeff-k...@utc.edu wrote: On 1/11/2011 11:29 AM, Seth Mattinen wrote: The cisco-nsp mailing list is often much more helpful than TAC. On that note... does this ring any bells? Have a 3750E that has had spurious reloads (4 since Friday), was switch-1 of a 3-member stack, initially was the master, now switch-2 has taken over as master. Show version on the failing one just shows FunnyFarm-1 uptime is 17 hours, 48 minutes System returned to ROM by power-on The other members have 23-week uptimes. There's no crashinfo in the logs, no software forced reload type reload events. TAC insists power was cut to the switch (four times?). Weekly at roughly 4:30am we regularly saw power cycling of a bunch of kit (including a 3750E stack) reoccurring, often to the minute, for one[1] of our considerably less than average server rooms. We put it down to brown-out's on a circuit caused by a timer asking for hell to be stoked so that the building has a chance to warm up. Simple text is to slap something else on the same circuit and see if that loses power too...make sure it is picky about getting it's $LOCAL_VOLTAGE and $WANTED_AMPERAGE (or put the stack member on a portable UPS). If that dies, you know your power feed is dodgy, if it stays up, you might have a borked/loose/taught cable. Cheers [1] that's a lie, they all are considerably less than average -- Alexander Clouter .sigmonster says: Do not drink and drive. ___ 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] redistribute routes leaked from another VRF?
Jeff Bacon ba...@walleyesoftware.com wrote: The unicast I want to switch out into a VRF. I get the notion of using VRF source-selection but I'm uncomfortable with it, and I'm not sure how well it works in hdw at line rate, which it needs to. Besides, I'd like to drive the source select map from the routing protocol I'm receiving from the far end...) Hopefully I understand what you are trying to do, I just had to work this out for myself yesterday when some infernal building services equipment landed on my desk that needs to connect to our LAN (and passed around over OSPF across multiple routers). :( Turns out the 6500 12.2(33)SXI4a does not support 'vrf source select' (well grumbles 'unsupported and not official' so best avoided I guess) unless you have forked out for a services provider imagesapparently. Means you have to turn to PBR to save the day: 6509-1#show ip access-list estates Extended IP access list estates 10 permit ip 172.16.11.64 0.0.0.15 10.192.0.0 0.0.255.255 (124047 matches) 6509-1#show route-map estates route-map estates, permit, sequence 10 Match clauses: ip address (access-lists): estates Set clauses: vrf estates Policy routing matches: 123023 packets, 7586318 bytes 6509-1#show ip vrf estates Name Default RD Interfaces estates 65000:0 Vl2900 Vl2901 Vl 6509-1#show run int vlan130 Building configuration... Current configuration : 791 bytes ! interface Vlan130 description infernal equipment ip vrf receive estates ip address 172.16.11.78 255.255.255.240 ip access-group 2130 in no ip redirects ip policy route-map estates standby 130 ip 172.16.11.65 end router ospf 1000 vrf estates router-id 10.192.0.253 log-adjacency-changes redistribute connected subnets needed (do not add 'network') passive-interface default no passive-interface Vlan2900 no passive-interface Vlan2901 no passive-interface Vlan network 10.192.0.0 0.0.255.255 area 0 network 172.18.0.0 0.0.255.255 area 0 network 172.31.4.0 0.0.0.255 area 0 In short, you add to your connected interfaces 'ip vrf receive estates' to put those routes into your vrf (in my case 'estates'), this pairs up with the 'redistribute connected subnets' in the ospf process; but you must *not* add 'network 172.16.11.64 0.0.0.15'. This sorts out traffic going from the VRF to Vlan130. To get the return traffic back into the VRF, that is where the PBR comes into play. Lit this up yesterday and works a treat. Cheers -- Alexander Clouter .sigmonster says: design, v.: What you regret not doing later on. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3550 layer 3 switch replacement for v6
Seth Mattinen se...@rollernet.us wrote: I have some etherswitch service modules (3750 in a NME) running IPv6 with OSPF just fine. Other than a /128 ACL requiring ff:fe in the right spot (someone detailed why either here or NANOG when I complained about it previously) to store it in TCAM, I don't have any major complaints with their IPv6 support. I'm not doing anything fancy, just pushing packets with anti-spoofing ACLs. Problems I have seen with our 3750 kit: * no VRF support for v6 * MAC based ACL's do not work, apparently Ethernet frames with a ID of 0x86dd are not 'Ethernet' frames to Cisco and instead take on a magical property that makes them invisible to MAC ACL's :-/ * does not generate ICMP unreachables for v6 (or v4 for that matter) * never could get v6 EIGRP working, but that might be just me, OSPF works fine so I am not complaining * no IPv6 VACL's support Cheers -- Alexander Clouter .sigmonster says: You will be run over by a bus. ___ 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] Multicast distribution over backbone
Phil Mayers p.may...@imperial.ac.uk wrote: I have 6 routers in 6 cities interconnected by 1Gbps links from third party providers (just 1 VLAN over xconnects, no QinQ, MTU=1500). Each city is connected to main node. I have to distribute multicast streams (around 100 channels of IPTV) from source 1 city to 5 others over these 1Gbps links. All devices are Cat6500/Sup720. All routers runs IS-IS and iBGP. And in each city local distrubution will be done over PIM Spare-Mode to L3 switches (Cat3560-X). How do this best ? Use mBGP ? Use MSDP ? Configure just PIM-SM on backbone interfaces ? Or maybe some hybrid solution ? You just need PIM-SM. Designate one router as the RP. Configure PIM-SM each router. Configure them all with the same RP. You only need MSDP to pass source info between PIM-SM RPs. All our core routers are RPs with the same 'anycasted' address so we have resilence. We use MSDP to then make sure everything is then sync'ed up: interface Loopback0 ip address 172.31.3.253 255.255.255.255 end interface Loopback2 description ANYCAST: mcast rp ip address 192.0.2.1 255.255.255.255 end 6500#show run | include pim [snipped] ip pim rp-address 192.0.2.1 mcast ip pim accept-rp 192.0.2.1 mcast ip pim ssm default 6500#show run | include msdp ip msdp peer 172.31.3.161 connect-source Loopback0 ip msdp peer 172.31.3.249 connect-source Loopback0 ip msdp peer 172.31.3.93 connect-source Loopback0 ip msdp cache-sa-state ip msdp originator-id Loopback0 ip msdp mesh-group soas 172.31.3.161 ip msdp mesh-group soas 172.31.3.249 ip msdp mesh-group soas 172.31.3.93 ip msdp password peer 172.31.3.161 7 [ahem] ip msdp password peer 172.31.3.249 7 [ahem] ip msdp rpf rfc3618 Cheers -- Alexander Clouter .sigmonster says: Confucius say too much. -- Recent Chinese Proverb ___ 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] Multicast distribution over backbone
Tomas Daniska tomas.dani...@soitron.com wrote: You just need PIM-SM. Designate one router as the RP. Configure PIM-SM each router. Configure them all with the same RP. You only need MSDP to pass source info between PIM-SM RPs. You only need BGP multicast AF if you want to use a different routing table for the multicast RPF check (and thus distribution tree). I'd go with PIM-SSM, no RP needed and more control over the topology ...SAP annoucements? Sure you could put the SDP payload on some HTTP server...but that is not great for all situations and an RP is needed isn't it? Cheers -- Alexander Clouter .sigmonster says: No man is an island if he's on at least one mailing list. ___ 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] Untagged native VLAN...
Elmar K. Bins e...@4ever.de wrote: why don't you use: switchport mode access switchport access vlan 402 switchport voice vlan 498 Will try that - this sounds like the easiest way, although I dislike special constructs normally. But - this would allow me to keep the portfast setting which definitely helps when dealing with workstations... The special construct is important for if you use dot1x on those ports and want both the phone and workstation to do dot1x (or mab) with your RADIUS infrastructure deciding what is what (rather than the 'phone' saying 'honest guv, let me in'). Cheers -- Alexander Clouter .sigmonster says: Beam me up, Scotty, there's no intelligent life down here! ___ 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] any program will send SMS message as Network device down?and resume
Edward Iong edward_io...@hotmail.com wrote: Anyone know what program will send the sms to people as the network device is down and resume as well. http://lmgtfy.com/?q=sms+monitor+oss Cheers -- Alexander Clouter .sigmonster says: If God is One, what is bad? -- Charles Manson ___ 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] Weird Ping Response Times
Dominic domi...@broadconnect.ca wrote: Does anybody have any idea what could wrong, or what I should be looking to adjust? Ping (aka ICMP Echo requests) does *not* measure latency, no matter what you may have been led to believe in the past. Cheers -- Alexander Clouter .sigmonster says: Be careful when you bite into your hamburger. -- Derek Bok ___ 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] help on pxe boot
teklay gebremichael teklis...@yahoo.com wrote: since we are planning to have computer lab with old pcs that will boot from the server, this problem is very critical. is there some thing enabled by default on the switch that prevents booting from the network? 'spanning-tree portfast default'? Remember to also enable 'spanning-tree portfast bpduguard default'. Cheers -- Alexander Clouter .sigmonster says: What orators lack in depth they make up in length. ___ 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] rancid and inventory with ^
Hi, * john heasley h...@shrubbery.net [2010-09-07 13:35:26-0700]: Tue, Sep 07, 2010 at 09:39:00AM +0100, Alexander Clouter: !NAME: temperature outlet 9 , DESCR: module 9 outlet temperature Sensor !NAME: temperature inlet 9 , DESCR: module 9 inlet temperature Sensor + !NAME: temperature device-1 9 , DESCR: module 9 device-1 temperature Sensor + !NAME: temperature device-2 9 , DESCR: module 9 device-2 temperature Sensor !opv1^T^LB fwiw, this would strike me a either failing hardware (SMbuss or sensor) or a s/w bug thats reading outside of device ID buffer range or an improperly flashed device ID. if it flaps, its probably not the latter. Cisco said there might be an I2C glitch. Makes me wonder if Cisco bitbang the I2C bus off some GPIO pins and much up the timing if the router is under load. it could also be a s/w bug that is just writing junk to the tty when this command is run. you can speculate based upon the bahavior. Indeed, you could speculate pretty much anything regarding an opaque box. :) Anyway, there was a thread here that kicked this off into life: http://marc.info/?l=cisco-nspm=126780984709176w=2 and that could be the s/w just not being patient enough for those devices. if the command returns an error when it fails to reach devices it knows to exist, then rancid can be altered to fail and retry. There is no error. To me that looks like either a buffer length not being properly checked, a NULL byte at the end of a string going AWOL (think 'strncpy') or there is crud just coming off the I2C bus (for whatever reason) and IOS is trying it's best to make the output usable; even if that means removing unusable guff. To be frank, it's rare that the vendor ever does the right thing so I doubt it's IOS trying to do the Right Thing(tm) :) Cheers -- Alexander Clouter .sigmonster says: Use at own risk. ___ 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] rancid and inventory with ^
Tassos Chatzithomaoglou ach...@forthnet.gr wrote: Is anyone having issues with rancid collecting the inventory when there are ^ characters in the output? !NAME: temperature outlet 9 , DESCR: module 9 outlet temperature Sensor !NAME: temperature inlet 9 , DESCR: module 9 inlet temperature Sensor + !NAME: temperature device-1 9 , DESCR: module 9 device-1 temperature Sensor + !NAME: temperature device-2 9 , DESCR: module 9 device-2 temperature Sensor !opv1^T^LB !NAME: Gi9/2, DESCR: Transceiver Port Gi9/2 !NAME: Transceiver Port Container Gi9/2, DESCR: Transceiver Port Container Gi9/2 !NAME: Transceiver Gi9/2, DESCR: Transceiver 1000BaseT Gi9/2 We get daily differences (whole config parts are removed and readded), because rancid believes that something has changed, although this is not the case. Probably has to do with the expect code. Yep, and Cisco were not too helpful in trying to get this fixed, their suggestion was to stop rancid making an inventory request :-/ Their initial suggestion was to stop calling 'show inv raw' in rancid as it is more a command not to be used by Joe Public (meant to be for internal use/diagnostics apparently) and that I should not be using it. I asked for another command that would give me the serial numbers of the GBIC's, but turns out 'show inv raw' is the only way. They then suggested that I sit at the console and manually check the output of 'show inv raw' and see if I notice anything in the logs when that occurs... I pointed out their madness and handed them a perl script that polled every five minutes by SSHing in, yanking the config and storing it locally. This meant you could quickly use the file size to see when it choked and run 'diff -u'. This replicated the problem after an hour or so to which the response was that my script is corrupting the output and so was rancid. It was suggested that unplugging and replugging in 'flapping' transceivers (the config changes for us were the gigabit slots on the SUP) could fix it, and it did for a short time...then it came back and would not go. I got bored hounding after them and added it to the list of items as another reason to leave Cisco.../grumble Anyway, there was a thread here that kicked this off into life: http://marc.info/?l=cisco-nspm=126780984709176w=2 Offline, various people contacted me and the only common element we could find was that problem started with SXI3 and we all had a 10Gb line cards in our 6500's. Cisco say they could not replicate the problem, although they have had several reports of it. The problem was with me most of last month (and on and off for months before that), however it has been behaving recently; probably as our 6509 has actually been turned off and on due to the regularity of power outages at my organisation. My suggestion: * you probably will find some gigabit interfaces are being persistently referred to, unplug and plug them back in * re-seat the line card :) * issue a 'reload' at some maintenance window and update to SXI4 * completely power off the box and turn it on A 'reload' seemed never to quite work for us, I got the impression that there is some dice rolling occurring when the box is powered on/reload'ed that decides if you will be plagued with this issue during the uptime of the box. :-/ Good hunting -- Alexander Clouter .sigmonster says: No one can put you down without your full cooperation. ___ 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 stack
Hi, * Alan Buxey a.l.m.bu...@lboro.ac.uk [2010-08-25 08:55:00+0100]: Interesting, Cisco told us it is generally a bad idea going much above five switch stacks. Something to do with the fact that at the rear of the switch you have a token ring-esque system and 40Gbps of backplane (off the top of my head). In the early code they only had a single token flying around the switches which caused horrible latency woes I would imagine, but things improved when they had multiple tokens rotating through the loop. StackWisePlus is a 32G full duplex bidirectional ring (when cables all installed properly this means you should still be better ff using it rather than having 2 stacks and trying to link the 2 together using eg expensive 10G ethernet X2's or port-channelled 1G's I should have been clearer, we have 3750 stacks in our data closests as workstation edge termination kit. Pulling two numbers out of nowhere and slapping them together (plus our use of 'switchport protected' in our standard access port template) tells me 99% of the traffic is not workstation-workstation. So for us, I still am thinking two stacks is better than one :) Cheers -- Alexander Clouter .sigmonster says: Is death legally binding? ___ 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 stack
Bøvre Jon Harald jon.harald.bo...@hafslund.no wrote: We have a number of 3750 stacks with anything from 2 to 8 switches. Our standard when configuring new stack: First switch numbered 9, second switch numbered 8 Switch # 9 given priority 15 (highest) Interesting, Cisco told us it is generally a bad idea going much above five switch stacks. Something to do with the fact that at the rear of the switch you have a token ring-esque system and 40Gbps of backplane (off the top of my head). In the early code they only had a single token flying around the switches which caused horrible latency woes I would imagine, but things improved when they had multiple tokens rotating through the loop. Either way, I also thought when an 'interesting' decision had to be made traffic had to be punted upto the master switch and back down. Obviously the longer the chain the worse *everything* gets. However I doubt our users would actually notice. Any reason you do not split your stack in half? Only curious. Cheers -- Alexander Clouter .sigmonster says: BOFH excuse #330: quantum decoherence ___ 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] LAM / Mobile IP in modern times
David Freedman david.freed...@uk.clara.net wrote: Had the idea of testing LAM to support an application without resorting to inter-datacenter bridging(*) (Vmotion in this case) , Astonished to find the documentation old and out of date, coupled with a lack of vrf support (no redistribute mobile in the VRF BGP context) , Can't seem to find anything suggesting a feature which could quite easily be a superb alternative to bridging is even remotely vrf aware. Any advice/pointers appreciated. I was toying with the idea internally of putting a tiny OSPF router into our VM cluster to drag IP's from one side of our organisation to the other. I then found out that our consultants had decided to deploy for us a two site with two node configuration where A|B where on one site, C|D on the other...but you could not do any (A|B)-(C|D) migration *sigh* :-/ You could actually put the OSPF daemon on the UNIX guests themselves but for Windows guests, you used to be able to use OSPF with Windows, but apparently (news to me) OSPF is not used much in the industry according to Microsoft I guess you could use RIP. I'm thinking of OSPF across two subnets on a trunk link to your guest. On one VM node one of the VLAN's goes to no where so there are no OSPF (or RIP, yay) neighbours, on the other, the other VLAN is the blackhole. The guest then advertises it's 'service' IP to it's OSPF neighbours and things should work. That's how I would do things. No silly over-engineered datacenter bridging technologies, no over priced licencing needing to be forked out for, etc etc. Of course that's with OSPF on a 'small' scale, but I guess you could feed that into a iBGP advertisement. The only remaining question is why for it's money have VMWare not done the trivial task of making OSPF part of their VMotion malarkey...*sigh* Cheers -- Alexander Clouter .sigmonster says: An avocado-tone refrigerator would look good on your resume. ___ 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] LAM / Mobile IP in modern times
Hi, * Lincoln Dale l...@cisco.com [2010-08-10 19:56:21+1000]: On 10/08/2010, at 6:35 PM, Alexander Clouter wrote: I was toying with the idea internally of putting a tiny OSPF router into our VM cluster to drag IP's from one side of our organisation to the other. reality is that many hosts and applications require and expect layer 2 connectivity for things other than IP unicast when they think they are in the same IP subnet another host. Thought it was obvious I was talking L3 here, maybe not. If you are coupling hosts at L2 then you would be nuts to not move them as a group surely? I probably was not clear when talking about the 'dead zone' VLAN at either site, there just would be no router on that VLAN. An amendment is that you have a dedicated locally scoped same-VLAN-ID VLAN for just those nodes that need L2 lovin' to work on, have another pair of VLAN's for the L3. The only remaining question is why for it's money have VMWare not done the trivial task of making OSPF part of their VMotion malarkey...*sigh* because its not /quite/ as simple as you suggest. The awkward part I see is host based (not service) L3 connectivity. The operating system would need work happily in a multihomed configuration and to understand what a dead gateway means. This probably would not be easy to pull off on a Windows based guest, but it should be quite doable onwell *any* other OS :) As a mentioned before though, unfortunately I never got this beyond the planning stage due to the 'quality' of the VMware consultants we hired :-/ Cheers -- Alexander Clouter .sigmonster says: Minnie Mouse is a slow maze learner. ___ 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] LAM / Mobile IP in modern times
Hi,
* Lincoln Dale l...@cisco.com [2010-08-10 20:46:53+1000]:
The only remaining question is why for it's money have VMWare not done
the trivial task of making OSPF part of their VMotion malarkey...*sigh*
because its not /quite/ as simple as you suggest.
The awkward part I see is host based (not service) L3 connectivity. The
operating system would need work happily in a multihomed configuration
and to understand what a dead gateway means. This probably would not be
easy to pull off on a Windows based guest, but it should be quite doable
onwell *any* other OS :)
the premise of VM mobility is that the OS and apps being virtualised
are completely unaware that they have been virtualised.
what this means in reality is that you can migrate a VM from one
physical host to another and there is no disruption to traffic flows.
there are no disruptions to any TCP connections to apps running on the
(virtualised) server.
...and there would not be as the *service* IP would remain present. It
is the service IP that is being advertised over OSPF, *not* the host
IPs. The idea is you assign multiple IP's to your hosts.
Sure this approach, instead puts the complication of migration into the
multiple number of hosts (would not be a problem if VMware did the OSPF)
rather than in the network. The advantage is that you are now playing
with a very familiary technology (OSPF/iBGP) where you can find many
engineers who can understand what is going on.
but in order for this trick to be pulled off, you need a common L2
domain.
No you do not.
if you're willing to remove that requirement and potentially have an
outage or disruption at the host or app level, or you're willing to do
whatever integration work is necessary to mitigate that, then i
believe its technically possible to have vMotion across L3.
The disruption lasts only as long as your iBGP/OSPF takes to rejiggle
surely? Not much worse than ARP argubly.
but note that not all apps will be supported. nor all hosts. and if
those apps/hosts are doing any form of network-based storage access
(NFS, CIFS, iSCSI et al), then bad things may well happen unless you
can quiesce the virtual host on a migration.
iSCSI can re-establish transparently the connection, NFS you can put
into UDP mode as a quick fix. CIFS, crime and punishment ;) If you want
to maintain TCP state, that you add to your routing table that when
communicating with ${STORAGE_SERVER} use a particular source IP, this
is not tricky stuff.
Cheers
--
Alexander Clouter
.sigmonster says: Life is like a simile.
___
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] LAM / Mobile IP in modern times
Hi, * David Freedman david.freed...@uk.clara.net [2010-08-10 12:01:16+0100]: i believe the common case is that vCenter today 'forces' all hosts in a 'cluster' to be in a common L2 domain, although i read something somewhere that said that it can be overruled. i haven't found the nerd knob to set that if there is such a thing. but even if there is such a nerd knob, its caveat emptor. you might not like the result. :) See, given that today the VMware virtual switch implements more edge features (esp more when you use the n1000v), I wonder why some form of fast converging L3 mobility + routing protocol doesn't feature more prominently here. (Now starting to go off-topic) I see your 'off-topic' and raise you 'conspiracy' :) If you can do L3 mobility with your existing equipment, why buy new equipment and licenses... Cheers -- Alexander Clouter .sigmonster says: Read terms and conditions. ___ 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] Blocking IPv6 on WiSM?
Phil Mayers p.may...@imperial.ac.uk wrote: I believe that various bits of the lightweight wireless are IPv4 only under the hood and will likely require a controller hardware update to make IPv6-aware. This is fine - annoying, but fine. What I really want to do in the meantime is block *ALL* ipv6 - i.e. drop ethertype 0x86dd. No...at a Cisco IPv6 meeting over a year ago (I'm pretty sure you were there too) Mr IPv6 in Cisco said sorry the WLC 4400[1] is effectively dire and cannot do IPv6 filtering. I then asked about MAC filtering to do exactly as you are wanting...and they said...nope. As far as I know the WLC 5500 runs effectively the same codebase, well thats what the Cisco sales rep confessed to and gives you nothing better than the 4400. 'Great' Like us over at SOAS, you too will have to stare at all that IPv6 multicast traffic floating around, knowing that you cannot do anything about it... :( I would love to be wrong on this, so please someone correct me... Cheers [1] my understanding is that the WiSM ~= WLC -- Alexander Clouter .sigmonster says: I am looking for a honest man. -- Diogenes the Cynic ___ 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] (off-topic?) Firefox ubuntu CPU issues when entering at tools.cisco.com to see the SRs
LM asturlui...@gmail.com wrote: Nice to see that I am not alone with problems at cisco.com. I can't understand how is possible to make so ticket website so bad. Do you not have 'web monkeys' where you work? If so, then are you hiring? ;) Cheers -- Alexander Clouter .sigmonster says: Causes moderate eye irritation. ___ 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] Specification of RA that responds to RS (applied RA?suppress I/F)
Brandon Applegate bran...@burn.net wrote: [snipped] The message from last month said that: ipv6 nd ra suppress ipv6 nd prefix default no-advertise Would stop machines from accidentially lighting up ipv6. This makes sense to me, and I really like that solution for a pure static / 'server' segment. However, it seems HSRP hooks into ND/RA so that it can advertise the HSRP address in the RA's. These commands above seem to tangle this up, and unexpected results come from that. I'll try to summarize: We opted for a slightly different approach, embracing that hosts can have multiple IP's, if not encouraged to do so, hanging off the same interface. I let our servers do stateless config and add the static IP's I want to hang services (SSH, DNS, etc) off using the following to pick the address to assign: http://www.digriz.org.uk/misc#GeneratingaUniqueIPv6Address The box will use it's stateless address for chatting to the other hosts (unless you are using 'ip rule' of course) but quite happily serve off the services you run off the box the static addresses you give it; obviously it is those static addresses that go into DNS. So it looks like I can't have my cake (HSRP) and eat it too (no RA + no autoconfig). I'm currently using the middle solution. What got my attention to begin with, is after statically defining the default gateway on the linux machine, I had two default gateways, one obviously from an RA: default via fe80::5:73ff:fea0:1 dev eth0 metric 1 mtu 1500 advmss 1440 hoplimit 4294967295 default via fe80::5:73ff:fea0:1 dev eth0 proto kernel metric 1024 expires 0sec mtu 1500 advmss 1440 hoplimit 64 We use 'fe80::' as the HSRP address, plus additionally marking the router preference as 'high', which seems to (on a Linux box at least) mean it appears as the first match in the routing table to get out of the subnet. The idea being that if something else was to start spitting out RA's on the subnet I hope this strategy mitigates against any misconfigurations of servers. So, the vlan config snippet we use is: interface Vlan123 ip address 1.2.3.6 255.255.255.248 ip pim sparse-mode ip igmp version 3 ipv6 address SOAS 0:0:0:1234::/64 anycast ipv6 nd router-preference High standby version 2 standby 123 ip 1.2.3.1 standby 123 preempt delay minimum 120 standby 123 authentication md5 key-string 7 ahem standby 2123 ipv6 FE80:: standby 2123 preempt delay minimum 120 standby 2123 authentication md5 key-string 7 ahem The result on the server: a...@ipserv0:~$ ip -6 route show default default via fe80:: dev bond0 proto kernel metric 1024 expires 1678sec mtu 1500 advmss 1440 hoplimit 64 The advantage for us with using 'fe80::' is that that is the default gateway on *all* our VLAN's. I thought it was neat anyway, hope you do :) If anyone can see any problems, or make any further recommendations on our standard config, I would be interested to hear them. PPPS: 12.4T says it supports a global address for the HSRP ip ? I only have the option of autoconfig or link-local on my 6500. Is this something coming for Catalyst ? I personally cannot think of a single reason why anyone would want to configure a router gateway address with anything other than link-local. As far as I am aware there are no advantages in using global address although I am happy to be proved wrong and learn something new. Cheers -- Alexander Clouter .sigmonster says: Am I SHOPLIFTING? ___ 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] Specification of RA that responds to RS (applied?RA?suppress I/F)
Alexander Clouter a...@digriz.org.uk wrote: PPPS: 12.4T says it supports a global address for the HSRP ip ? I only have the option of autoconfig or link-local on my 6500. Is this something coming for Catalyst ? I personally cannot think of a single reason why anyone would want to configure a router gateway address with anything other than link-local. As far as I am aware there are no advantages in using global address although I am happy to be proved wrong and learn something new. Okay, I have read Cisco's reasoning[1], although I cannot still see why it's necessary, but I'm not in the ISP/CPE business so my brain is not currently wired for that sort of thinking...I would have expected IGP on the next-hop to the customer router to have advertised the route. /me shrugs Obviously someone with a pile of cash asked for it with good reason and Cisco obliged. :) Cheers [1] http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-fhrp.html#wp1062511 -- Alexander Clouter .sigmonster says: Natural laws have no pity. ___ 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] Why doesn't this IPv6 ACL work?
Seth Mattinen se...@rollernet.us wrote: I tried changing the prefix to be out of my old /48 instead as a shot in the dark, and it didn't throw an error at me with this entry: permit tcp any host 2620:0:950:1:2c0:f0ff:fe5a:abe8 eq 25 However, this continues to not work: permit tcp any host 2607:fe70:0:1:2c0:f0ff:fe5a:abe8 eq 25 I can try switching to routing instead of default template. Otherwise I guess it's iptables/ip6tables time for me if this thing won't accept host addresses under my /32. Just to really be a pain, it all seems fine on our 3750 stack: 103-1#show sdm prefer | include --useful-stuff The current template is desktop IPv4 and IPv6 routing template. 103-1#show ver | include --useful-stuff Switch Ports Model SW VersionSW Image -- - - ---- *1 52WS-C3750-48TS 12.2(53)SE1 C3750-IPSERVICESK9-M 2 52WS-C3750-48TS 12.2(53)SE1 C3750-IPSERVICESK9-M 103-1#conf t Enter configuration commands, one per line. End with CNTL/Z. 103-1(config)#ipv6 access-list test 103-1(config-ipv6-acl)#permit tcp any host 2620:0:950:1:2c0:f0ff:fe5a:abe8 eq 25 103-1(config-ipv6-acl)#permit tcp any host 2607:fe70:0:1:2c0:f0ff:fe5a:abe8 eq 25 103-1(config-ipv6-acl)#end There seems to be no interesting difference between 53SE1 and 53SE2[1]. Last time I had something 'strange'[2] to resolve when talking to Cisco, they suggested a have you tried turning it off and on...given that a whirl? :) Cheers [1] http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_53_se/release/notes/OL21141.html#wp1036822 [2] the switch was acting like a hub for particular combination of destination MAC -- Alexander Clouter .sigmonster says: BOFH excuse #254: Interference from lunar radiation ___ 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] Why doesn't this IPv6 ACL work?
Hi, Phil Mayers p.may...@imperial.ac.uk wrote: On 06/22/2010 08:28 AM, Alexander Clouter wrote: Just to really be a pain, it all seems fine on our 3750 stack: 103-1#show sdm prefer | include --useful-stuff The current template is desktop IPv4 and IPv6 routing template. 103-1#show ver | include --useful-stuff Switch Ports Model SW VersionSW Image -- - - ---- *1 52WS-C3750-48TS 12.2(53)SE1 C3750-IPSERVICESK9-M 2 52WS-C3750-48TS 12.2(53)SE1 C3750-IPSERVICESK9-M 103-1#conf t Enter configuration commands, one per line. End with CNTL/Z. 103-1(config)#ipv6 access-list test 103-1(config-ipv6-acl)#permit tcp any host 2620:0:950:1:2c0:f0ff:fe5a:abe8 eq 25 103-1(config-ipv6-acl)#permit tcp any host 2607:fe70:0:1:2c0:f0ff:fe5a:abe8 eq 25 103-1(config-ipv6-acl)#end If I read it correctly, the problem was when applying the ACL to an interface, not defining the ACL? I get exactly the same as the OP: noc-rt1(config)#ipv6 access-list TEST noc-rt1(config-ipv6-acl)#permit tcp any host 2607:FE70:0:1:2C0:F0FF:FE5A:ABE8 sequence 30 ...so it defines fine, then: noc-rt1(config-ipv6-acl)#int vl51 noc-rt1(config-if)#ipv6 traffic-filter TEST in % This ACL contains following unsupported entries. % Remove those entries and try again. permit tcp any host 2607:FE70:0:1:2C0:F0FF:FE5A:ABE8 sequence 30 % This ACL can not be attached to the interface. ...this on 12.2(52)SE ...and SE1 :) My bad. Cheers -- Alexander Clouter .sigmonster says: BOFH excuse #71: The file system is full of it ___ 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] Alert: Correction
Jun Kemail junkemail...@gmail.com wrote: An employee of The University of Toledo, Jason Mishka, transmitted a message to this listserv on January 15, 2010, giving his personal opinion about Bluecat Networks products. It has since been published on other listservs and re-transmitted without authorization to other sites/forums. His assessments and statements are his opinion and NOT that of The University of Toledo. This is almost edging on a kind of Streisand effect[1]... The University of Toledo does not agree with or support his opinion. Businesses deciding whether to utilize Bluecat Networks products should not rely upon his opinion message in any way. We would appreciate it if all remarks were disregarded and if possible, removed from the listserv. Thank you. VP IT/CIO. From a Gborg account, especially one called 'Jun kEmail'? Assuming this is a legit email, if you plan on making official statements regarding an employee's obviously personal opinion[2], it is probably more effective in my view to consider using your organisation's email address? As for the Bluecat Networks' sales droids who, in my opinion, obviously pressed for this statement to be released, congratulations It is this attempt to censor opinion rather than to actually improve your customers opinion of you that has guaranteed I will not even look at your product line. Cheers [1] http://en.wikipedia.org/wiki/Streisand_effect [2] *I'd* recommend against a bluecat appliance based on our experience. -- Alexander Clouter .sigmonster says: A fool and your money are soon partners. ___ 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] 3750E 12.2(53)SE2 swallows blank lines for banner motd
Sascha Pollok nsp-l...@pollok.net wrote: I just started to finish configuration of a new 3750E-24TS-S running 12.2(53)SE2 IP Base software. Normally, we configure motd banners like this: banner motd # This is __switchname__ Blabla Unauthorized . # It seems, that this switch ignores blank lines as it results in: banner motd# This is __switchname__ Blabla Unauthorized . # Anyone with a similar experience? I get the same. My workaround is to dump the config over TFTP somewhere, tweak up the banner there, and copy it back. That seems to work...albeit it is truly horrible as solutions go. Cheers -- Alexander Clouter .sigmonster says: A man's best friend is his dogma. ___ 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] USB to Serial Converter recommendation
Youssef Bengelloun-Zahr yous...@720.fr wrote: Someone once told me that there is no such thing as dummy question so I am going to ask. Could anyone recommend a USB to Serial Converter that : - is compatible Mac OS X, - is compatible with minicom (or else), *- knows how to send breaks (the must have feature),* I have been stuck with this model that doesn't know how to end breaks, useless : http://www.trendnet.com/products/proddetail.asp?prod=150_TU-S9cat=49 I have been googling around but manufacturers documentations are very detailed about their products' capabilities. Thanks for your feedbacks. FTDI make some *very* nice cables (supports break): http://apple.clickandbuild.com/cnb/shop/ftdichip?productID=54op=catalogue-product_info-nullprodCategoryID=84 The TTL 3.3V 3.5mm 'headphone' plug ones are also nice for embedded projects, but that's getting off topic :) Cheers -- Alexander Clouter .sigmonster says: Anything free is worth what you pay for it. ___ 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] Multicast group filtering
ML m...@kenweb.org wrote: On a typical day my network can have ~500Mbps of multicast traffic flowing across a GigE cross country long haul circuit. I wanted some redundancy and I am only able to afford another 100M circuit for backup. When our primary circuit goes down I can afford to live without some of the multicast groups I normally carry. My Google-fu has turned up: ip multicast boundary and a standard ACL to deny certain groups from crossing a specific interface. 'ip multicast boundary' is useful only to stop *equally* all traffic groups from leaving your administrative domain. To effectively use this you would need to play with the TTL of your multicast sources, and that can get messy. You can just apply a bog standard outbound (if your kit supports that) ACL to both ends of your 100Mbps link that looks like: ip access-list extended mcast-basic 10 permit ip any 224.0.0.0 0.0.1.255 20 deny ip any any The alternative is to be clever (read harder) with your rp's and using: ip pim rp-address rp-ip acl ip pim accept-rp rp-ip acl Another approach would be to do QoS (rate-limiting the multicast ranges you do not want) on the uplink. What effect will this have on the CPU for routers that can't build SPF trees for the groups I deny? I've seen my router CPUs spike to 99% when the RP is unreachable. I think you need to look at something like: mls rate-limit multicast ipv4 non-rpf 100 10 mls rate-limit multicast ipv4 partial 250 100 The reason is that *all* your multicast packets get punted up to the CPU that takes a bit of time to then realise that as it is multicast traffic, you cannot send an ICMP reply...it then gets dropped. Adding these lines rate limits the number of homeless multicast packets that get shovelled up to the CPU. The main time that we saw this was on our backup router when someone fired up Norton Ghost :-/ Cheers -- Alexander Clouter .sigmonster says: Drinking is not a spectator sport. -- Jim Brosnan ___ 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] Mixing PFC3B and DFC3A with 10G linecards / 6500
Asbjorn Hojmark - Lists li...@hojmark.org wrote: Are there any gotchas with running the 10G linecards in this box in this condition? There's MPLS, as mentioned, but there are other minor differences as well. No mac classify-packet either...which has bitten me, for those wanting to use 'mac access-list's. Cheers -- Alexander Clouter .sigmonster says: YOW!! The land of the rising SONY!! ___ 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] Multicast Core
Phil Mayers p.may...@imperial.ac.uk wrote: On 16/03/10 17:04, Adrian Minta wrote: 3750G will not handle this becase multicast routing is done in CPU. I believe the first switch that do multicast routing in hardware is 6500. I don't think that's true. I think 3750s do multicast in hardware. Ours definiately do, otherwise I would imagine all that IPTV traffic on our network would be crippling them...plus they probably would not be all idling at 2%. Cheers -- Alexander Clouter .sigmonster says: This report is filled with omissions. ___ 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] Multicast Core
Tony Bunce to...@go-concepts.com wrote: Ours definiately do, otherwise I would imagine all that IPTV traffic on Are you using the 3750s for layer3 or just layer2? If just layer2 what are you using as your as your multicast router? Mixed, but generally L3. The uplink links are port-channel'd 'hybrid' L2/L3 links: interface Port-channel1 switchport trunk encapsulation dot1q switchport trunk native vlan 979 switchport trunk allowed vlan 127-130,901,979 switchport mode trunk ip arp inspection trust ip dhcp snooping trust end The native VLAN carries all the L3 routing and thus obviously also the multicast traffic up to the access layer. FYI, VLAN's 127-130,901 are the L2 and RSPAN bits, but those carry next to no multicast traffic. ...but the 3750 can do stacking. Cross stack channel bonding is *very* nice. We use it for our servers and our uplinks with great success; especially handy when you want to be clever with your UPS and hook up half of your stack to the UPS feed and the other to raw mains. Cheers -- Alexander Clouter .sigmonster says: Sorry. Nice try. ___ 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] SMTP
Mohammad Khalil eng_m...@hotmail.com wrote: we have a lot of our customers that are uses SMTP servers other than our own server which causes the subnet to be black listed My guess is that you are not cleanly labelling your IP space which means the jobs of the people maintaining blacklists have no idea about the IP usage of your network. As they have no information, and I guess you might ignore your abuse@ mailbox, you get a /24 listing after repeat offences. You need to give your customers IP space clear and up-to-date reverse DNS (PTR) records and where possible detailed WHOIS information on your address allocations. This means that when one of your customers is blacklisted the maintainer has information available to them to make a more targeted listing. I imagine at the moment your WHOIS space probably just says this /20 is ours, rather than this /26 belongs to company X which makes up part of our /20 allocation? You then need to pro-actively monitor (typically blacklisting only occurs if you ignore your abuse@ mailbox to be honest) all the main blacklists and act when you see a listing and deal with the problem. we tried to block them from accessing any other SMTP server except our own server using access lists on our core routers it works fine but is that the optimal solution for that?? is there any other ways to do that ? It's a solution, however if you are dealing with business customers you are only likely to end up annoying them. Watch of the following excellent presentation for hints on how to do things properly: http://tinyurl.com/yb5zt4f And the slides are at: http://www.cl.cam.ac.uk/~rnc1/talks/090401-emailspam.pdf Cheers -- Alexander Clouter .sigmonster says: It is better to have loved and lost -- much better. ___ 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] SMTP
Hi, * Drew Weaver drew.wea...@thenap.com [2010-03-15 13:01:31-0400]: What is stopping service providers having a bunch of perl scripts that daily check when IP's they are responsible for get listed? It should be simply an extension of their NMS platform. Once you have detailed WHOIS/PTR records you at least have something to point out to the postmasters, and the blacklist maintainers, to say hey next time do *your* jobs properly. :) Er, are you serious? Yes. Sending 90,000 DNS queries to all the different RBLs on a daily basis is an easy way to get banned your network banned. Doing that is obviously stupid, however I did not tell you to launch a DoS on a RBL :) To me, it is not asking too much of people to look at re-purposing the blacklists they are using already? As you seem to be in the $WE_PUSH_PACKETS biz I guess you *might* already have an rsync feed to spamhaus given your size? Obviously this rule does not apply to everyone, but I do not see why not? Another option is that UCEPROTECT/spamhaus and others seem to provide a subscribe to notifications when we list you service. This obviously is sub-optimal as it revolves around the concept that every postmaster-and-their-dog have to opt-in to be told about their own network rather than vice versa. To be honest, as all the postmasters and their mutts have already manually opted in to various blacklistings, plus postmaster worth their salt is regularly reviewing their logs and visiting the blacklist sites, whilst on the page hardly a huge chore to subscribe to notifications too. Once subscribed you are then looking at procmail/sieve recipes to do some of the hard work (work out which customer is abusing their AUP, automatic linkies to RRD graphs for the user, PPP history, etc etc) Roaming off the spam track, there are plenty of downloadable lists out there already. Emerging Threats, Malware Domains, ZeuS tracker, various Honeypot projects, etc etc. Is it really asking too much of service providers to munch through those too? Cheers -- Alexander Clouter .sigmonster says: Most people deserve each other. -- Shirley ___ 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] SMTP
Hi, * Drew Weaver drew.wea...@thenap.com [2010-03-15 12:18:01-0400]: Entities such as Senderbase and UCEPROTECT don't even use WHOIS information so that point is irrelevant. ...entities such as ISP's and mail server administrators do maintain their own lists too so I think stating the point is irrelevant is a tad OTT. :) In the case of Senderbase/UCEPROTECT, I got the impression it is the postmaster's 'crime and punishment' for using those lists in a boolean OK or REJECT fashion; much like those fools that want to outright trust spamcop? That is putting aside the question of 'quality' in regards to those lists. Most people now-a-days don't report SPAM to abuse@ addresses because they're either lazy or assume nobody is listening. Well I personally still enjoy the warm feeling of my 10% disconnected for AUP violation success rate. I do understand where you are coming from though on this. I will admit, I do not wear the postmaster hat, but as a packet pusher I do use route blackholing for the unsavoury parts of the Internet[1]. Without detailed WHOIS, abuse@ or PTR information I have no way in which to *whitelist* blackholed regions...once whitelisted on my LAN I can work with the blacklist maintainer to get them delisted. Those people who choose not to have detailed PTR/WHOIS records should not expect people like me, who silently work on your behalf, to get them whitelisted. We're getting into a 'list first, don't ask questions later' scenario which is very frustrating for service providers. Which then calls for an alternative strategy... What I find frustrating is that service providers are not willing to pro-actively monitor their network for egress 'filth'. I personally cannot believe that the RBN actually do have 6500+ IP ranges that they lurk on...I pro-actively whitelist and feed that information back to the maintainers. What is stopping service providers having a bunch of perl scripts that daily check when IP's they are responsible for get listed? It should be simply an extension of their NMS platform. Once you have detailed WHOIS/PTR records you at least have something to point out to the postmasters, and the blacklist maintainers, to say hey next time do *your* jobs properly. :) Hell, Turknet should be sending me some bottles of Raki for getting one of their /16's turned into a handful of /32 listings. :) /rant Cheers [1] http://www.digriz.org.uk/route-blackholing -- Alexander Clouter .sigmonster says: Unix soit qui mal y pense [Unix to him who evil thinks?] ___ 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] SMTP
* Alexander Clouter a...@digriz.org.uk [2010-03-15 16:53:12+]: [snipped] Hell, Turknet should be sending me some bottles of Raki for getting one of their /16's turned into a handful of /32 listings. :) That was meant to be TurkTelekom and a /17...incase there is some Raki out there for me :) Cheers -- Alexander Clouter .sigmonster says: If you're not careful, you're going to catch something. ___ 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] SMTP
Alexander Clouter a...@digriz.org.uk wrote: Sending 90,000 DNS queries to all the different RBLs on a daily basis is an easy way to get banned your network banned. Doing that is obviously stupid, however I did not tell you to launch a DoS on a RBL :) [snipped] Scrub that, this is far too much effort. Layer-4 route-map into your own UNIX box running some kinda of Net::Pcap perl script that munches egress initial SMTP chit-chat. As soon as you get to DATA, stop looking at that TCP stream. If you see a REJECT then record it somewhere and use it to catch the problems as they happen. The result, you do not need to subscribe, munch or pay attention to *any* RBL services. The hard work/expense has already been done by the SMTP server that is rejecting your userbase. Cheers -- Alexander Clouter .sigmonster says: He who laughs last didn't get the joke. ___ 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 irregularities.
Peter Rathlev pe...@rathlev.dk wrote: SNMPv2-SMI::mib-2.17.4.3.1.1.164.186.219.22.153.81 = Hex-STRING: A4 BA DB 16 99 51 This MAC address is strange though. :-) ...or it just means he has a Dull machine on the VLAN. http://standards.ieee.org/regauth/oui/oui.txt Unless you meant it should be non-x86 filth, in that case I agree with you completely :) Cheers -- Alexander Clouter .sigmonster says: Do I have a lifestyle yet? ___ 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] ntp scaling
Nick Hilliard n...@inex.ie wrote: Offhand no, but why on earth would you want to use a sup720 as an NTP time server? ...because it is a box typically in the core of the network that is probably already always available and sync'ed up to the world. No harm in letting it distrubute the time to the servers/switches on the LAN rather than increasing your workload in maintaining a one or two dedicated boxes (including the juice and possible OS hassles). Cheers -- Alexander Clouter .sigmonster says: Ahead warp factor 1 -- Captain Kirk ___ 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] context firewall
Jason Giles jgi...@e-dialog.com wrote: The big issue I have with the FWSM, and for that matter the whole cisco firewall line is that in Multi-Context mode you cannot run any routing protocols like you can in single context. There are way to work around this, but none of them were ideal in my topology. v6 already has been mentioned, but also multicast is a non-goer too in a multi-context lifestyle. Cheers -- Alexander Clouter .sigmonster says: Love thy neighbor, tune thy piano. ___ 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] SXI3 sensor reports changing through the day...
Peter Kranz pkr...@unwiredltd.com wrote: Ever since moving to 12.2(33)SXI3, I've seen a somewhat regular appearance and then later disappearance of a selected list of sensors on SUP-7203BXLs I have a ticket open with Cisco on this and am seeing it too...contact me off list. We first saw it with rancid and I have been working with them to acknowledge it. Curious, do you have any 10GbE modules? Cheers -- Alexander Clouter .sigmonster says: Mother Earth is not flat! ___ 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] IPV6 again
Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: [snipped] worse, stateless configuration, whilst in a way elegant, hardly anything gets handed over to iteg DNS or NTP information . theres also no way to hand over any encrpytion or seed things eg for SeND - we've been in chats with people about getting some nice extensions into the stateless RFC - it'd be good/useful to have these things sorted. DNS is via RFC5006 (if your client supports it, however for now stateless DHCPv6 can give you that) and NTP should be discovered via multicast...like most other services. Cheers -- Alexander Clouter .sigmonster says: I will never lie to you. ___ 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] PXE not working on Cat2948
Jens Neu jens@biotronik.com wrote: I have a Catalyst 2948G which seems to keep PXE boot from working properly. This one Cat2948 is the only Layer 2 device between the DHCP/PXE boot server and the PXE client - both are directly connected and share a /24. PXE boot is not working at all, and DHCP is unbearably slow, for no apparent reason. Both PXE Server and Client(s) are various IBM xSeries using the onboard GBit interfaces. Now the fun stuff: when I put a second Layer 2 device between the Cat 2948 and the PXE client, it is magically working. Means: PXE Server - Cat 2948 - some cheap Netgear Office switch - PXE Client == works. In fact, any additional Layer 2 device that appears between PXE Client and the Cat 2948 scares the problem away. Anyone seen this before? Any hints where to start looking? The switch looks as follows: .'spanning-tree portfast default'? The PXE times out before the STP action has finished and the port is in blocking mode for the duration. You should also consider 'spanning-tree portfast bpduguard/filter default' too. Cheers -- Alexander Clouter .sigmonster says: That's what she said. ___ 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] RSA and rancid
Dirk-Jan van Helmond c-...@djvh.nl wrote: Don't use RSA authentication for automated processes? Use local accounts, or if your devices support it SSH public keys are a handy option. To be honest you would be crazy to rely just on RSA authentication as if your RADIUS server is dead you will not be able to log into *any* of your switching infrastructure...oh your RADIUS server might be dead because of a network issue :) Also why VoIP is great, no support calls to deal with when there are problems :) So in short, you *have* to have a local backup account...even if it is only accessible via a serial console server. If the authentication isn't being sent plaintext, there is no added security in using one time passwords for automated processes. I have to take grumblings against that. OTP's go a good way to stop bruteforce attacks[1] and also goes a long way to *prove* that the person logging in has not had their credentials p0wned. Cheers [1] well if you are using naff pincode jobs (RSA or HOTP for example), then maybe it is pointless not but rfc2289 is rather good -- Alexander Clouter .sigmonster says: Girls are better looking in snowstorms. -- Archie Goodwin ___ 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] Can Ping Websites but cannot browse.
Hi, * Dale Shaw dale.shaw+cisco-...@gmail.com [2009-11-03 11:18:01+1100]: On Tue, Nov 3, 2009 at 1:26 AM, Alexander Clouter a...@digriz.org.uk wrote: It is a pretty impressive [read: hard/unusual -- Ed.] to screw up non-SSLed traffic with an MTU issue, In Opposite Land? or in a land where IPSec and PPPoX don't exist? :-) Well at $ORK[-1] I was an ISP packet pusher and there all those 'factory default'ing 1492 MTU routers that blocked all ICMP traffic used to drive us mad. There regular HTTP traffic was always fine[1] as the request always fitted with no problem within a single MTU...it was only when you slapped on some SSL action (or tried to SMTP something about) that the MTU issue would appear. So 'opposite' land being CPE rather than core networking land...hence my you have to be a special person to have done this. Even the greatest ICMP offenders of the Internet (financial institutions) just gave up dealing with this crap and cranked all their servers to shunt their MTU to 1000ish and tinker with the MSS on the inbound TCP SYN packet. So...this is why I focused on the cannot browse websites, I personally am just stunned the helpfulness[2] of the group to such a vague question. If any of the helldeskers here said that (which they often do, *sigh*) I have to re-remind them with the public flaying... :-/ Cheers [1] back in the day when you did not have honkingly large cookies, wtf? [2] come on guys, I felt you were all much more on the ball the way you handled http://marc.info/?l=cisco-nspm=125441497832189w=2 :) -- Alexander Clouter .sigmonster says: A vivid and creative mind characterizes you. ___ 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] Can Ping Websites but cannot browse.
Phil Mayers p.may...@imperial.ac.uk wrote: bharath kondi wrote: I have a strange situation, I can browse the websites but cannot browse them. Check for MTU issues It is a pretty impressive to screw up non-SSLed traffic with an MTU issue, I would be more inclinded to think it's something else. Real Men(tm) use tcptraceroute: a...@chipmunk:~$ tcptraceroute www.google.com 80 Selected device bond0, address 195.195.131.226, port 47429 for outgoing packets Tracing the path to www.google.com (209.85.227.106) on TCP port 80 (www), 30 hops max 1 no-reverse-defined.ja.net (195.195.131.225) 0.324 ms 0.243 ms 0.241 ms 2 so-1-3-2.read-sbr1.ja.net (146.97.34.157) 0.762 ms 0.752 ms 0.750 ms 3 so-6-0-0.lond-sbr3.ja.net (146.97.33.166) 2.020 ms 2.047 ms 2.191 ms 4 te1-1.lond-ban3.ja.net (146.97.35.98) 2.345 ms 2.236 ms 2.142 ms 5 google.lond-ban3.ja.net (193.62.157.30) 2.206 ms 2.228 ms 2.218 ms 6 209.85.252.76 8.794 ms 2.399 ms 2.358 ms 7 72.14.232.134 8.328 ms 8.423 ms 8.225 ms 8 216.239.49.45 8.280 ms 8.370 ms 8.287 ms 9 209.85.243.93 13.284 ms 8.821 ms 17.787 ms 10 * * * 11 * * * 12 wy-in-f106.1e100.net (209.85.227.106) [open] 9.765 ms 9.779 ms 9.753 ms they also give a descriptive breakdown of the problem they are having, what their setup is, any logs and also what they have tried already. However this is reply to Phil not the OP... :) Cheers -- Alexander Clouter .sigmonster says: Am I SHOPLIFTING? ___ 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] filtering IPV6 for L2 bridged traffic ?
Jeff Fitzwater jf...@princeton.edu wrote: I am running SXI code on sup720-CXL and need to filter out certain IPV6 packets like MDNS on trunked L2 port? I was going to use an vlan access-map but it appears that it does not allow me to do a MATCH on an IPV6 acl, I guess I am stuck with a MAC ACL to filter bridged IPV6 traffic. Any ideas on this issue? How else can it be done? Eugh, I am having a similar problem. Seems our 3750's are blind to 'permit any any 0x86dd 0x0' and I have to RSPAN *everything* and get it filtered on the next hop...then to add to my pain it's awkward and not wholely predictable even there; on a pair of 6509's. For you however there might be a solution. Your magic cookie hint is... http://en.wikipedia.org/wiki/Multicast_address#Ethernet_multicast_addresses Enjoy -- Alexander Clouter .sigmonster says: What's love but a second-hand emotion? -- Tina Turner ___ 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 3750 Stack less disruptive EtherChannel configuration
luismi asturlui...@gmail.com wrote: We had a problem with a stack 3750 here and the configuration is.. Stack (2x3750) === FEC === SW 2960 It is a cross etherchannel configuration. 3750 is not working with L3 mode at all. The FEC config is mode on. We use 'active' as then it is using LACP and testing not just that the link is up but it is also successfully shifting packets over it; plus some other goodies. So, one the 3750 had a problem yesterday and it creates disruption in the connectivity with the 2960 switches. I didn't expect from Etherchannel. It is supossed that is pretty fast but it was not. I would like to see if there is anyone here with a similar configuration or other one to fix this situation. Any comment is welcome Depends what the disruption was, as you are all L2, if it was the VLAN instance that was affected then that would be your longer than expected outage. The Etherchannel will only protect you from link failures on the Etherchannel, not from what might be happening inside that Etherchannel. Cheers -- Alexander Clouter .sigmonster says: Oh, I get it!! The BEACH goes on, huh, SONNY?? ___ 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] send multicast over non-multicast-enabled switch
victor vi...@list.ru wrote: It indeed works through GRE though linux box doesn't want to respond to IGMP query. But I hope I'll fix it. The following usally kicks things into life: ip link set GRE_INTERFACE multicast on sysctl -q net.ipv4.conf.GRE_INTERFACE.rp_filter=0 Cheers -- Alexander Clouter .sigmonster says: When among apes, one must play the ape. ___ 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'
Hi, Dave Weis djw...@internetsolver.com 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. No experience in actually doing this but I would say no. :) There is no (or it is so small I have missed it) sharing of object data between contexts and so you will find your self spending all your time trying to keep in sync the common parts of each context. Instead you should apply simple RPF (if you do not have them already) rules so that all the IP traffic coming from your custom does come from their own allocated address space (prevent spoofing). After you have done that, each customer can just be a raw IP range on whatever (single instance) firewall platform you wish to purchase making manglement of the whole thing just feel like a regular LAN. Of course things get fun if you add multicast traffic and/or asymmetric routing :) Cheers -- Alexander Clouter .sigmonster says: ahzz_ i figured 17G oughta be enough. ___ 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] Hacking
Mohammad Khalil eng_m...@hotmail.com wrote: can i know from the log or using any other method if the router was hacked ?? When RANCID collects (or fails to collect) the configuration file off your router every day (or hour), it will compare it to the previous run and email you the differences. Those differences will show you when someone caught you with your pants down...or when someone fat fingered an amendment. Cheers -- Alexander Clouter .sigmonster says: semper en excretus ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] HSRP/multicast help
Hi, David Warner davidwarner1...@yahoo.com.au wrote: We have a requirement to provide gateway redundancy for a multicast enabled server(s) . Weve had a few issues with getting this working in a deterministic fashion. Does anyone have a working config or tips on getting multicast working in a HSRP set up? You probably are using 'standby x priority'? We had the same issue years ago. You *should* set up your VLAN's like so (example for a /24): .0 network address .1 HSRP gateway address ... workstations .253HSRP *standy* router address .254HSRP *active* router address .255broadcast address I personally remove the standby priorities from the VLAN configs as the 'active' router will be the one with the higher IP address...which is *also* the rule for PIM. What is probably happening is the PIM router for the subnet is your standby router and you are being hit with a lot of reverse path filtering issues[1]. If you really want to use standby priorities, make sure the higher number sits on the router with the higher IP addresshowever once you have done this you will wonder why If you have not already, I would use this as an opportunity to move to using HSRPv2 or VRRP...and make sure you are using a shared secret to prevent someone spoofing that they are a HSRP gateway (plus enable IGMPv3). An example for a /25 is below: one of our 6509's interface Vlan100 description test ip address 1.2.3.126 255.255.255.224 ip pim sparse-mode ip igmp version 3 standby version 2 standby 100 ip 1.2.3.1 standby 100 preempt delay minimum 120 standby 100 authentication md5 key-string ahem the other of our 6509's interface Vlan100 description test ip address 1.2.3.125 255.255.255.224 ip pim sparse-mode ip igmp version 3 standby version 2 standby 100 ip 1.2.3.1 standby 100 preempt delay minimum 120 standby 100 authentication md5 key-string ahem If you are seeing high CPU usage on your routers, you might want to add: mls rate-limit multicast ipv4 non-rpf 100 10 mls rate-limit multicast ipv4 partial 250 100 Cheers [1] or it is because the IGMP joins never reach the PIM gateway as they are going to the wrong router, I can never remember, it was years ago when we fixed this -- Alexander Clouter .sigmonster says: Philosophy will clip an angel's wings. -- John Keats ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] HSRP/multicast help
Hi, Dale W. Carder dwcar...@wisc.edu wrote: On Sep 18, 2009, at 3:04 AM, Alexander Clouter wrote: I personally remove the standby priorities from the VLAN configs as the 'active' router will be the one with the higher IP address...which is *also* the rule for PIM. What is probably happening is the PIM router for the subnet is your standby router and you are being hit with a lot of reverse path filtering issues[1]. Also, in addition to the higher ip address tiebreaker, you can set the DR priority: primary: ip pim dr-priority 4294967294 standby: ip pim dr-priority 2147483647 (or whatever) This is very helpful if someone attaches a pim speaking device and your ip addresses are at the bottom of the range rather than the top. I like it, any reason I cannot use 4294967293 on the standby? Cheers -- Alexander Clouter .sigmonster says: No solicitors. ___ 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] IPV6 in general was Re: Large networks
Phil Mayers p.may...@imperial.ac.uk wrote: No, my routers do NOT send ra. I disable it as an incredibly insecure mechanism. Fine - so point your clients statically at the virtual link-local address e.g. under Linux: ip -f inet6 route add default via fe80::the hsrp vip dev eth0 What's the problem? Well, you should be using ip route add 2000::/3 via. ;) Cheers -- Alexander Clouter .sigmonster says: Sign here without admitting guilt. ___ 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] IPV6 in general was Re: Large networks
Alexander Clouter a...@digriz.org.uk wrote: Phil Mayers p.may...@imperial.ac.uk wrote: No, my routers do NOT send ra. I disable it as an incredibly insecure mechanism. Fine - so point your clients statically at the virtual link-local address e.g. under Linux: ip -f inet6 route add default via fe80::the hsrp vip dev eth0 What's the problem? Well, you should be using ip route add 2000::/3 via. ;) Bah, stumbled on RFC3587, I take that statement back :) Cheers -- Alexander Clouter .sigmonster says: The best defense against logic is ignorance. ___ 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] IPV6 in general was Re: Large networks
Hi, * Bjørn Mork bj...@mork.no [2009-08-27 11:31:08+0200]: sth...@nethelp.no writes: Some of us would disagree rather strongly with one or more of those points. For instance, for us DHCPv6 is a hard requirement. Why the hard requirement? Is this for a MAC-IP association table? I'm working on a method (might not work mind you) to make a SLAAC network forfill this requirement...I have to so we meet our upstream AUP requirements but running DHCPv6 kinda misses the point for why you try to deploy IPv6. :) This is an old discussion, and has been rehashed a number of times on various DHCP and IPv6 mailing lists. In any case: - SLAAC cannot distribute all the parameters that DHCP distributes to customers today. Example of parameters needed: DNS servers, domain name, NTP servers, ... No it can't, but personally I see that as a feature :-) We need to publish DNS servers, but RFC 5006 solves that. The other DHCP options are mostly unecessary bloat. Are there really that many DHCP clients doing anything useful with the NTP option? I guess you may have set-top boxes using it, but those can just as well be pre-configured with the well-known DNS name of your NTP servers. Service discovery (SLP, SDP and DNS based) and multicast (NTP especially) has been with us for years. I think this is the problem people have with IPv6, their mindset is stuck in IPv4 for a lot of things. - DHCP lets us control customer address allocation from one central point, instead of having to individually configure routers. You can do that with SLAAC too, e.g. by using RADIUS. We'll of course use DHCPv6 too, mostly because we want prefix delegation. But I still think SLAAC is useful in some settings, even for ISPs. I want both. I do not think SLAAC was ever intended for the ISP-CPE, I could not see how it could be used there. However for router-node I cannot see why people are so against it. Obviously I'm in a minority so I'm going to disappear back into the Ether :) Cheers -- Alexander Clouter .sigmonster says: God isn't dead. He just doesn't want to get involved. ___ 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] IPv6 experience on DSBU switches
Hi, Janet Plato pl...@wisc.edu wrote: I'm finding IPv6 support lacking a few glaring things on 12.2(50)SE2. Things like the inability to enter an IPv6 address as a target for a radius server, or a hostname with only a Quad A record as well. When I ask Cisco, they view these things as features to be added, not bugs to be fixed. I thought IPv6 was relatively well worked out. Are other folks mostly able to get IPv6 going, or would you think it's reasonable to expect accepting an IPv6 address in a config to be a feature request? [snipped] I'm kind of shocked with the replies I am getting, and I am thinking maybe I just fail to grasp the current situation. I think you only need to look to Cisco's 'next generation' wireless offerings to answer your questions...it seems they not care too much for IPv6; their presentations say one thing, the product line and IOS's say quite a different story. :-/ You should see what plans I have to get our 3750's to make SLAAC actually accountable (in a ARP inspection-esque sense) and usable on our network... :) I think the 'backporting' of the IPv6 support in ipservices into ipbase was only because everyone 'else' supports IPv6 and Cisco were no longer able to justify the considerable markup. The sad part is that no one can get the in production experience of IPv6 because the vendors do not support it. You generally have to make do with what you can and use Linux as 'duct-tape' for the bits that are lacking... Wait till you stumble on the lack of an 'ND proxy' or 'RA guard' :) Cheers -- Alexander Clouter .sigmonster says: Generic Fortune. ___ 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] IPv6 experience on DSBU switches
Hi, * Gert Doering g...@greenie.muc.de [2009-08-26 14:09:25+0200]: On Wed, Aug 26, 2009 at 10:54:32AM +0100, Alexander Clouter wrote: The sad part is that no one can get the in production experience of IPv6 because the vendors do not support it. You generally have to make do with what you can and use Linux as 'duct-tape' for the bits that are lacking... Oh, well, it's not *so* bad. Some things are lacking, but the conclusion the box cannot do radius over IPv6 transport == not ready for production IPv6 deployment is not something I can agree to. Exaggerated definitely[1] but when Cisco's only answer for you to assign IP's (accountably) is to use DHCPv6 it's a bit of a crappy welcoming mat; not many DHCPv6 servers out there and defeats a lot of IPv6 benefits (especially now that RFC 5006 is 'here'). I expect that we'll have to run IPv4 in parallel for a few more years, and if some parts of the device management functionality is not available over IPv6 today, it won't stop us from offering IPv6 internet services... Very true, probably for the next 20 or more. Wait till you stumble on the lack of an 'ND proxy' or 'RA guard' :) Tell your account teams that you want it, and won't buy new hardware unless they deliver... Problem is in the Real World(tm) when the 'other' vendors also don't offer much needed functionality you have to make compromises and your threats become empty. :-/ Cisco is good at L2 stuff, it seems when they look much about L3 they start being a pain; probably the issues are just more easily solved for me with a pile of battered Linux boxes[2]. OTOH - Cisco has working prototypes of SeND, while no other (!) operating system out there supports it. So where's the Linux duct-tape when you need it...? Apparently Cisco has some IPv6 stuff in the works I am told, but the people telling me are all NDA'd to hell and back and cannot tell me anything'great, handy info'! Unsure why I would want to cryptographically sign my ND's, we do not control the workstations that plus into our network and I'm not dishing out client side certificates for everyone :) For the IPv4 world I have 'ARP inspection' and 'DHCP snooping' to stop people doing stupid things[4], in the v6 world it seems I have to use 802.1x and Linux duct-tape. All I want is something similar in the v6 world, but it needs to support SLAAC (with privacy extensions) and multiple addresses per host...QoS throttling and 'ND inspection' would give a 99% solution this without the whole load of IPsec dumped upon us. Without this, we pretty much are still stuck in the mindset of IPv4 when deploying our IPv6 services. Accepting that 'crap' is going to happen on your network whatever you do to try and stop it seems to have been a pointless endeavour for years. Having a good audit trail and event driven monitoring/alerting has been far more helpful for *us* (plus better use of our time deploying because of it's other non-security related benefits) and means we do not have to plug *every* hole in our network when we come to the finding out what happened and the lessons learned phase of an incident. Then, I'm only starting out in the v6 world...from an early start I do know that Cisco is not making my life any easier and until recently I had to pay a premium to even *look* at v6 on a 3750. Just my £0.02...keep the change ;) Cheers [1] well, their WLC 4400's (and it seems the 5500's) cannot do any L3 v6 stuff which means we cannot deploy it accountably on our wireless network [2] I'm still coming to terms with a 3750 being unable to shift more than 20Mbit's of IPIP/GRE tunnel[3] action as it's all done in software. [3] hmmm, and in SXI3 their 6509's still suck with multicast over IPIP tunnels forcing you to use GRE tunnels :-/ [4] the *majority* of problems on the network here are not from attackers but -- Alexander Clouter .sigmonster says: Edited for television. ___ 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] IPV6 in general was Re: Large networks
Hi, Scott Granados gsgrana...@comcast.net wrote: I'm interested in general, how much IPV6 is actually out there? I'm very unfamiliar but at my present gig and my last few I never ran in to this once. Is it actually being used in production? Ironically I would suggest Google...which it's-self is IPv6 enabled. It's not the 'enabling' IPv6 in the network that's the awkward bit, it's trying to eject the mindset that IPv4 puts you in... With IPv6 you can get rid of DHCP, forget VPN's, forget DDNS, forget HSRP, and most importantly you no longer need NATs that understand every protocol that runs through it and so remove a possible single point of failure. By tinkering you find out what horrible kludges are in IPv4[1] and slowly untie your brain from thinking in that manner. You quickly discovery what tpye of straightjacket IPv4 put us all in. In short, it's how the Internet is meant to run. Google themselves say it has simplified things internally for them. Besides, I though Comcast was rolling out IPv6 next year to all it's DSL users? Other production cases are the smattering of ISP's about with it everywhere and of course free.fr. Cheers [1] for the OS knowledgable people, it is akin to UNIX compared to Plan9, just without the cute logo of course -- Alexander Clouter .sigmonster says: Is it clean in other dimensions? ___ 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] IPV6 in general was Re: Large networks
sth...@nethelp.no wrote: With IPv6 you can get rid of DHCP, forget VPN's, forget DDNS, forget HSRP, and most importantly you no longer need NATs that understand every protocol that runs through it and so remove a possible single point of failure. Some of us would disagree rather strongly with one or more of those points. For instance, for us DHCPv6 is a hard requirement. Why the hard requirement? Is this for a MAC-IP association table? I'm working on a method (might not work mind you) to make a SLAAC network forfill this requirement...I have to so we meet our upstream AUP requirements but running DHCPv6 kinda misses the point for why you try to deploy IPv6. :) If it's for service discovery, that should be via DNS or better still multicast. However I would kill for PXE booting IPv6, no practical reasoning there though. Cheers -- Alexander Clouter .sigmonster says: Avert misunderstanding by calm, poise, and balance. ___ 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] RES: IPV6 in general was Re: Large networks
Hi, Leonardo Gama Souza leonardo.so...@nec.com.br wrote: Why can we forget about HSRP with IPv6? Depending on how 'high' the 'H' is in your HSRP, you can have multiple routers on the same subnet to provision your default gateway to the world, the clients *should* just use the responsive one if one was to disappear. Cheers -- Alexander Clouter .sigmonster says: I'm not proud. ___ 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] IPV6 in general was Re: Large networks
Hi, Daniel Verlouw dan...@bit.nl wrote: On Aug 26, 2009, at 9:18 PM, sth...@nethelp.no wrote: [snipped] No VPNs? What about host-to-host IPSec VPNs (e.g MS DirectAccess)? I should have said VPN concentrator. Mobile IPv6 and finally the end-to-end-ness of IPv6 lets use use IPsec finally in it's transport mode as 'God' intended. Cheers -- Alexander Clouter .sigmonster says: Wanna buy a duck? ___ 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] Long Uptime
Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: [snipped] ..some might wonder why routine upgrade/patching windows are not being undertaken..a resilient linkage scheme and equipment list should mean that eg a router or switch can be taken out even in middle of day should out of hours work be a non-entity :-| In a phrase risk assessment. The risk of being h4ck0r3d probably in many situations might be considered lower than the risk of someone having a larger todger^Wuptime. Cheers -- Alexander Clouter .sigmonster says: BOFH excuse #248: Too much radiation coming from the soil. ___ 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] Arp Inspection Rate Limit
Hi, nm...@guesswho.com wrote: Thanks for the response. Funny you mention the print server because that happens to be one device port I need to tweak since it occasionally exceeds the 15 pps. We have been fine at 10 for over a year now[1], however it took us a while to figure out that for some bizarre reason[2] 'File and Print Sharing' being enabled actually caused the workstation to flood ping the local subnet looking for printers everytime someone pressed Print on their workstation. Similar thing happens under Vista only when you want to add an IPP printer by hand :-/ Cheers [1] we are a university with about 600 staff and 3000 students [2] might be linked to Novell being installed too, but who knows -- Alexander Clouter .sigmonster says: There's enough money here to buy 5000 cans of Noodle-Roni! ___ 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] Upgrading IOS core on a 3750 Stack
Peter Rathlev pe...@rathlev.dk wrote: On Sun, 2009-08-02 at 06:18 -0700, Bill Blackford wrote: The subject line says it all. I have some questions regarding how the upgrade works. 1. Do I only upgrade the master? Technically no, but the master might be able to auto-upgrade the members. There is a whole 'licencing' question issue. You can get ipservices into your network slightly cheaper if you put ipservices on the master and ipbase on the other stack members. Then you just hope the master does not die as everything will then drop to ipbase...apparently. All of our 3750's run the same IOS and you have to copy it to each flash area seperately. One hint is you can copy from flash-flash which savessome finger wear and tear. 2. If not, how do I upgrade the other switches in the stack? You can upload software to flash1:, flash2: etc. and set the boot variables with boot system switch 2 flash:/asdf.bin. Remember that each switch sees the flash as just flash: when booting, so set the boot variable accordingly. Hmmm, we run ours with 'no boot system switch all' and the switches pick up the IOS on the flash automatically. As you can only fit one IOS on the flash anyway. Cheers -- Alexander Clouter .sigmonster says: The man who runs may fight again. -- Menander ___ 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] Mac OSX WakeOnLan
Christina Klam ck...@ias.edu wrote: We have been trying to get WakeOnLan for Mac OSX to work reliably across subnets without success. I have added ip directed-broadcast [access-list#] to the interface VLANs for those buildings/users with Mac Minis. However, it works only part of the time. On the same switch, some Minis work all the time, while others work only part of the time. I have done a a couple of packet capture but nothing jumps out at me. In addition, using the cable-diagnostics tdr on the switches, I have verified that all of the cabling is good. We are using Cisco 3750G/E stacks (version 12.2(44)SE1) and Cisco 4507R-E (cat4500e-ipbasek9-mz.122-46.SG.bin). We are 12.2(50)SEish Anyone else had similar issues? Not bothered trying to wake up the fruits here, but PeeCee's have been sulking. I thought it was just typical borked Dull kit however even packet sniffing off the port I fail to get the magic packets. That on the same switch on other identically configured ports it works :-/ We have the 'extra fun' of it being an 802.1X port but the 'dot1x direction in' bits are in there and it *can* work...occasionally. From my experience, I don't have hard and fast info and it was a while back, the issue is linked to the switch thinking there is no spanning tree edge port action. You can see a difference on working/non-working ports when you type 'show dot1x int whatever detail' and querying about what spanning tree is making of the situation too. Sorry it's all vague, I looked into this about three months ago (when we were using 12.2(44)ish) and it's on my books for revisiting this summer. At least you know you are not alone :) Cheers -- Alexander Clouter .sigmonster says: 42 ___ 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] ipv4 link-local for eigrp
Hi, After an organisational switch refresh last year we have been fortunately enough to end up with surrounded by nothing but 3750 stacks (c3750-ipbasek9-mz.122-50.SE1.bin) at the edge of the network; the core is made up by a pair of 6509's (s72033-ipservicesk9-mz.122-33.SXI.bin). As we were overhauling the network we decided to have some fun and rollout L3 to the edge to obliterate spanning-tree where-ever we can. As Cisco boxen are a pain and don't let you have true 'hybrid' L2+L3 links (we still have some L2 action at the edge) and assign IP addresses to trunk links we use 'native' VLAN's to route the L3 stuff through the link. This all works great and we are happy with it, however now things are working, I hoping to now have a 'lessons learned' fixup of the bits that niggle at me. This ties in with the IPv6 rollout we are doing over the next few months and I thought it's worth fixing up the IPv4 stuff at the same time. The biggest issue is all the rfc1918 usage used in the /30 used to force the L3 routes out to the edge of the network which make traceroutes ugly. I really do not want to put aside publicly routable addresses that are just used to pass EIGRP data around, as that would involve soaking up over 50 /30's, a bit of a waste. So what to use, I am pretty keen to use link-local IPv4 addresses (169.254.0.0/16) much like I plan to for IPv6 to build up the L3 point-to-point links and they are perfect for this situation. The downside is that I run into the following issues: 1. 169.254.0.0/16 can start to appear in the distributed EIGRP listings 2. traceroutes have 169.254.0.0/16 addresses in them 3. 169.254.0.0/16 is pingable by edge hosts as the switch they are plugged into knows of at least one 169.254.0.0/16 address. These addresses should never escape the local subnet Now apparently I can solve the first issue by properly fixing up the way we use EIGRP, possibly involving liberal use of 'ip prefix-list' filtering or something similar? There is *very* little online about if the second issue can even be solved on Cisco kit, but I did stumble on a suggestion to use NAT/route-map's (that would work perfectly for us as the Loopback0 interface on are kit is a non-rfc1918 address): https://cisco.hosted.jivesoftware.com/message/4910 I could not get this to work, but I was only tinkering with it for a couple of hours. If only IOS had a 'ip icmp source interface...' command :) I do have no idea on how I could fix the third issue or if it is even possible. I would have hoped the kit would have a way to say don't route where the source, or dest, IP address is in this ACL list. I guess I could build ACL lists and place them on all the edge switches and just throw these packets into oblivion, however that would not be a global setting, instead a messy per-vlan settings surely? So, I'm hoping someone can make any suggestions on how I could go about doing this. Suggestions on how to tackle all three issues would be great as I'm not 100% on that I do know how to solve the first two issues. Has anyone else done or heard of anyone using local-link addresses for routing between...erm...routers and then fixed the ICMP issue. Even if the advice is well if you had xy software you could do z. Thanks in advance for any clue you can impart onto me. Cheers -- Alexander Clouter .sigmonster says: The life of a repo man is always intense. ___ 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] ipv4 link-local for eigrp
Alexander Clouter a...@digriz.org.uk wrote: [snipped] So what to use, I am pretty keen to use link-local IPv4 addresses (169.254.0.0/16) much like I plan to for IPv6 to build up the L3 point-to-point links and they are perfect for this situation. The downside is that I run into the following issues: 1. 169.254.0.0/16 can start to appear in the distributed EIGRP listings 2. traceroutes have 169.254.0.0/16 addresses in them 3. 169.254.0.0/16 is pingable by edge hosts as the switch they are plugged into knows of at least one 169.254.0.0/16 address. These addresses should never escape the local subnet I see in the archives the first two points have been lightly touched upon before, with prefix-list filterings and some NAT. Of course I'm interested in other possible solutions or sound advice. Cheers -- Alexander Clouter .sigmonster says: Manoj I *like* the chicken ___ 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] ipv4 link-local for eigrp
Gert Doering g...@greenie.muc.de wrote: Hi, On Sat, Jun 20, 2009 at 01:50:43PM +0100, Alexander Clouter wrote: The biggest issue is all the rfc1918 usage used in the /30 used to force the L3 routes out to the edge of the network which make traceroutes ugly. I really do not want to put aside publicly routable addresses that are just used to pass EIGRP data around, as that would involve soaking up over 50 /30's, a bit of a waste. So what to use, I am pretty keen to use link-local IPv4 addresses (169.254.0.0/16) much like I plan to for IPv6 to build up the L3 point-to-point links and they are perfect for this situation. Using 169.254.x addresses is no better or worse than RFC1918 addresses. Well yes, I agree but... Just don't go there. If your routers are going to source packets from those addresses (traceroute responses or - much worse! - ICMP packet too big messages), use public addresses. That's what they are there for. I just don't want to burn public routable addresses on point-to-point links needlessly when there is a perfectly good routable address on Loopback0. These link are there just to steer traffic down and distribute routing tables, the kit should not be responding with these addresses for anything...I don't want them to. I was hoping someone knew of some cunningness and/or magic trick I could call upon? On non-ethernet point-to-point links, you could use ip unnumbered... Alas, it's all Ethernet here. Cheers -- Alexander Clouter .sigmonster says: To err is human, but I can REALLY foul things up. ___ 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/
