|
Ginger Beer Belly posted:
I ask because other than the first question, no (FTE) networking people at my company would be able to answer them. Public sector so no money for CCIE-level (or even CCNP at market rate) engineers, other than hiring them as a contractor for a project. We don't even use BGP as we don't even have a direct internet connection and most of our traffic is either LAN or WAN with minimal web traffic. And now I'm wondering, if in 5-10 years time I plan to move on, our weird environment might make it hard to learn some things outside of GNS/study to get a more advanced role. Even learning ACI/NSX might not be too helpful if we're not using them to their full capability.
|
#
?
Mar 24, 2019 11:43
|
|
|
|
| # ? Apr 27, 2024 04:10 |
|
|
I've seen questions like that in the 120k+ territory for senior type roles. Tortilla_chip posted some spot on questions you would expect to be asked at Amazon which is mid 100s base with heavy stock incentives. Some of those same questions were also brought up in a prop trading firm interview whose base salary was in the 300k range. Some places are certainly better at interviewing than others though, or they weigh your experience a little more. Finance is kind of a soft ball interview if you've already worked in finance before. Ginger Beer Belly posted:The most illuminating questions that I ask tend to be of the "tell me of a problem you've solved that you're the most proud of, and then let us ask you to dig deeper into details about it" sort. You both get to assess the passion of the individual, as well as let them demonstrate their expertise in what they find important, rather than what the interview team is looking for. With this, you can tell if someone is an expert in anything at all, and potentially just not aligned with your particular area, vs being someone that simply has no depth at all. This question drives me nuts. I've dealt with so many difficult problems that putting one in the spotlight always has me sitting there in my head thinking of which one to use. It always ends up being something stupid. Sepist fucked around with this message at 12:40 on Mar 24, 2019 |
|
#
?
Mar 24, 2019 12:36
|
|
|
Has anybody here dealt with ASA APIs? Supposedly, there is no online documentation of where any endpoints are or how to use the loving thing. You're supposed to use the API browser provided by the ASA, which requires the ASA reaching out to Cloudflare to download some javascript bullshit. For internal firewalls that are explicitly cut off from the internet this causes a problem in that i have absolutely no idea how to use the API at all. Can anybody point me to a cheat-sheet somewhere with some endpoints?
|
|
#
?
Mar 24, 2019 20:59
|
|
|
https://www.cisco.com/c/en/us/td/docs/security/asa/api/qsg-asa-api.html https://www.cisco.com/c/en/us/td/docs/security/asa/api/13/asa-api-rn-13.html https://maroskukan.wordpress.com/2015/02/11/cisco-asav-firewall-rest-api/ "ASA contains a awesome documentation that is located on device itself. Simple point your browser to the following URL https://<management-ip>/doc/" ^^^ I assume this is the externally reaching URL? tortilla_chip fucked around with this message at 22:42 on Mar 24, 2019 |
|
#
?
Mar 24, 2019 22:31
|
|
|
tortilla_chip posted:https://www.cisco.com/c/en/us/td/docs/security/asa/api/qsg-asa-api.html Yeah I've already been up and down all three of those sites, and while they contain helpful examples, they don't provide a full API map. And yes the /doc/ site requires the cloudflare access. I was hoping somebody, somewhere, had written down popular or useful endpoints and put them online for reference.
|
|
#
?
Mar 25, 2019 01:17
|
|
|
You could parse these python scripts for the commands https://github.com/kuhlskev/ansible-cisco-asa/tree/master/library
|
|
#
?
Mar 25, 2019 01:39
|
|
|
That's probably the best I can hope for. Looks like this code has about 5 or 6 good API calls to get most of what I need. Thanks!
|
|
#
?
Mar 25, 2019 05:12
|
|
|
Buy the cheapest ASA that runs the software version you’re running and connect that up to an internet connection to get the documents. This is only a half-joking suggestion.
|
|
#
?
Mar 25, 2019 09:39
|
|
|
An ASAv in vagrant is always an option.
|
|
#
?
Mar 25, 2019 12:00
|
|
|
Both of those ideas have been floated, and the ASAv seems reasonable while we develop our API calls. We need a dummy box to send posts to for testing anyway. I just can't believe Cisco would develop this API, develop all the documentation, and then lock it inside the box like it's some trade secret. And then design the docs to require internet based plugins to work correctly. It seems extremely amateur for enterprise gear.
|
|
#
?
Mar 25, 2019 13:03
|
|
|
For a long time the Fortinet API was behind a paywall... so it's par for the course 
|
|
#
?
Mar 25, 2019 13:44
|
|
|
I mean I don't know if you've actually had to work with Cisco regularly in the past, but them hiding all their API documentation inside the bowels of the ASA is... legitimately not nearly as frustrating as 99% of the other licensing related poo poo they make you put up with. Like I'm seriously not even baffled or given moderate cause for pause reading that scenario. That sounds perfectly normal for them.
|
|
#
?
Mar 25, 2019 21:21
|
|
|
Everything is a subscription now, isn't it excellent
|
|
#
?
Mar 25, 2019 21:33
|
|
|
Digital_Jesus posted:I mean I don't know if you've actually had to work with Cisco regularly in the past, but them hiding all their API documentation inside the bowels of the ASA is... legitimately not nearly as frustrating as 99% of the other licensing related poo poo they make you put up with. yeah, I'm doubting their cisco cred if licensing issues are some new discovery.
|
|
#
?
Mar 25, 2019 22:54
|
|
|
CrazyLittle posted:yeah, I'm doubting their cisco cred if licensing issues are some new discovery. 'Cisco cred' lol like banging your head against the wall is some hill to stand on And it's not a licensing issue. It's an access issue. Requiring a firewall to have internet access on some management port to utilize an internal function is laughably broken.
|
|
#
?
Mar 25, 2019 23:15
|
|
|
lol if you expect any Cisco product with a GUI to work
|
|
#
?
Mar 25, 2019 23:42
|
|
|
I guess it's not as bad as Palo Alto API. While Cisco requires an account called 'enable_1' to exist with full command access if you're using command based authentication and API, at least basic auth works. Palo Alto chokes on basic auth if you're password contains a ^
|
|
#
?
Mar 25, 2019 23:59
|
|
|
wtf
|
|
#
?
Mar 26, 2019 00:15
|
|
|
A lot of boxes choke on certain characters in IPsec PSKs but afaik there's not an RFC that explicitly states what valid PSK characters are, so it ends up as a bit of a guessing game
|
|
#
?
Mar 26, 2019 00:19
|
|
|
Palo Alto's are perfect I can't hear you la la la It kind of says something that an in-house PA developer chose to use SSH for their AWS Transit VPC code rather than the API
|
|
#
?
Mar 26, 2019 01:11
|
|
|
Thanks Ants posted:lol if you expect any Cisco product with a GUI to work Flashbacks to UC 500 intensify
|
|
#
?
Mar 26, 2019 01:31
|
|
|
Sepist posted:Palo Alto's are perfect I can't hear you la la la Palo Alto does most API calls with 'Get', even when post or put is way more appropriate. Want to add an IP to a list? That's a Get, with ?action=add in the URI. It's miserable. And if you have a ^ in your password, the device won't actually care. It will just mangle your password before making the radius request, resulting in invalid credentials and a hit against your credential lockout policy. But you know what? Their API documentation is decent, and the API browser doesn't require bullshit internet access, so there's that! My project of pulling the networking team out of their CLIs isn't stressful at all why do you ask
|
|
#
?
Mar 26, 2019 02:02
|
|
|
I avoid special characters in all my password if possible. If the password is >16characters then just Upper and Lower + numbers is still a pretty huge space. Plus in the rare case where you have to actually type the password out, over the phone, the lack of special character is nice.
|
|
#
?
Mar 26, 2019 18:17
|
|
|
I remember esxi had a bug where if your root console password ended with a $ you just couldn't log into the web interface on the server after deployment and had to redeploy, even if you changed the password at the console. lol.Judge Schnoopy posted:My project of pulling the networking team out of their CLIs isn't stressful at all why do you ask You youngins and your graphics. You can pull my CLI out of my cold, dead, grey bearded hands.
|
|
#
?
Mar 26, 2019 20:24
|
|
|
So I'm looking at new APs for our office and something I noticed is them not able to run over 802.3at anymore? Is this the new trend? Specifically talking aobut this: https://www.arubanetworks.com/assets/ds/DS_AP330Series.pdf quote:Power over Ethernet (PoE): 48 Vdc (nominal) If our switches can provide full 802.3at power, will these restrictions affect us? Or maybe I'm just misreading what IPM is.
|
|
#
?
Mar 26, 2019 20:25
|
|
|
Digital_Jesus posted:I remember esxi had a bug where if your root console password ended with a $ you just couldn't log into the web interface on the server after deployment and had to redeploy, even if you changed the password at the console. lol. Nah not GUIs, we're building in-house tools with APIs that correlate different services together. An IPSet in NSX should match what's in the ASA, an updated service definition in ASA should also be pushed to the Palo Alto, and all base configurations should exist as templated code that can be deployed with values gathered from a number of other sources. Both GUIs and CLI should get out of the way of superior API tools.
|
|
#
?
Mar 26, 2019 20:32
|
|
|
ate poo poo on live tv posted:If our switches can provide full 802.3at power, will these restrictions affect us? Or maybe I'm just misreading what IPM is. It means if you leave ipm off your AP's USB port wont be active. Far as that reads.
|
|
#
?
Mar 26, 2019 20:37
|
|
|
If you leave IPM on, which is the default, then you should power it with an 802.3at switch to get all the functionality. If you disable IPM then there's no way to use the USB port, if you leave IPM enabled then you might be able to get decent performance if you only have an 802.3af power source, but it will depend on load.
|
|
#
?
Mar 26, 2019 20:38
|
|
|
I could see some devices wanting more power to run your USB bluetooth beacons or whatever . So far I’ve yet to see a single AP that uses UPoE or that “you’ll need two Ethernet cables for downlink” . We invested in gear that runs 802.3bz to support that case but still hasn’t happened . UPoE is an annoying mess anyway.
|
|
#
?
Mar 27, 2019 00:01
|
|
|
The Cisco 4802 uses UPoE with all the features enabled
|
|
#
?
Mar 27, 2019 00:05
|
|
|
PancakeTransmission posted:What level/position would this be interviewing for, and what kind of pay range are we talking? Generally it's Sr. Infosec Engineer, or Manager level, and those positions are 100k-150k starting range. Very few of them actually require that level of BGP or netflow knowledge, but when a candidate presents themselves as an expert in those technologies, I want to validate that claim. A successful candidate may instead claim strong python, Splunk, or SSL/TLS expertise, at which point I'll let other people in the interview panel grill them on those details. The funny detail is ... you list the traceroute question as the easier one, yet I've had tons of candidates answer the more BGP-protocol specific answers correctly, and completely bomb the traceroute ones. The reason that's my favorite question is that it's a really good way of identifying a candidate that really deeply understands what is going on in practice, vs just exam-level topics. I want a candidate who can say "I saw a SYN/ACK from the Internet destined for my local IP, but I don't have record of a SYN going outbound. It's entirely possible that this is backscatter from a spoofed SYN sent to that Internet address and not proof that my local address really reached out to them with a SYN"
|
|
#
?
Mar 27, 2019 09:29
|
|
|
Judge Schnoopy posted:My project of pulling the networking team out of their CLIs isn't stressful at all why do you ask I feel like I'm going to be one of the olds, blissfully pounding away at the CLI while some young whippersnapper does some fancy python poo poo to accomplish the same thing. No I'm not bitter at all why do you ask? Actually the last Cisco rep we met with mentioned that none of his clients are taking advantage of the new DNA Plus or whatever the heck its called for full network programability. Sometimes I think this is %90 marketing driven and sometimes I think I'm going to wake up one day without a job because I dont know python/jenkins/whatever.
|
|
#
?
Mar 27, 2019 15:44
|
|
|
DNA Center is dog poo poo Unless you run super simplistic networks CLI is never going away. There are far too many knobs to turn on feature rich enterprise networks to do it with confidence
|
|
#
?
Mar 27, 2019 15:50
|
|
|
Yea, Ansible for large-scale multi-device changes. CLI for specific tuning/one-offs.
|
|
#
?
Mar 27, 2019 16:04
|
|
|
I ditched Ansible and went to straight python w/Netmiko. I found it's easier to explain basic programming logic when it's actually in a programming language instead of YAML and it was rare I could stay within the Ansible lanes. I think the pure CLI is slowly going away with modern netengineers coding things as the second or third step (as opposed to the hundredth, or never, in the old days) of rolling something out. I personally have moved to a Python pipeline for any configuration changes I think I'm going to have to do on more than two devices because it's faster and more reliable for me to do it that way.
|
|
#
?
Mar 27, 2019 22:34
|
|
|
Our Network engineers have to spin up 2 - 6 ASAs a month. Their current method is some Excel file that they copy into flat text, manually change template values for the specific deployment, and then copy it in over step by step into the CLI. Their current automation efforts involve Ansible taking over the process of sending the steps through to the CLI, which is only half of the solution. I'm trying to cut them off at the pass to show them how they can have scripts collect the deployment value for them, build a full configuration from a better template, and deliver it to the box without any additional intervention.
|
|
#
?
Mar 27, 2019 23:24
|
|
|
Judge Schnoopy posted:Our Network engineers have to spin up 2 - 6 ASAs a month. Their current method is some Excel file that they copy into flat text, manually change template values for the specific deployment, and then copy it in over step by step into the CLI. Got any resources for this?
|
|
#
?
Mar 27, 2019 23:39
|
|
|
Judge Schnoopy posted:Our Network engineers have to spin up 2 - 6 ASAs a month. Their current method is some Excel file that they copy into flat text, manually change template values for the specific deployment, and then copy it in over step by step into the CLI. I just recently went through something similar for our pool of hot spare hardware. If you wanted to replace a failed bit of kit, previously everyone had their own little step by step process of what was involved and the spares were all over the place. Now, you run a script that pushes the configuration, updates the device to the correct version, reloads it and then tells you the serial number of the box. When you take it out of the rack, you simply unbox another, completely blank, device, plug it in, and it automatically joins the pool of spares. Everyone knows exactly how many spares are available, where they are, and all the hardware details, so when someone is away and a switch goes pop you can simply replace it then tell the local guys to do the swapsie. There's an abstract question in there about whether CLI's will ever truly disappear and honestly - I think they will. Maybe not for another 10 years but I fully anticipate a network device be released that only has an API, where the "CLI" is simply a wrapper around API calls (bigswitch I think is already like this for example).
|
|
#
?
Mar 27, 2019 23:40
|
|
|
I am hoping someone can validate my design, I am having packet loss which I think is related to lovely design. I have a pair of nexus 93180 switches connected together in VPC domain 1, using vpc 1 / po1. I have a pair of nexus 9348 switches connected together in VPC domain 2, using vpc 1 / po1. Each of the switches in each pair is connected to each of the other pairs switches, for a total of 4 links between the two pairs, using vpc 2 / po2. I have SVIs configured on my pair of 93180 switches, which I think is the main source of my problems. Each of the four switches can ping each other fine, but once I traverse a layer 3 boundary I am seeing a lot of packet loss on the 9348 switches. The 93180 switches seem to be fine, but I haven't had a ton of opportunity to test just yet. Here is a crude drawing of my design (minus the SVIs on the 93180s).  Is there anything I need to know about regarding back-to-back vPC and SVI? This is my first time doing back-to-back VPC or Nexus SVI.
|
|
#
?
Mar 27, 2019 23:44
|
|
|
|
| # ? Apr 27, 2024 04:10 |
|
|
I had something similar on the n3k line, the port-channels in the middle had to be difference po#s
|
|
#
?
Mar 28, 2019 00:21
|
|