Re: [c-nsp] 3750G vs. Nexus for a SAN
- Nick Hilliard n...@inex.ie wrote: Incidentally, if you're planning to use the N5K as a fancy 1G switch, note that the system will change the switching mode from cut-through to store-n-forward for GE ports; cut-through is only supported for 10G transceivers. This may matter for iSCSI. Looking at the specs an alternative would be a central 5010 and two 2148 FEX as top-of-rack 1G. Using up to 40 of the 1G ports and 4 x 10G for uplink to N5K would make it line-rate, right? Has anyone got any experiences with this setup? Arne ___ 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] RSA and rancid
Mark Meijerink mark.meijer...@sara.nl writes: Is anyone of you using RSA tokens and rancid? If so, please explain how you make this work. Thanks in advance for your comments. Friend of mine told me that a combination of a web cam, fuzzyOCR and some Perl code is working fine for token based auto logins. I haven't worked with RSA tokens for a long while but I think there was an option to not use a token for logging in. HTH Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jensl...@guug.de | - ___ 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] uRPF bug on C6k SXI1?
Peter Rathlev wrote: Hi Phil, Thanks for the input. On Tue, 2009-11-10 at 13:23 +, Phil Mayers wrote: Do you have CoPP or MLS rate limiters? Is the traffic being CPU punted (use a SPAN session to find out) and this rate-limiting what's causing the drops? No CoPP or rate-limiters configured, only defaults. Is there any way to see counters for the rate-limiters? The show If so, it could be a hardware/tcam programming error; we've seen a few of these in obscure cases on SXI, and I've not found a reliable way to clear them. Does a shut / no shut of the SVI fix the problem? Or the various clear commands (e.g. clear cef etc.) Well, I tried shutting/unshutting the SVI, and now I can't seem to recreate the problem. :-( Yep, that sounds familiar. We've seen the problem with dodgy CEF prefixes suddenly go away when SVIs are shut/no shut. Someone suggested the next-hop MTU getting set wrong in the hardware and causing CPU punts, and that this can happen when SVIs come up/down very occasionally :o( If I remove the ip verify-command and then add the version with allow-default directly, I have no problems. Without uRPF there's no problem either. Only when first entering the command without allow-default and then adding allow-default does the problem appear. We haven't seen that, but have seen other issues where (apparently) CEF entries are programmed incorrectly resulting in traffic being CPU punted and having to pass through CoPP, and thus being very lossy. I would really like to have looked more into this, but with the problem gone, I'm stuck: If it would happen again, is there any way to check what the rate-limiters/CoPP drops via some counters? Well, CoPP drop can be see with: sh policy-map control-plane ...but if you haven't got it setup, you'll see nothing. sh mls rate-limit ...shows the current config for MLS rate limiters, but again if you've not got it setup then the defaults are some pretty conservative multicast punts and nothing else IIRC. Hmm. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] VPLS and SSTP or STP
HI guys, Just a quick question. Here's my context --- CPE1--*QinQ + L2PT port* (7600)--VPLS---(7600) *Trunk port* --NNI-CPE2 CPE1 and CPE2 run PVST+ and both 7600 don't run any STP On QinQ + L2PT port (7600), i ran a debug netdr and: - i can see PVST+ traffic coming CPE1 - i can't see PVST+ traffic coming from CPE2 ((from (7600) Trunk portChassis) On (7600) Trunk port, i ran the same debug, debug netdr and: - i can see L2PT traffic coming ((QinQ + L2PT port (7600)) originated from CPE1 My question is on a *basic Trunk port* (as above facing CPE2), How VPLS should handle those SSTP BDPUs (01:00:0C...CD) ? Apparently they're dropped, and only untagged STP BPDU 01:80.. are allowed. IMPORTANT: the NNI VLAN is already double tagged. Any thoughts would be appreciated tks Sam ___ 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] Different CPU load on two 7206VXR-NPEG2
Packet fragmentation and re-assembly on one path to one of the sites could explain it. Maybe 'show ip traffic' could glean some useful information. -- Ben ___ 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 fragmented packets on SUP720-3BXL
On Tue, 10 Nov 2009, Gert Doering wrote:
No. Routers will never reassemble transit traffic.
Never is a strong word. It seems ip virtual-reassembly do it. It looks
like it at least reassembles them in memory and delays them before
forwarding them (as fragments) from the debug and counters. On a
virtual 7200:
Router#show ip virtual-reassembly fa1/0
FastEthernet1/0:
Virtual Fragment Reassembly (VFR) is ENABLED...
Concurrent reassemblies (max-reassemblies): 16
Fragments per reassembly (max-fragments): 32
Reassembly timeout (timeout): 3 seconds
Drop fragments: OFF
Current reassembly count:0
Current fragment count:0
Total reassembly count:23
Total reassembly timeout count:3
Not that you'd want to do it, but still.
-
typedef struct me_s {
char name[] = { Thomas Habets };
char email[] = { tho...@habets.pp.se };
char kernel[]= { Linux };
char *pgpKey[] = { http://www.habets.pp.se/pubkey.txt; };
char pgp[] = { A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854 };
char coolcmd[] = { echo '. ./_. ./_'_;. ./_ };
} me_t;
___
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 fragmented packets on SUP720-3BXL
On 2009-11-11 12:00, Thomas Habets wrote: On Tue, 10 Nov 2009, Gert Doering wrote: No. Routers will never reassemble transit traffic. Never is a strong word. It seems ip virtual-reassembly do it. It looks like it at least reassembles them in memory and delays them before forwarding them (as fragments) from the debug and counters. On a virtual 7200: Sure. But that functionality is not found on core routers, but on border routers running CBAC/ZBFW or IPS functionalities, that need a whole packet to do it's work on it. As Gert noted, fragmented IP packet is forwarded in hardware (or normally) as long as it contains valid header information. -- Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco 12000 Series Packet over SONET/SDH (POS) Line Cards (2-Port OC-192c POS )
Hi, I am planing to use Cisco 12000 series Two port OC-192 line card. I would like to have some feedback on this line card. This line card supports Synchronous Digital Hierarchy (SDH). Does any one configured it as Gig enabling WAN. I used SPA-1x10GE-WL-V2 on 12000-SIP-600 as 10Gig enabling WAN. So I am trying to check if 2-Port OC-192c POS can also be configured for 10Gig enabling WAN. Cheers. Pratap. ___ 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] What's the value of ASA/FWSM TCP state bypass?
Roland, iatrogenic. induced inadvertently ... http://www.merriam-webster.com/dictionary/IATROGENIC It is not often I have to look up a word on this board. Well played sir. On Tue, Nov 10, 2009 at 6:31 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Nov 11, 2009, at 4:26 AM, Peter Rathlev wrote: I've read about this, but I fail to see what the point is. The point is that there shouldn't be firewalls in front of servers in the first place, given that every packet which comes in is unsolicited and therefore the stateful inspection is both completely obviated and forms a DDoS chokepoint; and yet folks have been so conditioned by security snake-oil marketing to put firewalls in front of their servers that they do it anyways, complain to their vendors when said firewalls fall over with relatively small amounts of traffic due to state-table exhaustion, and thus need a way to disable the stateful inspection they paid so much to achieve so that they can still claim that they've a firewall in front of their servers, even though said firewalls are iatrogenic in nature. ; Folks should do as you say, hardening their servers/apps/services, enforcing policy via stateless ACLs in hardware, and deploying reaction tools such as S/RTBH. Firewalls in front of servers is generally a Bad Idea, period. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken ___ 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/ -- Gregory Wendel Springfield VA, 22153 ___ 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
On 11/11/09 6:03 AM, Jens Link li...@quux.de wrote: Mark Meijerink mark.meijer...@sara.nl writes: Is anyone of you using RSA tokens and rancid? If so, please explain how you make this work. Thanks in advance for your comments. Friend of mine told me that a combination of a web cam, fuzzyOCR and some Perl code is working fine for token based auto logins. I haven't worked with RSA tokens for a long while but I think there was an option to not use a token for logging in. If you are running an ACS/TACACS+ server on the back end you should be able to specify local-database authentication for your Rancid user and RSA token for everything else. Regards, Mike ___ 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 fragmented packets on SUP720-3BXL
There is nothing special about *forwarding* fragmented packets - unless you have an ACL or anything else that wants to look at Layer 4 info. That would be Netflow or some QoS policy attached to the interface, for instance? I guess the router should reassembly the fragmented packets before applying any policing on the traffic arriving on the interface... Am I right? It assumes that any fragment matches clauses with L4 info, because it lacks stateful context from the first fragment to eval it. Rubens ___ 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 12000 Series Packet over SONET/SDH (POS) Line Cards (2-Port OC-192c POS )
On Thu, 12 Nov 2009, Pratap Reddy wrote: Hi, I am planing to use Cisco 12000 series Two port OC-192 line card. I would like to have some feedback on this line card. This line card supports Synchronous Digital Hierarchy (SDH). Does any one configured it as Gig enabling WAN. I used SPA-1x10GE-WL-V2 on 12000-SIP-600 as 10Gig enabling WAN. So I am trying to check if 2-Port OC-192c POS can also be configured for 10Gig enabling WAN. No, it's Packet over Sonet using HDLC or PPP, it doesn't do ethernet at all. Also, it requires 12800 upgrade/fabric to work (if it's the old Engine6 card you're referring to). PS. I interpreted 10Gig enabling WAN as 10GBASE-LW (WANPHY), if it's something else then all bets are off. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
