Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Nuclearmonkee
Jun 10, 2009


falz posted:

I must be backwards since NAT seems so strange on ASA and more logical on IOS.

I share this opinion. Making complicated NATs is a pain in the rear end on ASAs.

Adbot
ADBOT LOVES YOU

Nuclearmonkee
Jun 10, 2009


Eletriarnation posted:

In IOS, that would be "dammit, who did this!?" going to check your ACS server followed by an hour of cursing while reconfiguring. a swift reload from your backup server.

TACACS+ accounting is your friend! Though yes, XR does it far far better.

Nuclearmonkee
Jun 10, 2009


I have a rather weird situation that I'm trying to work through.

On one side, I have my ASAs trunked to my internet side switches which then patch into an ISP router. We have two different IP blocks from this ISP, and the ASAs have an interface in each block on their respective subinterface, as shown below.
code:
interface Ethernet0/0.100
Vlan 100
nameif ATTOutside
security-level 0
ip address x.x.x.x 255.255.255.240
!
interface Ethernet0/0.200
Vlan 200
nameif ATTOutside2 
 security-level 0
ip address y.y.y.y 255.255.255.240
This works fine and dandy, except for the fact that on the ISP side it's just a single routed interface hosting the two IPs, so I need to bridge these VLANs together and hand it off to the ISP router unencapsulated. Why not just use two physical interfaces on the ASAs, a secondary IP, or just normal routed subinterfaces you ask?

1) I have no more physical ports free on my ASAs
2) ASAs don't do secondary IPs
3) I have to use VLANs because the ASA will not let you do nameifs on subinterfaces unless they also have a VLAN assigned :suicide:

So I have my two VLANs delivered successfully to my switch, and though I know that I could just bridge the two VLANs together with a patch cable going between access ports on the two different VLANs, such a solution is not elegant and will trigger my inner :spergin:. I know you can use bridge groups and BVIs to do various bridging magic with interfaces, however I want to bridge two VLANs together on the switch itself. Is this possible?

I posed this question to a few Cisco TAC guys and got :psyduck: in response.

Nuclearmonkee fucked around with this message at 21:41 on Oct 18, 2011

Nuclearmonkee
Jun 10, 2009


Powercrazy posted:

Why do you have two separate public networks from presumably two providers, but on only a single physical interface?

I'd address that first. Having two networks like that seems unnecessarily complicated, and useless.

Two networks, same provider. They ran out of IPs and bought a second block.

EDIT: And by "ran out" I mean the guy at this location doesn't know wtf he is doing. I am basically trying to get this working quickly for a specific purpose, not fix their entire (poorly configured) network.

Nuclearmonkee fucked around with this message at 22:03 on Oct 18, 2011

Nuclearmonkee
Jun 10, 2009


jwh posted:

I think the physical cable is your best bet. Disable spanning-tree or else you'll see bpdu mismatch errors (I think).

Yeah I bpdufiltered the port to prevent any angry errors from popping up and told the customer they need to pay for the network to be redone (at least the internet side mess) and not to bitch if there are problems because of the bandaids we slapped on.

You don't get 99.999 when your topology looks like it was designed by a drunken chimpanzee.

Nuclearmonkee fucked around with this message at 21:00 on Oct 19, 2011

Nuclearmonkee
Jun 10, 2009


Zuhzuhzombie!! posted:

Can the ISP simply route you the other block of IPs, let you advertise/allocate it as you want, and then just forward everything out of your network like normal?

I don't understand the necessity of a completely different interface.

It is a complicated combination of people unwilling to purchase hardware that they should be using, along with the annoying limitations involving complex site to site VPN topologies using ASAs. I suppose I could write it all out tomorrow if you want the long version :)

Nuclearmonkee
Jun 10, 2009


GOOCHY posted:

This is the question I'd ask too. Why don't they just route the 2nd additional public subnet down to your ASA device instead of, presumably, having it as a secondary "connected" network on the interface on the ISP end. That's how I'm envisioning they're doing it, anyway.

