The Cisco Short Questions Thread v12.4.9(WTF)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cisco Short Questions Thread v12.4.9(WTF)

«‹›430 »

Thanks Ants: May 21, 2004; #essereFerrari

If the data transfer happens over SMB and it's not SMB 3.0 then at non-LAN latencies it's going to be slow as poo poo, that's just how it is.

# ? Sep 2, 2019 21:09

Adbot: ADBOT LOVES YOU

# ? Apr 24, 2024 00:51

MF_James: May 8, 2008; I CANNOT HANDLE BEING CALLED OUT ON MY DUMBASS OPINIONS ABOUT ANTI-VIRUS AND SECURITY. I REALLY LIKE TO THINK THAT I KNOW THINGS HERE

INSTEAD I AM GOING TO WHINE ABOUT IT IN OTHER THREADS SO MY OPINION CAN FEEL VALIDATED IN AN ECHO CHAMBER I LIKE

Since we are general networking in here, I'll ask for some ideas/info here.

Client is balking at the total cost of ownership of an SG250 48-port switch, he is crying because over the life of the switch he will have paid for the switch a second time in SmartNET costs. I mean, sure, but do you not want a service agreement when the thing goes tits up in 2 years? Also, it's not really that much but WHATEVER

Anyway, looking at alternatives, I've come up with Aruba (same issue, actually their support agreements are like double/triple the cost).

Looks like there are some low/mid-end HPE branded switches like this https://www.cdw.com/product/hpe-1950-48g-2sfp-2xgt-switch-48-ports-managed-rack-mountable/4360627pfm=srh I'm not at all familiar with, so not sure how they are, anyone have experience?

Dell EMC devices like this: https://www.cdw.com/product/dell-emc-networking-x1052p-switch-48-ports-managed-rack-mountable/3860905?pfm=srh

Any actual/other recommendations? 48 ports, rack mountable, no PoE needed; it's going to be a client access switch.

# ? Sep 3, 2019 22:13

GreenNight: Feb 19, 2006; Turning the light on the darkest places, you and I know we got to face this now. We got to face this now.

http://download2.mikrotik.com/news/news_90.pdf

# ? Sep 3, 2019 22:15

MF_James: May 8, 2008; I CANNOT HANDLE BEING CALLED OUT ON MY DUMBASS OPINIONS ABOUT ANTI-VIRUS AND SECURITY. I REALLY LIKE TO THINK THAT I KNOW THINGS HERE

INSTEAD I AM GOING TO WHINE ABOUT IT IN OTHER THREADS SO MY OPINION CAN FEEL VALIDATED IN AN ECHO CHAMBER I LIKE

GreenNight posted:

http://download2.mikrotik.com/news/news_90.pdf

I would rather kill myself, also they don't have 48 port options and we only have 1U of rack space.

# ? Sep 3, 2019 22:34

Partycat: Oct 25, 2004

I�ve run about 100+ SG300s and had only one that was DOA. The rest have been solid.

Looks like the SG250X-48 is $700 new. Not sure on the maintenance. $700 is not a lot for a piece of quality or managed gear. You can do cheaper for unmanaged I�m sure, refurbs, or discontinued equipment. YMMV on lifespan.

If you have enough poo poo to need a 48P switch, and the ~$100/year cost for the equipment is too much for the company you have other issues. That or find an unmanaged from wherever that is cheap and has some reasonable buffers and horsepower.

# ? Sep 3, 2019 23:23

Thanks Ants: May 21, 2004; #essereFerrari

I wouldn't bother buying support plans for something as low end as an SG250-series switch, just buy a spare and verify it works before shoving it into storage.

Aruba switches have a lifetime warranty for as long as you're the original owner of the switch and can provide a proof of purchase when asked (they don't always care about that), and do next-day hardware replacements. As above though, if it's critical then have a spare or build availability into whatever you're doing.

My go-to basic L2 switch would be an Aruba 2530.

Thanks Ants fucked around with this message at 23:40 on Sep 3, 2019

# ? Sep 3, 2019 23:38

BaseballPCHiker: Jan 16, 2006

BaseballPCHiker posted:

Anyone ever work much with CWDM fiber?

