|
routenull0 posted:So it looks like Cisco changed the CCIE stuff a bit from what I remember. It use to be you have to attempt the lab within 12mhts of passing the written, if you failed, you got another 18mths. If you failed the 2nd attempt, you had to re-take the written. Have some faith! Which vendor are you using for your preparation? INE, IPe, Narbik, etc.? How long have you been preparing?
|
#
?
May 10, 2013 15:44
|
|
|
|
| # ? May 31, 2024 11:39 |
|
|
BoNNo530 posted:Have some faith! Which vendor are you using for your preparation? INE, IPe, Narbik, etc.? For lab prep I am using my job  , but I have looked some at INE though for if/when I pass the written.I wouldn't really say I am "preparing" for the written though.
|
|
#
?
May 10, 2013 17:09
|
|
|
Last I looked, SRX kind've sucked for IPv6. Or at least their smaller units did.
|
|
#
?
May 11, 2013 23:31
|
|
|
I am running some of the beta SRX Firefly model (VMs) and they're great for testing/learning.
|
|
#
?
May 13, 2013 19:13
|
|
|
So for passing the CCNA I bought a Les Paul. Go me.
|
|
#
?
May 13, 2013 19:32
|
|
|
What kind of les paul?
|
|
#
?
May 13, 2013 21:59
|
|
|
Traditional Pro P90
|
|
#
?
May 13, 2013 22:17
|
|
|
That's a great present to give yourself for passing the CCNA! I like P90s, though I think most modern P90s are wound way too hot. I have a 1960 es330 that has the nicest sounding P90s I've ever heard. I have a much too large, house-consuming guitar collection that I've been trying to pare down. When you live in a 700 square foot condo, they take up an awful lot of room. Well, that and the SVT... How did you feel about the CCNA test? Pretty comfortable? Nerve-wracking?
|
|
#
?
May 13, 2013 22:22
|
|
|
I was way more comfortable with it the second time around. First time I took it I was literally yelling at my land lord to fix my AC during a 110 degree heat wave, my dad was getting emergency surgery for pancreatic cancer, and I was going through a divorce with a knife wielding drunk. Not prime test taking environment and failed with something like 823 of 825. Took three days off to cram for it this time around and passed with a 933. Was looking into CCNA wireless next but started looking into CCNA security and it's stuff I'm much more familiar with. Gonna shoot for it in a few months. Best thing about that Les Paul? Coil taps that bump the P90s down to a more moderate output. That was THE selling point.
|
|
#
?
May 13, 2013 22:35
|
|
|
madsushi posted:I am running some of the beta SRX Firefly model (VMs) and they're great for testing/learning.
|
|
#
?
May 13, 2013 23:29
|
|
|
falz posted:Is this available to download? Curious what the restrictions are, I'd love test this out as a potential route reflector in packet mode. It's available for download as a partner. Right now they say it's a 30-day license but it doesn't seem to have an expiration date on it that I can find. http://www.juniper.net/support/downloads/?p=firefly#sw
|
|
#
?
May 14, 2013 03:43
|
|
|
I think maybe my present to myself after completing the CCNP will be going to Vegas or something.
|
|
#
?
May 14, 2013 13:39
|
|
|
madsushi posted:It's available for download as a partner. Right now they say it's a 30-day license but it doesn't seem to have an expiration date on it that I can find. Thanks. Nabbed it, got it in packet mode. Note to others: OVA will not import on VirtualBox or Xen, I could only get it working on ESX. Also: code:falz fucked around with this message at 15:53 on May 14, 2013 |
|
#
?
May 14, 2013 15:26
|
|
|
falz posted:Note to others: OVA will not import on VirtualBox or Xen, I could only get it working on ESX. The documentation doesn't look to be available for download, but it does mention that it's ESX/i only. Now I'm thinking about buying another 8-core whitebox for my home lab just to run some routing sims.
|
|
#
?
May 14, 2013 17:58
|
|
|
Anyone have any experience debugging overrun input errors on ASA? This is pretty ridiculous- i'm showing received (in 181.250 secs): 9836 pkts/sec 595028 bytes/sec transmitted (in 181.250 secs): 39 pkts/sec 16725 bytes/sec so let's say around 10kpps Interface GigabitEthernet0/0 "internal", is up, line protocol is up Hardware is i82574L rev00, BW 1000 Mbps, DLY 10 usec Auto-Duplex(Full-duplex), Auto-Speed(1000 Mbps) Input flow control is unsupported, output flow control is off Description: Internal interface MAC address d48c.b54e.6cb6, MTU 1500 IP address unassigned 4398209 packets input, 363248808 bytes, 0 no buffer Received 6369 broadcasts, 0 runts, 0 giants 720266 input errors, 0 CRC, 0 frame, 720266 overrun, 0 ignored, 0 abort 16% overruns!? Total CPU utilization for: 5 seconds = 79.8%; 1 minute: 73.2%; 5 minutes: 63.4% 86 packets transmitted, 41 packets received, 52.3% packet loss round-trip min/avg/max/stddev = 42.415/269.927/3263.541/606.826 ms Hardware: ASA5515, 8192 MB RAM, CPU Clarkdale 3058 MHz, 1 CPU (4 cores) Encryption hardware device : Cisco ASA-55xx on-board accelerator (revision 0x1) This platform has an ASA 5515 Security Plus license. This platform has an ASA 5515 Security Plus license. GAHHHHHHHHHHH! What are you doing Cisco!? Why do you torment me!? edit: PC Thread 5Sec 1Min 5Min Process 0x00000000006c27c2 0x00007fff23c37078 1.2% 1.2% 1.3% CP Processing 0x00000000012f7b38 0x00007fff23c200c8 0.5% 0.1% 0.1% ssh - - 86.3% 79.6% 70.0% DATAPATH-0-1136 Oh that narrows it down. jwh fucked around with this message at 21:40 on May 14, 2013 |
|
#
?
May 14, 2013 21:38
|
|
|
14747544 packets input, 1245054248 bytes, 0 no buffer Received 16210 broadcasts, 0 runts, 0 giants 7042733 input errors, 0 CRC, 0 frame, 7042733 overrun, 0 ignored, 0 abort 50% overruns! What is going on here!
|
|
#
?
May 14, 2013 21:59
|
|
|
Your interface is auto/auto, when I had an ASA spiking cpu and overruns it was due to a speed mismatch with the other side that wasn't negotiating correctly.
|
|
#
?
May 14, 2013 22:04
|
|
|
Sepist posted:Your interface is auto/auto, when I had an ASA spiking cpu and overruns it was due to a speed mismatch with the other side that wasn't negotiating correctly. Yep, hard code each side to gig/full and you'll see those errors go away. I just fixed an issue like this earlier this morning.
|
|
#
?
May 14, 2013 22:17
|
|
|
GOOCHY posted:Yep, hard code each side to gig/full and you'll see those errors go away. I just fixed an issue like this earlier this morning. Not so much of hard-coding each side, but making sure both sides are set in the same fashion. And disabling auto-neg on GigE can be bad: http://etherealmind.com/ethernet-autonegotiation-works-why-how-standard-should-be-set/
|
|
#
?
May 14, 2013 22:22
|
|
|
I set both sides to only negotiate for 1000/full (what is this, 1998!?) But it seems like it's still occurring. Some additional info: I have a pen-test guy here, and when he lights up nessus, it absolutely knocks the ASA over. 90%+ cpu, rapid interface overruns. I've tried what I can think of, which is to say, show asp drop, show traf, show proc, etc. This is bullshit: 64 bytes from 10.16.10.1: icmp_seq=1928 ttl=254 time=340.367 ms Request timeout for icmp_seq 1929 64 bytes from 10.16.10.1: icmp_seq=1930 ttl=254 time=274.331 ms Request timeout for icmp_seq 1931 64 bytes from 10.16.10.1: icmp_seq=1932 ttl=254 time=433.541 ms Request timeout for icmp_seq 1933 64 bytes from 10.16.10.1: icmp_seq=1934 ttl=254 time=317.571 ms 64 bytes from 10.16.10.1: icmp_seq=1935 ttl=254 time=366.677 ms 64 bytes from 10.16.10.1: icmp_seq=1936 ttl=254 time=346.191 ms Request timeout for icmp_seq 1937 64 bytes from 10.16.10.1: icmp_seq=1938 ttl=254 time=405.707 ms 64 bytes from 10.16.10.1: icmp_seq=1939 ttl=254 time=543.083 ms Request timeout for icmp_seq 1940 64 bytes from 10.16.10.1: icmp_seq=1941 ttl=254 time=540.137 ms Request timeout for icmp_seq 1942 Request timeout for icmp_seq 1943
|
|
#
?
May 14, 2013 23:11
|
|
|
jwh posted:I set both sides to only negotiate for 1000/full (what is this, 1998!?) Turned off unneeded inspections? Or all inspections then re-enable what you need on a more granular than 'default traffic' basis?
|
|
#
?
May 14, 2013 23:39
|
|
|
Overruns on are in the input side of the queue, so what is plugging into that interface? Your original output had matching errors to overruns: 720266 input errors, 0 CRC, 0 frame, 720266 overrun If you clear the counters do they increment in the same fashion? Is it possible whatever is plugged into that interface is sending >1500byte frames?
|
|
#
?
May 14, 2013 23:40
|
|
|
I declawed the default inspection policy as much as I could, which I had thought could be causing the issue, and while it brought the cpu utilization down a bit, it didn't seem to stop this problem: 25082806 packets input, 2069052054 bytes, 0 no buffer Received 21442 broadcasts, 0 runts, 0 giants 6559474 input errors, 0 CRC, 0 frame, 6559474 overrun, 0 ignored, 0 abort This is just a regular old boring gig copper port on a 2960S. switch side of things: GigabitEthernet1/0/44 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is 44e4.d9d9.cfac (bia 44e4.d9d9.cfac) Description: "asa-1 Gi0/0 internal trunk" MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 3/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX input flow-control is off, output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:00, output hang never Last clearing of "show interface" counters 00:50:02 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 1926000 bits/sec, 222 packets/sec 30 second output rate 12441000 bits/sec, 11983 packets/sec 2855095 packets input, 357720198 bytes, 0 no buffer Received 0 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 67434480 packets output, 6568835994 bytes, 0 underruns
|
|
#
?
May 14, 2013 23:52
|
|
|
jwh posted:I declawed the default inspection policy as much as I could, which I had thought could be causing the issue, and while it brought the cpu utilization down a bit, it didn't seem to stop this problem: Do the input errors / overruns increment when the nessus scan isn't running? Since they are matching up 1:1, something is feeding it bullshit. Span the port headed to ASA gi0/0 and see what's up.
|
|
#
?
May 15, 2013 00:11
|
|
|
routenull0 posted:Since they are matching up 1:1, something is feeding it bullshit. Nothing physical layer? Won't autonegotiate is pretty strange.
|
|
#
?
May 15, 2013 00:21
|
|
|
If I turn down the Nessus scan, things go back to "normal," read as: not ~50% packet loss across the interfaces of the ASA, but that's not a really viable technique in this scenario, since we need to complete the Nessus scans for compliance purposes. I enabled flow control on the ASA interfaces and corresponding switch interfaces, and guess what? That brought overruns down to zero! Er, well, two: 5831541 packets input, 479449108 bytes, 0 no buffer Received 3053 broadcasts, 0 runts, 0 giants 2 input errors, 0 CRC, 0 frame, 2 overrun, 0 ignored, 0 abort Problem solved right? --- 10.16.10.1 ping statistics --- 264 packets transmitted, 164 packets received, 37.9% packet loss round-trip min/avg/max/stddev = 42.332/349.673/925.334/169.186 ms Wait, why is tha- s1#show int gi1/0/44 | i drop Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1342612 Now imagine me shaking my fist angrily at the sky.
|
|
#
?
May 15, 2013 00:41
|
|
|
jwh posted:If I turn down the Nessus scan, things go back to "normal," read as: not ~50% packet loss across the interfaces of the ASA, but that's not a really viable technique in this scenario, since we need to complete the Nessus scans for compliance purposes. Flow-control is setup automatically if you are setup for Auto-Negotiate. If you setup auto/auto on the ASA and corresponding switchport, will they come up at a-1000 / a-full? If not, you've got and underlying L1/L2 problem. Now that you've got drops on the output side of the switch, this is definitely pointing more towards the ASA dealing with the incoming traffic than the switch. Not attempting to be insulting here either, but have you changed the sw1 --> asa-gi0/0 cable? H.R. Paperstacks fucked around with this message at 00:52 on May 15, 2013 |
|
#
?
May 15, 2013 00:48
|
|
|
The switch interface output said that direction was unsupported, so I imagine it just drops it -- but that did move the problem and underscore the need for a span. e: jwh posted:Use ether channel to increase the number of FIFO queues. bort fucked around with this message at 00:52 on May 15, 2013 |
|
#
?
May 15, 2013 00:49
|
|
|
Oh, and I think I understand what the problem is. Single ingress FIFO queue on the 1gbit ASA interfaces is 32/48KB (can't tell which). This is divided into a series of buffers/blocks of _fixed size_ The NIC driver moves received data onto the rx buffer(s). overruns are the result of the the FIFO queue not being able to allocate a buffer/block with which to move packet data off the rx ring. This problem is exacerbated when small packets high pps, since each arrived packet acquires effectively the same block regardless of size. One (honest to god, I wish I was making this up) remediation step? Use ether channel to increase the number of FIFO queues. In conclusion: gently caress you Cisco.
|
|
#
?
May 15, 2013 00:49
|
|
|
jwh posted:Oh, and I think I understand what the problem is. Wow...nice work Cisco.
|
|
#
?
May 15, 2013 00:56
|
|
|
I still think a 5515 should be able to handle a Nessus scan as well as the traffic sizes in the slices you've posted, unless inspection configured to act against it or manically log when it happens. ninja edit: you're not vulnerable to Nessus scanning, I guess. real edit: routenull0 posted:Not attempting to be insulting here either, but have you changed the sw1 --> asa-gi0/0 cable?  oh wait, but the flow control moved the drops to the switch.
bort fucked around with this message at 01:00 on May 15, 2013 |
|
#
?
May 15, 2013 00:56
|
|
|
bort posted:I still think a 5515 should be able to handle a Nessus scan as well as the traffic sizes in the slices you've posted, unless inspection configured to act against it or manically log when it happens. "Port-scans not supported" Not sure if jwh ever mentioned he could get auto-negotiate working on both the ASA and SW1...if not, he's got deeper issues. H.R. Paperstacks fucked around with this message at 01:02 on May 15, 2013 |
|
#
?
May 15, 2013 00:58
|
|
|
Anyone take the new CCNA exam? How was it?
|
|
#
?
May 15, 2013 01:02
|
|
|
I'm slowly walking through the configuration and gutting everything I can. 'no logging enable,' didn't help. I haven't replaced cables to asa-1, but only because I'm seeing the same behavior when I fail over to asa-2.
|
|
#
?
May 15, 2013 01:03
|
|
|
Failover interfaces are negotiated at gig, right? No Active/Active, standby looks normal? e: just thinking that maybe failover/ARP table magic could be sending extra traffic to the active firewall interface. not seeing any bugs that touch this bort fucked around with this message at 01:29 on May 15, 2013 |
|
#
?
May 15, 2013 01:18
|
|
|
Looks good- these are crossover cables between gig0/5 on each box: Interface GigabitEthernet0/5 "failif", is up, line protocol is up Hardware is i82574L rev00, BW 1000 Mbps, DLY 10 usec Auto-Duplex(Full-duplex), Auto-Speed(1000 Mbps) Input flow control is unsupported, output flow control is off Description: LAN/STATE Failover Interface MAC address d48c.b54e.6cb5, MTU 1500 IP address 10.255.255.1, subnet mask 255.255.255.252 45561415 packets input, 5031377840 bytes, 0 no buffer Received 568 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 pause input, 0 resume input 0 L2 decode drops 113375427 packets output, 79260293700 bytes, 0 underruns 0 pause output, 0 resume output 0 output errors, 0 collisions, 7 interface resets 0 late collisions, 0 deferred 0 input reset drops, 0 output reset drops input queue (blocks free curr/low): hardware (494/457) output queue (blocks free curr/low): hardware (495/321)
|
|
#
?
May 15, 2013 01:29
|
|
|
Always with the mysteries, ASA.
|
|
#
?
May 15, 2013 01:32
|
|
|
I have an open TAC case, so fingers crossed. I think it's crazy that 10kpps would clobber one of these boxes. Something isn't right here.
|
|
#
?
May 15, 2013 01:40
|
|
|
Not sure if this is relevant, but I noticed a similar issue with output drops on a 4510R:code:
|
|
#
?
May 15, 2013 04:44
|
|
|
|
| # ? May 31, 2024 11:39 |
|
|
Bluecobra posted:I think they designed it in such a way that when you run "show processes cpu history" it looks like the Cisco logo every time. This made me laugh out loud more than you could imagine. Some interesting news on this one- my TAC engineer called me back to inform me that, yes, the ASA interface is being overwhelmed by the traffic, and that I have two options, more or less: a). Stop sending so much traffic b). Consider port-channels to try and provide more ingress buffers to the platform. So there you have it! 
|
|
#
?
May 15, 2013 05:01
|
|