If they do it that way you can break the network out however you wish on your side.

At another remote office, there is an ASA with two uplinks. On the other side, there is this messy ASA with the two blocks on one ISP.

They want to have two active site to site tunnels going over each of these remote site uplinks over to their home ASA, which specific VPN traffic designated for each uplink. The ASA doesn't support single site to site VPNs with an active/active configuration like this (or at least not that I'm aware of, nor were the TAC guys aware), so the easiest way was to just add a secondary interface on the far ASA to function as an endpoint for this second VPN connection so that I could build rules to send appropriate traffic over each tunnel.

The customer refused to buy hardware which does this kind of thing easily, and I was simply told to "make it work with what they have right now", which is exactly what they got.

Nuclearmonkee
Jun 10, 2009


Zuhzuhzombie!! posted:

In other news.

"I can't access Wikipedia"

Can you send me a traceroute?

"Traceroute shows 200ms latency on Level 3 in Florida"

But you can actually get to the site?

"Yes, sometimes it's instantaneous, sometimes it's slow."


.........






Moral of the story is that I need to go into the public sector.

That is everywhere. You are networking so if "the internet is slow" then it's obviously your fault. You are personally responsible for every fiber line severed by a tractor, weather which knocks out cable service, and even the rogue squirrel who decides to snack on some of your dark fiber.

Nuclearmonkee fucked around with this message at 17:32 on Oct 20, 2011

Nuclearmonkee
Jun 10, 2009


Just had to share this little screenshot.



No, the password recovery mechanism was not disabled.



Seen all kinds of eBay switches with configs still intact, but this is my first government one. Always remember to delete your configs before you eBay your old stuff!

When I worked in government, albeit local government, I remember extremely strong prohibitions against letting a network device that could have potentially sensitive data in it ever creep out of the organization. Password recovery was also disabled on everything (and verified as such via Solarwinds). I can only assume the Department of Defense is supposed to be more stringent. v:v:v

Nuclearmonkee
Jun 10, 2009


CrazyLittle posted:

Even better if they used Cisco 7 passwords (reversible)

They did.

Domain name from the config: ip domain-name soccent.centcom.smil.mil

Special Operations Central Command.

:downs:

Nuclearmonkee
Jun 10, 2009


psydude posted:

AFAIK, devices carrying classified or sensitive but unclassified information are supposed to be destroyed rather than sold as surplus. To give you an idea of how anal they are about technology - you can't even take a CD that's been in a classified computer and stick it in a machine of a lower classification or and unclassified network.

That's a pretty standard USG-wide warning, though, so for all we know it could have come from like the Forestry Service or BLM or something; non secret-squirrel parts of the government need to access them internets too, you know.

Unless they faked the config it appears to come from Special Operations Central Command and is configured with IPs in the 22.0.0.0/8 and 11.0.0.0/8 ranges. Pretty sure those guys are supposed to be super anal. Now it gets to have a rather boring existence serving truck engineers.

Nuclearmonkee
Jun 10, 2009


psydude posted:

You'd be surprised at the kind of people who find their way into working on classified networks.

Well I know idiots exist everywhere, particularly in large organizations. I'm just amazed that they would allow such a horrible config oversight and not have some kind of compliance system in place to make sure it never ever happens.

It's not like budget would be a concern for these guys and I would expect the senior engineers to be at least semi-competent. Even in my experience with derpy local pd/sheriff departments we had to follow the lowest FIPS 140-2 standard.

Nuclearmonkee
Jun 10, 2009


Bob Morales posted:

HP switch question here: there appears to be two software versions, 15 and 16 for the same switches? Is one a more 'reliable' one and one has more 'features' or something like that? I seem to remember Adtran having something weird like that with AOS releases.

16 is the new release train which has more stuff and is the one they are actively maintaining. I have a few HP 5412 zl switches out there and they are still happily running 15.10.0018m and will probably continue to do so until they are replaced or a reason to change them to 16 arises.