We're having a really strange issue, and I am not a fiber expert at all, with one of our fiber channels. Its the same dark fiber between multiple sites, all of the sudden its like we were bleeding trunks and looped the network, storm control kicked in shut off interfaces and then everything came back up except for one specific 1390 wavelength.

My understanding is that those muxes are passive devices, there isnt much to them. Is it possible for them to go bad and like combine wavelengths somehow? Maybe just the optics got messed with, like they put on an OTDR to do testing somewhere and burned an optic? Im at a complete loss.

So this is from way back but thought I'd post an update.

Apparently the issue had something to do with a water peak on the fiber that affects that wavelength. The fiber put in was old enough that it was not "zero water peak fiber", which I had never heard of before and wasnt an issue until a fiber break by a contractor that got fixed added just enough attenuation that we started having issues.

The fix was having our vendor come out with a OTDR that could handle those wavelengths and basically clean each optic and end and splice point. At which point our levels went back up and we're now up and running and happy again. So an odd issue with a basic fix.

# ? Sep 5, 2019 19:32

CrazyLittle: Sep 11, 2001; Clapping Larry

Moey posted:

https://www.fs.com/products/75866.html

I really don't have a need for it, but this is pretty cool looking.

You have issues with it?

The issue I had was that it was simply unavailable for purchase (perhaps until very recently)

# ? Sep 5, 2019 20:15

ragzilla: Sep 9, 2005; don't ask me, i only work here

BaseballPCHiker posted:

So this is from way back but thought I'd post an update.

Apparently the issue had something to do with a water peak on the fiber that affects that wavelength. The fiber put in was old enough that it was not "zero water peak fiber", which I had never heard of before and wasnt an issue until a fiber break by a contractor that got fixed added just enough attenuation that we started having issues.

The fix was having our vendor come out with a OTDR that could handle those wavelengths and basically clean each optic and end and splice point. At which point our levels went back up and we're now up and running and happy again. So an odd issue with a basic fix.

The water peak refers to an increase in attenuation peaking around 1383nm from 1360-1460nm. Transmissions in this range will suffer attenuation similar to 1310nm at the peak.

https://www.fiberoptics4sale.com/blogs/archive-posts/95050054-what-is-zero-water-peak-fiber

-edit-
This is incredibly common as a lot of the fiber out there is standard g.652, and not the more modern and exotic like low water peak and dispersion shifted (unless it's new longhaul intercity builds that use DS fiber to avoid doing DCM, but even that's less useful now with 200G+ superchannel OEO regen GMPLS networks).

# ? Sep 5, 2019 22:03

Methanar: Sep 26, 2013; by the sex ghost

ragzilla posted:

This is incredibly common as a lot of the fiber out there is standard g.652, and not the more modern and exotic like low water peak and dispersion shifted (unless it's new longhaul intercity builds that use DS fiber to avoid doing DCM, but even that's less useful now with 200G+ superchannel OEO regen GMPLS networks).

Its rare I read something that I understand this little.

# ? Sep 5, 2019 22:11

tortilla_chip: Jun 13, 2007; k-partite

https://community.fs.com/blog/from-o-to-l-the-evolution-of-optical-wavelength-bands.html

# ? Sep 5, 2019 22:14

Moey: Oct 22, 2010; I LIKE TO MOVE IT

As someone who has been dragged through a decent scale fiber project, it makes more sense than it should for me.

# ? Sep 5, 2019 22:26

falz: Jan 29, 2005; 01100110 01100001 01101100 01111010

BaseballPCHiker posted:

So this is from way back but thought I'd post an update.

Apparently the issue had something to do with a water peak on the fiber that affects that wavelength. The fiber put in was old enough that it was not "zero water peak fiber", which I had never heard of before and wasnt an issue until a fiber break by a contractor that got fixed added just enough attenuation that we started having issues.

The fix was having our vendor come out with a OTDR that could handle those wavelengths and basically clean each optic and end and splice point. At which point our levels went back up and we're now up and running and happy again. So an odd issue with a basic fix.

Monitor Dom on your pluggables via snmp or whatever to ensure your power budget on links is acceptable or not. Trend it over time to know when splice cases froze, someone re spliced somewhere and you have more or less power, and so on.