So I guess it's kind of up to you but I'm just sticking with the old boring 15 stuff since I don't need any 16 features and despise buggy switch firmware.

Nuclearmonkee
Jun 10, 2009


adorai posted:

I know no one pays list. Generally, I expect 50% from Cisco. I'm not new to UCS, we use their C series and have for a few generations. We just aren't at the scale where the centralized management of their blade system is going to be a selling point. I am looking at blades to minimize rack utilization right now, as I am considering a move from our own datacenters to leased racks. If I tie that in with a refresh I would do otherwise, it probably makes sense to go with blades, but maybe not UCS.

I love it even if it's just a UCS mini sitting out somewhere. If you have a comprehensive and sane network architecture/plan after you put these guys in you generally don't have to touch them very much beyond doing the occasional software update or part replacement when some doodad or another goes bad, which in my experience thus far with 14 chassis happens very rarely. They go in easy, don't take much space and are extremely easy to manage once you are used to them. I suppose you can do an HP blade server or w/e instead if you prefer them though.

We pay around 25k for a starter mini with the 6324s and 2 server blades w/ 256gb memory. If you wanted to go a bit lower budget you can stick a pair of 10gig 3850s or 4500x's on top of them as your core with enough ports to connect storage, copper switches etc along with the UCSes. I stamp these out for manufacturing facilities and they come in at about 80k for the core switches, UCS chassis and storage.

Nuclearmonkee fucked around with this message at 19:28 on Jan 16, 2017

Nuclearmonkee
Jun 10, 2009


psydude posted:

Happy Thursday! Your Cisco equipment may die after 18 months in production:

http://www.cisco.com/c/en/us/support/web/clock-signal.html#~overview,

Ughhh this is literally every ASA I have.

Also I just pulled a pair out of the box from CDW and put them in and...

code:
rew-fw1# sh inventory
Name: "Chassis", DESCR: "ASA 5508-X with FirePOWER services, 8GE, AC, DES"
PID: ASA5508           , VID: V02
so I assume folks at CDW and where ever don't give a single gently caress and are just selling their existing inventory anyways.

Nuclearmonkee
Jun 10, 2009


n0tqu1tesane posted:

Toss your serial numbers in the order spreadsheet, your particular hardware may not have the faulty part, even if the VID matches.

I'm seeing that if it's got a manufacture date newer than November, it's not affected.

Of course, I sent a big list in that spreadsheet off to Cisco just to verify that the routers I've got aren't affected.

It is. I RMA'd it and sent in my spreadsheet with 52 entries :suicide:

Nuclearmonkee
Jun 10, 2009


Ahdinko posted:

How are you guys getting the correct PIDs for your ASA's for this spreadsheet? I know for a fact at least one of them was ordered as a ASA5516-FPWR-BUN, but when i do a "show inventory" it just says the PID is "ASA5516". Same with all my other ones, they all just say "ASA5508" but they must be at least ASA5508-K9 because they all do AES.

Please dont make me go back to the sales team and find all the orders for ASA's over the last 18 months :(

I just matched the hardware and the serial in show inventory, cried a little at the size of the list, and hit submit. Aren't all of the different PIDs just mostly license bundles with the base hardware being the same? Unless you are dealing with like the babby ones which can have wireless or whatever inside.

Depending on how you are doing licensing it may be a goddamn nightmare for you to migrate them individually from all of the appliances with Cisco though.

Worst part for me will be getting firepower back in order afterwards. It takes fuckin forever to go from the 5.4 whatever base they come with to 6.2 and I will need to do it 52 times.

Nuclearmonkee
Jun 10, 2009


Ahdinko posted:

Yeah I think they pretty much are just different licensing bundles. Just figuring out the easiest way to find out what each one has rather than going into every single one and doing a sh act and then logging into each firepower and checking the licence out there. All those firepower licences, sec plus licences, additional anyconnect licences... ughhhhh.

I've found the easiest way to go from the old rear end version they ship with to the latest version is to replace the boot image and install the FPWR software bit from a fresh rather than getting it setup and doing the upgrades through the firepower GUI. Still takes a good hour per box though. At least if you can just throw them all into a build network together with a TFTP and FTP server, you can smash the lot out in one go.

Yeah it takes about an hour just to get the drat thing ready to begin and then I have to put them all back in the management center and put them in their groups and associate the correct policies and :suicide:

Nuclearmonkee
Jun 10, 2009


I would like to run the unified image but they still don't have freaking anyconnect support on there yet. Supposedly coming SOON.

Nuclearmonkee
Jun 10, 2009


Colonial Air Force posted:

Hi, total Cisco newb. What is this? Why won't it just configure easily so I can move on? :(



I'm not opposed to using CLI for the first steps, I just don't know how.

It's punishing you for using the ASDM. If you are total newb use the thing to generate the commands and then connect to it via ssh/console and put them in so you can see what it is actually doing.

ASDM is kind of poo poo for a lot of things. I do use it for live logging and manipulating access lists but for most things besides that it likes to do bullshit like what you are seeing and break your stuff.

Nuclearmonkee fucked around with this message at 18:51 on Feb 23, 2017

Nuclearmonkee
Jun 10, 2009


Colonial Air Force posted:

Ok.

I went into the CLI, and I (think I) configured the WAN interface (1/1) to use DHCP, and the LAN interface (1/2) to be 10.71.1.1. It won't let me set the IP for Management 1/1 onm the same subnet as the LAN, even though the quisktart guide that came with the thing says it should.

That must have been what was erroring with ADSM also, because that's the only command that gave me a problem.

If you are not doing out of band management w/ the management int you can just use the normal LAN interface for management traffic. If you are using the firepower module it will use the management interface and can be on the same subnet but you have to actually configure that from within the sfr module.

Just put in:
code:
management-access LAN (or whatever you called it)
ssh <host or network you want to let things ssh to it from> LAN
http <host or network you want to let things access ASDM from> LAN
Assuming you already have a user/pass and the basic auth setup it should work.

Nuclearmonkee
Jun 10, 2009


GreenNight posted:

I'm still waiting on my stack of routers from Cisco that has that bad timing part.

I haven't gotten anything but an automated response as of yet though for our pile, though we did have one fail in the manner described and got it RMAd the normal way :v:

I'll laugh if they are half replaced by the time they actually send me poo poo.

Nuclearmonkee
Jun 10, 2009


code:
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active
10   native                           active    Te1/1/5, Te1/1/6, Te1/1/7, Te1/1/8, Te1/1/9, Te1/1/10, Te1/1/11, Te1/1/12, Te1/1/14, Te2/1/5, Te2/1/6
                                                Te2/1/7, Te2/1/8, Te2/1/9, Te2/1/10, Te2/1/11, Te2/1/12, Te2/1/14
...
420  erry_day                         active    
I like how this guy thinks. The interface had an appropriate description so I didn't have to puzzle out what it did.

Nuclearmonkee
Jun 10, 2009


GreenNight posted:

So uh, what's the hottest a Cisco switch can be before failure? Getting some alerts from Solarwinds that a switch hit 120F in one of our manufacturing facilities.

A mere 120F? That baby'll be fine.


:thunk::thunk::thunk:

This stupid loving thing sits inside an unventilated metal box in direct sun near a substation out at a plant and has operated like this for several years. Peaks around 160Fish in August usually. Most access switches will survive way beyond their recommended env ranges and if it's an industrial facility they should have a spare on site anyways. I try to get the plants to install IDFs that are slightly less hostile than this or spring for an IE but really they'll be fine even if they don't most of the time.

I don't even have it alert me at all for temp anymore because what's the point.