# ? Sep 5, 2019 22:39

Partycat: Oct 25, 2004

Yeah if you spend for metrics on your big boy circuits do that. Cheap gear and optics leaves you with nothing which ... tells you nothing.

Water peak is a property of the cable though, so they likely just cleaned it all.

As we are pushing to 100G we are getting a rude awakening to the need to clean 20 years of garbage because we didn�t cap fibers, clean faces, and treat the glass carefully. Endface inspection is big, and finding scratched cores on panel connectors sucks if you need them reterminated.

# ? Sep 5, 2019 23:53

falz: Jan 29, 2005; 01100110 01100001 01101100 01111010

Partycat posted:

Yeah if you spend for metrics on your big boy circuits do that. Cheap gear and optics leaves you with nothing which ... tells you nothing.

Water peak is a property of the cable though, so they likely just cleaned it all.

As we are pushing to 100G we are getting a rude awakening to the need to clean 20 years of garbage because we didn’t cap fibers, clean faces, and treat the glass carefully. Endface inspection is big, and finding scratched cores on panel connectors sucks if you need them reterminated.

Any cheap optic of any speed should have dom. As for gear, my assumption is juniper or Cisco (not Cisco by Linksys or whatever the Soho stuff is). Plenty of open source ways to trend this for free.

For 100g no different, if this is lr4 you should be able to get per-lane statistics pretty easily.

# ? Sep 6, 2019 00:08

Partycat: Oct 25, 2004

I�m going to look now. Cisco and juniper yes, but i know the 1G and some of the 10G claim no diagnostics . Could just be the platform or code train. I�ll look tomorrow, but since the concept of a power budget is new to some of these guys, I bet I�m going to get some blank stares.

# ? Sep 6, 2019 00:15

Thanks Ants: May 21, 2004; #essereFerrari

You can buy non-OEM optics without DOM for some reason, but the only reason I can think of for doing is it if you made a mistake.

# ? Sep 6, 2019 00:17

falz: Jan 29, 2005; 01100110 01100001 01101100 01111010

Also a lot of optics may not seem to have dom due to vendor coding issues. You can get an i2c programmer to "fix" this if you really want.

Our really old 1g optics don't have it, but we replace them when come across in the field, bring them back to the office and reprogam them and put a mark on them with a fine point sharpie to indicate status.

# ? Sep 6, 2019 00:26

FatCow: Apr 22, 2002; I MAP THE FUCK OUT OF PEOPLE

Lighting fiber spans that are measured in km without DOM on your optics is some seriously dangerous living.

Got a span from Zayo that should have been 60km. When they delivered it OTDR said it was 90km. Good thing we buy cheap poo poo from FS for these projects.

# ? Sep 6, 2019 03:12

BaseballPCHiker: Jan 16, 2006

ragzilla posted:

The water peak refers to an increase in attenuation peaking around 1383nm from 1360-1460nm. Transmissions in this range will suffer attenuation similar to 1310nm at the peak.

https://www.fiberoptics4sale.com/blogs/archive-posts/95050054-what-is-zero-water-peak-fiber

-edit-
This is incredibly common as a lot of the fiber out there is standard g.652, and not the more modern and exotic like low water peak and dispersion shifted (unless it's new longhaul intercity builds that use DS fiber to avoid doing DCM, but even that's less useful now with 200G+ superchannel OEO regen GMPLS networks).

I read the same link after our fiber management company was telling us about it. I honestly had no idea this was even a thing, but it made perfect sense to us as it was affecting the wavelengths that article mentioned.

Partycat posted:

Yeah if you spend for metrics on your big boy circuits do that. Cheap gear and optics leaves you with nothing which ... tells you nothing.

Water peak is a property of the cable though, so they likely just cleaned it all.

As we are pushing to 100G we are getting a rude awakening to the need to clean 20 years of garbage because we didn’t cap fibers, clean faces, and treat the glass carefully. Endface inspection is big, and finding scratched cores on panel connectors sucks if you need them reterminated.

falz posted:

Any cheap optic of any speed should have dom. As for gear, my assumption is juniper or Cisco (not Cisco by Linksys or whatever the Soho stuff is). Plenty of open source ways to trend this for free.

For 100g no different, if this is lr4 you should be able to get per-lane statistics pretty easily.

We've historically majorly cheaped out on optics here, along side plenty of grey market switches, which is now coming back to bite us. Things have started to change for the better though once new management came in. We're now ordering optics with DOM, we actually got a cheap OTDR to do some basic diagnostics, got money to have a vendor come out and clean ends, etc. Plus later this year we should be making the switch over to DWDM from our old CWDM stuff.

I entered this job knowing nothing about fiber and just now am starting to feel like I have a reasonable idea of whats going on. It's really a whole new world.

# ? Sep 6, 2019 14:15

ragzilla: Sep 9, 2005; don't ask me, i only work here

ras� fantastic optical presentation from nanog also covers water peak and a whole host of other optical details: https://archive.nanog.org/sites/default/files/2_Steenbergen_Tutorial_New_And_v2.pdf

# ? Sep 6, 2019 17:43

Partycat: Oct 25, 2004

So here in NY, Fiber Instrument Sales offers training at different locations. Their Brightside location is a lodge in the Adirondacks for like $700 with everything included. They�re pretty good company.

# ? Sep 6, 2019 23:59

falz: Jan 29, 2005; 01100110 01100001 01101100 01111010

BaseballPCHiker posted:

I read the same link after our fiber management company was telling us about it. I honestly had no idea this was even a thing, but it made perfect sense to us as it was affecting the wavelengths that article mentioned.

We've historically majorly cheaped out on optics here, along side plenty of grey market switches, which is now coming back to bite us. Things have started to change for the better though once new management came in. We're now ordering optics with DOM, we actually got a cheap OTDR to do some basic diagnostics, got money to have a vendor come out and clean ends, etc. Plus later this year we should be making the switch over to DWDM from our old CWDM stuff.

I entered this job knowing nothing about fiber and just now am starting to feel like I have a reasonable idea of whats going on. It's really a whole new world.

You don't need to arbitrarily change from cwdm to dwdm unless you have a reason, optical system support, capacity on a path, distance, etc.

# ? Sep 7, 2019 00:39

Moey: Oct 22, 2010; I LIKE TO MOVE IT

falz posted:

You don't need to arbitrarily change from cwdm to dwdm unless you have a reason, optical system support, capacity on a path, distance, etc.

It's always capacity.

# ? Sep 7, 2019 02:58

Tetramin: Apr 1, 2006; I'ma buck you up.

I got a large capacity

Tetramin fucked around with this message at 09:22 on Sep 7, 2019

# ? Sep 7, 2019 08:24

ragzilla: Sep 9, 2005; don't ask me, i only work here

Moey posted:

It's always capacity.

Distance too. DWDM you pack inside C and L bands so it can be amplified with EDFA/Raman. You can�t do that with CWDM in the E band.

# ? Sep 7, 2019 13:44

BurgerQuest: Mar 17, 2009; by Jeffrey of YOSPOS

Moey posted:

https://www.fs.com/products/75866.html

I really don't have a need for it, but this is pretty cool looking.

You have issues with it?

We have one, seems to work, I've not heard of any issues with it.

# ? Sep 8, 2019 03:06

FatCow: Apr 22, 2002; I MAP THE FUCK OUT OF PEOPLE

ragzilla posted:

Raman

This is the most black magic poo poo in all of networking.

# ? Sep 9, 2019 03:42

Kazinsal: Dec 13, 2011

Anyone been having issues with pages on CCW not loading properly behind Umbrella? We're seeing estimate and quote pages breaking randomly with a whole bunch of 403 statuses on requests for JS and CSS files on apps.cisco.com, but only when using Umbrella for DNS resolution.

# ? Sep 10, 2019 21:55

MF_James: May 8, 2008; I CANNOT HANDLE BEING CALLED OUT ON MY DUMBASS OPINIONS ABOUT ANTI-VIRUS AND SECURITY. I REALLY LIKE TO THINK THAT I KNOW THINGS HERE

INSTEAD I AM GOING TO WHINE ABOUT IT IN OTHER THREADS SO MY OPINION CAN FEEL VALIDATED IN AN ECHO CHAMBER I LIKE