Had a 3650 that somebody stuck inside a wall behind some insulation a couple years back because the guys redoing the room didn't care or know what that thing stuck to the old wall was. It sat in the 140s pretty much always. Plant never bothered to relocate it until someone needed to add some drops in the area.

Nuclearmonkee
Jun 10, 2009


Kazinsal posted:

A coworker of mine has a password so long it breaks the TACACS+ process on IOS-XE 16.6.1. Instead of sending "authentication continue" with his password, it sends another "authentication start". Only the one switch in our environment still on 16.6 hits this.

Absolutely magical.

lmao out of curiosity how many characters does it take to break it?

Nuclearmonkee
Jun 10, 2009


Thanks Ants posted:

Lots of vendors will throw up warnings about incompatible transceivers. I just buy ones from FS.com flashed with a legit part number so the switch doesn't complain and so it doesn't show up in tech support diagnostic data giving people an easy way out of your ticket, and then keep a couple of legit ones on hand for troubleshooting if required.

Also "service unsupported-transceiver" and "no errdisable detect cause gbic-invalid" are your friend

I've never actually needed to use my Cisco optics but we also have one of each set just in case TAC tries to wriggle out of providing support.

Nuclearmonkee fucked around with this message at 17:45 on Aug 12, 2019

Nuclearmonkee
Jun 10, 2009


MF_James posted:

Can a cisco device syslog to the same IP twice but on different ports?

I have a want/need to condense 2 syslog "servers" (aka windows 7 workstations set up by my predecessor) and I'd prefer to just have one listen on something like UDP/1025 while the other listens on UDP/514, but I'm not sure if that will actually work; other option is obviously give the new VM 2 IP addresses and just have each one listen on its' own IP.

code:
logging host 69.69.69.69
logging host 69.69.69.69 transport udp port 1025 
should work

Nuclearmonkee
Jun 10, 2009


howdoesishotweb posted:

Not sure if this is the place for this question, since I’m dealing with Cisco software.

I work in radiology, and I’m trying to work from home occasionally. We connect to our hospital network through the Cisco AnyConnect VPN. I can connect no problem, but the speed is absolute poo poo. I usually get 70mbps download and 11-12 up. Ookla speed test gives me a latency of 11-12 ms. However when trying to download radiology studies to read, I rarely get more than 1-2 mbps. Our IT department says latency to the hospital servers is too long, or the radiology software doesn’t handle remote connections well. However I know other hospitals use the same software without issue. How would I troubleshoot whether this is a VPN issue, whether it be latency or bandwidth?

It's likely doing split tunneling, so your speed test is just testing your local uplink at home, while the problem is with a lovely connection somewhere between you and the remote machine you are connecting to via VPN, or they are applying some kind of QoS to prevent VPN users from eating too much bandwidth.

Your IT guy is giving you the lazy answer to make you go away, doesn't know how it works, or doesn't want to bother the guy who actually knows how it works.

Nuclearmonkee fucked around with this message at 20:45 on Sep 2, 2019

Nuclearmonkee
Jun 10, 2009


MF_James posted:

explicitly marking the port made no change.

Gonna have our architect look at it on Monday I guess, I'm just spinning my wheels at this point, unless you come back with your solution.


*edit*

aaaaaaaaaaaaaaaaaand gently caress everything it's working now, all I had to do was completely remove the logging config and re-add it all...

lmao was about to recommend "reboot or rip it all out and put it back to restart the process"

ASAs are creaky old bullshit and that works more often than it should. I have to do this with my SNMPv3 configs from time to time when they just stop working and the monitoring server stops being able to poll them. It's a regular enough task that it's now a script.

Nuclearmonkee
Jun 10, 2009


MF_James posted:

I feel dumb for not trying that before but really wtf come on.