So, I'm mildly perplexed by this, the situation is that I have an ASA5515 pair that is logging to a syslog server, I have moved the syslog server to a new machine (from a win7 desktop to a server 2019 VM), since doing that I'm no longer getting netflow logs.

We don't have netflow specifically set up, but we are doing debug logging; the only configuration change that was made on the ASA was removing the old server and adding the new in its' place.

I confirmed the server is not seeing those logs via pcap on the server, but it does get other debug level logs without issue.

I confirmed that those logs appear on the ASA by logging to the console directly.

It does not (appear) the traffic is being dropped by the switch, I looked at counters and they aren't going up.

I ran a cap on the ASA itself to try to confirm 100% that it's sending the logs to the syslog server, but the capture only shows date, time source IP/port, destination IP/port and packet count, doesn't show the actual content of the packet.

Anyone have any ideas about where I can look next? I was really hoping to validate the ASA is sending the logs with more verbose capture but I don't see how to do that. Even if it is, I don't see what the hell could be happening to the packets, they seem to be disappearing into the ethernet

# ? Sep 13, 2019 17:35

uhhhhahhhhohahhh: Oct 9, 2012

MF_James posted:

So, I'm mildly perplexed by this, the situation is that I have an ASA5515 pair that is logging to a syslog server, I have moved the syslog server to a new machine (from a win7 desktop to a server 2019 VM), since doing that I'm no longer getting netflow logs.

We don't have netflow specifically set up, but we are doing debug logging; the only configuration change that was made on the ASA was removing the old server and adding the new in its' place.

I confirmed the server is not seeing those logs via pcap on the server, but it does get other debug level logs without issue.

I confirmed that those logs appear on the ASA by logging to the console directly.

It does not (appear) the traffic is being dropped by the switch, I looked at counters and they aren't going up.

I ran a cap on the ASA itself to try to confirm 100% that it's sending the logs to the syslog server, but the capture only shows date, time source IP/port, destination IP/port and packet count, doesn't show the actual content of the packet.

Anyone have any ideas about where I can look next? I was really hoping to validate the ASA is sending the logs with more verbose capture but I don't see how to do that. Even if it is, I don't see what the hell could be happening to the packets, they seem to be disappearing into the ethernet

Did you add the new IP in both places? If you're doing it through ASDM, you do it on the device management page and on the Service Policy page.

# ? Sep 13, 2019 18:19

MF_James: May 8, 2008; I CANNOT HANDLE BEING CALLED OUT ON MY DUMBASS OPINIONS ABOUT ANTI-VIRUS AND SECURITY. I REALLY LIKE TO THINK THAT I KNOW THINGS HERE

INSTEAD I AM GOING TO WHINE ABOUT IT IN OTHER THREADS SO MY OPINION CAN FEEL VALIDATED IN AN ECHO CHAMBER I LIKE

uhhhhahhhhohahhh posted:

Did you add the new IP in both places? If you're doing it through ASDM, you do it on the device management page and on the Service Policy page.

Both places? We don't have netflow explicitly configured, it (should) be sent because logging level is set to debugging and debug-trace is on; if that's what you mean. Doing this all through the CLi, I don't really use ASDM.

Perhaps I am mis-using netflow, but I assumed that's what they were... here's an example log that I'm not getting now that I was before:

<166><1566403763000>ASA-6-302014:Teardown TCP connection 24157561 for outside: X.X.X.X/443 to inside: X.X.X.X/21135 duration 0:00:00 bytes 0 TCP FINs from inside

MF_James fucked around with this message at 18:51 on Sep 13, 2019

# ? Sep 13, 2019 18:45

BaseballPCHiker: Jan 16, 2006

What syslog software are you using?

What does your config look like for the ASA if you do a show run?

Did you specify an interface for the logging host? For example:

code:

logging host INSIDE 192.168.1.1 Port#

# ? Sep 13, 2019 19:38

uhhhhahhhhohahhh: Oct 9, 2012

MF_James posted:

Both places? We don't have netflow explicitly configured, it (should) be sent because logging level is set to debugging and debug-trace is on; if that's what you mean. Doing this all through the CLi, I don't really use ASDM.

Perhaps I am mis-using netflow, but I assumed that's what they were... here's an example log that I'm not getting now that I was before:

<166><1566403763000>ASA-6-302014:Teardown TCP connection 24157561 for outside: X.X.X.X/443 to inside: X.X.X.X/21135 duration 0:00:00 bytes 0 TCP FINs from inside

I don't think that's technically netflow, just the standard ASA log about connections being created, ended or denied.

This is the guide I used to get started with it: https://community.cisco.com/t5/security-documents/configuring-netflow-on-asa-with-asdm/ta-p/3119466

# ? Sep 13, 2019 19:42

MF_James: May 8, 2008; I CANNOT HANDLE BEING CALLED OUT ON MY DUMBASS OPINIONS ABOUT ANTI-VIRUS AND SECURITY. I REALLY LIKE TO THINK THAT I KNOW THINGS HERE

INSTEAD I AM GOING TO WHINE ABOUT IT IN OTHER THREADS SO MY OPINION CAN FEEL VALIDATED IN AN ECHO CHAMBER I LIKE

BaseballPCHiker posted:

What syslog software are you using?

What does your config look like for the ASA if you do a show run?

Did you specify an interface for the logging host? For example:
code:
logging host INSIDE 192.168.1.1 Port#

ALB5515# show run logging
logging enable
logging timestamp
logging buffer-size 65535
logging buffered informational
logging trap debugging
logging asdm informational
logging host inside 192.168.86.6
logging debug-trace

Configuration worked fine before changing to the new server, all I did was change the host IP; we're using Log360 it is listening on 513 and 514 UDP.

The issue is still that the logs do not even get TO the syslog server, it's not sending anything about connections etc, it's only sending information about login/out/configuration change and possibly a few other little things, but nothing about allowed/denied/created/destroyed connections.

uhhhhahhhhohahhh posted:

I don't think that's technically netflow, just the standard ASA log about connections being created, ended or denied.

This is the guide I used to get started with it: https://community.cisco.com/t5/security-documents/configuring-netflow-on-asa-with-asdm/ta-p/3119466

Ahh guess it's not netflow then, just need info about the connections.

# ? Sep 13, 2019 19:52

BaseballPCHiker: Jan 16, 2006

MF_James posted:

logging host inside 192.168.86.6

Try putting the port numbers at the end up that IP. Like: logging host inside 192.168.86.6 UDP/513.

I just fought a similar battle and am trying to look through my notes to figure out how and the heck I got it working.

# ? Sep 13, 2019 21:16

MF_James: May 8, 2008; I CANNOT HANDLE BEING CALLED OUT ON MY DUMBASS OPINIONS ABOUT ANTI-VIRUS AND SECURITY. I REALLY LIKE TO THINK THAT I KNOW THINGS HERE

INSTEAD I AM GOING TO WHINE ABOUT IT IN OTHER THREADS SO MY OPINION CAN FEEL VALIDATED IN AN ECHO CHAMBER I LIKE

BaseballPCHiker posted:

Try putting the port numbers at the end up that IP. Like: logging host inside 192.168.86.6 UDP/513.

I just fought a similar battle and am trying to look through my notes to figure out how and the heck I got it working.

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...

MF_James fucked around with this message at 22:21 on Sep 13, 2019

# ? Sep 13, 2019 22:12

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.

# ? Sep 17, 2019 16:44

MF_James: May 8, 2008; I CANNOT HANDLE BEING CALLED OUT ON MY DUMBASS OPINIONS ABOUT ANTI-VIRUS AND SECURITY. I REALLY LIKE TO THINK THAT I KNOW THINGS HERE

INSTEAD I AM GOING TO WHINE ABOUT IT IN OTHER THREADS SO MY OPINION CAN FEEL VALIDATED IN AN ECHO CHAMBER I LIKE

Nuclearmonkee posted:

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.

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

# ? Sep 17, 2019 19:42

Adbot: ADBOT LOVES YOU

# ? Apr 24, 2024 00:51

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

# ? Sep 17, 2019 20:28

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cisco Short Questions Thread v12.4.9(WTF)

«‹›430 »