Live and learn I suppose, now I know not to trust the config of an ASA :(

To be fair, it could also have been a firmware bug that's hopefully resolved in an update. That would be next on my list if you are 100% confident the config is correct. :v:

On other ASA related awesomeness, I see that the default 5506x configuration still doesn't do management properly over VPN because lmao https://bst.cloudapps.cisco.com/bugsearch/bug/CSCve82307/?reffering_site=dumpcr This has been outstanding for literal years.

Had to throw one of these out for a one-off remote instrumentation site but forgot about that one until the local guy actually installed it and none of the management would work over the L2L tunnel. Have to delete the BVI and use individual interfaces because "management-access interface " cannot bind to a BVI, which is how they come out of the box.

Add the fiasco that is getting firepower work properly and stay working on top of that and I really am quite annoyed that I have to deal with this crap when there are other NGFWs for comparable cost that are much less of a nightmare to manage.

Nuclearmonkee fucked around with this message at 20:36 on Sep 17, 2019

Nuclearmonkee
Jun 10, 2009


Thanks Ants posted:

Are the Firepower 1000-series poo poo as well, or is it too early to tell

I have one they gave me to mess with. It's still Firepower but at least there's no ASA in there. You can accomplish almost the same thing with an ASA running the FTD image, though you can't run anything after 6.2 on 5506-x and 08-x, which is still the recommended version anyways so lol.

New coat of paint on the turd basically. If you have the budget to buy this, buy something better instead imo.

If you are trapped in Cisco land and have a need for a lot of small 5506-x ish sized appliances they are at least better than what came before.

Nuclearmonkee fucked around with this message at 20:57 on Sep 17, 2019

Nuclearmonkee
Jun 10, 2009


ragzilla posted:

Is this some new code that's not FTD? Because FTD is Firepower as hypervisor and an ASA dataplane, so the ASA piece is still in there but all hidden behind the veneer of FMC/FDM.

No it's still FTD. You just don't have to touch the ASA bits directly

Nuclearmonkee
Jun 10, 2009


Tetramin posted:

I am losing management access to ASAs all across my network, getting connection refused and pcaps show the ASA resetting the connection. Running iOS 9.6.3.1. I have a case with TAC since the ASA at my office is currently affected and I can serial into this one, but we aren’t getting anywhere. He told me removing the SSH config and re adding would fix but it didn’t. Rebooting the device resolves until it happens again.

Anybody have any loving idea? Even ASDM access breaks when this happens.

In other news our Cisco TAM is takin me to a ball game in a suite on Thursday lol

Did you try loving with firmware? I’m on 9.8 train but since it’s ASA I’d try 9.6.4 or something on your local one just to see if it makes a difference

Nuclearmonkee
Jun 10, 2009


Tetramin posted:

This might not be the correct thread, but we were getting some Orion alerts for high interface usage on one of our ASAs this morning. According to Netflow this is all HOPOPT traffic, which I've been doing a bit of reading on and it seems like it's possible this could be some kind of attack? Or could this be some sort of error with the Netflow gathering?

Screenshot from Orion:


The source/dests are all strange too, like 0.101.0.53 or similar.

Didn't notice any performance issues during the time of the traffic, but I just spotted whatever this is and I'm a bit confused.

That's an IP null attack which will show as HOPOPT.

https://www.corero.com/resources/glossary.html#IP%20NULL

Nuclearmonkee
Jun 10, 2009


falz posted:

Doesn't it show the protocols and ports?

IP null attack is a flood with null for the protocol in the IP header, which is what HOPOPT legitimately uses.

Nuclearmonkee
Jun 10, 2009


BaseballPCHiker posted:

Heres hopefully a quick question.

About a year ago while we were doing an equipment refresh I made a point to enable bpduguard on all of our access switches to prevent some horrific episodes that have happened here in the past.

Well I finally had a port go err-disabled and had a heck of a time getting back up. I had to remove the access and voice vlan from the port config, re-enable the port, then add the vlan config back. Is that the normal way of doing it or is there a quicker way?

Also the port in question was an end user bringing in some stupid android TV box thing that caused the port to shutdown. He's a firefighter and said he wanted it to play Kodi on overnight shifts...
code:
errdisable recovery interval 30
errdisable recovery cause all
errdisable detect cause all
If someone does something dumb and removes the thing they plugged in, it will re-enable the port by itself.

Nuclearmonkee
Jun 10, 2009


I've had sfr fail-open let things through when the module was completely broken and non-functional. I thought that was the whole point of the command.

Does it just behave strangely if you have it in fail-open with the module installed but still awaiting setup? Never tried that honestly but it seems silly for it to work that way.

Nuclearmonkee
Jun 10, 2009


falz posted:

I guess I could add a hundred lines to the config to ignore things. Seems weird to me that there's not just a flag like 'log IPS stuff' to turn off, and it's on by default.

This is the answer

quote:

Anyway, ASAs are lame.

Yep

Nuclearmonkee
Jun 10, 2009


falz posted:

I ended up doing this, which got 99% of the cruft, but leaves important stuff like commands that users type. Annoyingly though it shows the command class (enable_15) instead of the username. oh well.

code:
logging buffer-size 20480
logging buffered notifications
logging trap notifications
logging asdm notifications

logging message 106001 level debugging
logging message 106006 level debugging
logging message 106007 level debugging
logging message 106014 level debugging
logging message 106021 level debugging
logging message 106023 level debugging
logging message 313001 level debugging
logging message 313005 level debugging
logging message 400010 level debugging
logging message 400011 level debugging
logging message 400014 level debugging
logging message 400015 level debugging
logging message 400026 level debugging
logging message 410001 level debugging
logging message 710003 level debugging
logging message 733100 level debugging

It does that whenever you use enable. Set priv level 15 for admin users and auto enable on login so they don’t need to enable (which switches executed commands from their user to being run as “enable_15”)

If priv level is already set then running “login” instead of enable will let you elevate to 15. Setting ASA to work right with full AAA/logging and fail back to local is a giant pain in the rear end

Adbot
ADBOT LOVES YOU

Nuclearmonkee
Jun 10, 2009


Bob Morales posted:

We have a Fortinet, but I guess this is a generic networking/failover question:

Two internet connections, and the firewall is configured for failover, basically checking if 8.8.8.8 is reachable.

Our ISP had an issue last weekend where one of the cards in their core router went down, so certain other networks were not reachable. So maybe 80% of stuff worked still, but we got a few emails about things being down etc. One of them being a cloud-based piece of software that is pretty important to the daily operations (Matrixcare EHR)

An order came in from above to have the failover operate on whether we can reach that website. I'm not going to change anything because that's ridiculous and every time that website has a hiccup we're going to switch connections...

So just as a brainstorming session, what are some other suggestions? In all honesty, this is something that should have been investigated by the on-call person, and once identified, manually failed over. It's such a rare thing to happen. One time last year we had something similar where a bug or something screwed up a routing table and we had all kinds of goofy poo poo happen, so we just used the other connection until they got it cleared up.

SD-WAN!

Thanks Ants posted:

You should be able to set this up as an SD-WAN target using an HTTP probe to the domain of the cloud application. Just have it check every minute or so, only look for packet loss, set the failure requirement high enough so you aren't flapping the selected path constantly - I assume five minutes of this app being down before the other link is used is a totally acceptable scenario to be in.

SD-WAN path selection only affects the things you make rules for, so any existing failover on complete loss of a service won't be affected.

Yeah you build policies for different applications along with policies for the links themselves. If the SD-WAN detects your HTTP probe fails on circuit A, it can just send that traffic over to circuit B. It's path selection on a per application basis so if application B still worked fine over the crippled link it could keep going that way. The interruption due to things flipping around would only affect the impacted application(s).

SD-WAN is real good and if you have any critical poo poo in the :cloud: or some big horrible WAN with tons of sites you really want it. It makes the functionality you used to get with monstrous weighted track objects linked to IPSLA and PBR something that is manageable by normal humans.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply