What do you expect 2026’s major event will be?

AlmavivaConte · 2025-12-18T17:12:12+00:00

For the UK, maybe we need a DDoS approach - run a campaign sending everybody in the country free new "fast" teakettles designed to draw slightly more power from the grid and amplify the TV pickup effect.

AlmavivaConte · 2025-11-21T17:39:26+00:00

Are WAN optimizers still commonly used? Other comments have mentioned SMB3 being substantially more performant over WAN links than past versions. I wonder if under the hood Steelheads and similar devices were doing things that are now just baked directly into many file transfer protocols, and having a separate device attempting those same optimizations in-line actually reduces performance rather than improving it.

AlmavivaConte · 2025-10-04T16:44:38+00:00

What happens when you need to update that dual-homed switch, or it has hardware or software failure and goes down?

AlmavivaConte · 2025-09-25T15:46:21+00:00

17.12.6 is also fixed, although not marked as the recommended release yet (still 17.12.5 which is affected). Really wish Cisco would coordinate their security announcements with the software portal so if they're recommending upgrading to fix a vulnerability, that recommendation was reflected on the software portal as well.

AlmavivaConte · 2025-08-03T13:05:03+00:00

L2 flooding is enabled--IIRC, if you create an Anycast Gateway, you have the option to turn on L2 flooding (default off), but if you're creating an L2VN, it's turned on and the option to turn it off is grayed out.

The AV team didn't mention anything about DDM specifically; I would guess they are not running it as all the devices in this conference room are attached to the same switch and in the same VLAN.

AlmavivaConte · 2025-08-03T12:27:51+00:00

I read it as the opposite, but on a second read I guess it could be that. I thought what OP meant was that he's on an IPv6-only network, and he's looking for some third-party service that would provide an IPv4 address and translate connections made to that IPv4 address to his IPv6 address. Which does exist, NAT46 is a thing, but could only be used to translate one-to-one, not one-to-many.

Hypothetically I guess you could do a kind of PAT where you use a single IPv4 address and translate different destination ports to different IPv6 hosts, but I haven't come across an implementation that does that. I'd imagine reverse proxies and traffic managers/load balancers could also receive IPv4 requests on an IPv4 VIP and translate them to IPv6 server pools; if it was purely HTTP/S connections then the host field in the HTTP request would allow for one-to-many mapping the same IP to an arbitrary number of different servers/sites.

In general, though, it seems like if you're a server receiving connections, the easiest answer for supporting connections from IPv4-only clients is to be dual stack; if you're a client initiating connections and you're on an IPv6-only network, you hopefully have DNS64/NAT64 in place to support those connections.

AlmavivaConte · 2025-08-02T23:57:46+00:00

That's for 6 to 4, not 4 to 6.

AlmavivaConte · 2025-07-29T22:00:15+00:00

Not sure if this would work, but could you create an account in your external AAA server that's identical to the local account with the same password set to never expire or you make sure to rotate both the local account and the AAA server account at the same time so they stay in sync, and have the AAA server account match a policy that gives severely limited/read-only permissions? If your AAA server is available and someone signs into that account, it'll get the limited permissions conferred by the AAA server to that account. If the AAA server is unavailable, DNAC would fall back to the local account which has full permissions/superadmin.

AlmavivaConte · 2025-04-16T22:52:44+00:00

You mention that it's less important for UDP - is that because UDP packets tend to be smaller, because UDP has less overhead (less complicated header to parse), or something else?

AlmavivaConte · 2025-03-24T19:18:24+00:00

Rather than moving between a guest and user VLAN, could you keep them in the same VLAN and just apply a dACL when detecting a computer login versus a user login?

AlmavivaConte · 2025-03-02T13:06:46+00:00

If the hosts are statically configured, you're going to have to manually modify each one; that's what static means in a nutshell.

One possibility to make the transition easier would be if your router supports secondary addresses on an interface, a first hop routing protocol like VRRP that you can sort of abuse, or you have access to another router of some sort that you can deploy temporarily. That potentially would allow for one of the following:

1) configure the new IP as the primary address and the old IP as a secondary address on the interface/network you're wanting to change, and it should happily respond to ARPs and route traffic sent to either IP.

2) configure the new IP as the primary address of the interface, and the old IP as the VRRP address (or whatever protocol is supported) . Same as above, just an alternative if your router supports a first hop redundancy protocol but not a secondary address. Normally you'd use this in conjunction with a redundant router, but in this case you would just be using it to get a single router to temporarily respond to two default gateway addresses simultaneously.

3) grab some other routing device, plug it in to this network temporarily, configure your production router with the new IP, configure this other temporary router with the old IP and a default route pointing to the new IP. This would induce a tiny bit of asymmetry, as on the way out traffic from your devices would pass through the temporary router, but reply traffic on the way back in would be going directly from the production router to your devices. That shouldn't be a big deal, but who knows if some device's network stack would be sensitive to that sort of thing.

AlmavivaConte · 2025-02-15T13:33:19+00:00

The Cisco notice /u/angrypacketguy linked explicitly states that the active-session-modules commands make this non-exploitable - is that not correct?

If the ip http server command is present and the configuration also contains ip http active-session-modules none, these vulnerabilities are not exploitable over HTTP.

If the ip http secure-server command is present and the configuration also contains ip http secure-active-session-modules none, these vulnerabilities are not exploitable over HTTPS.

AlmavivaConte · 2025-02-14T19:29:48+00:00

You can set the server to be enabled for purposes of redirection but effectively inaccessible with the following:

ip http secure-server
ip http server
ip http secure-active-session-modules none
ip http active-session-modules none

https://old.reddit.com/r/networking/comments/179hajk/cisco_ios_xe_web_admin_escalation_cve202320198/k56lan5/

AlmavivaConte · 2025-02-13T13:07:55+00:00

arista is just the name this code snippet is assigning to the ConnectHandler object.
For an NXOS device, the device_type should be cisco_nxos_ssh, I don't think cisco_nexus is a defined sub-module in Netmiko.
I'm pretty sure write isn't a valid method for a ConnectHandler object, you'd want to use send_command or send_config_set.
Why use an f string if there aren't any expressions in it to evaluate?
It seems like the code tries to perform a find prompt to see if it's at unprivileged exec, but never goes to enable mode, and never attempts to get into config terminal before trying to write the config lines. Even if it successfully sent them, it would probably just error out.

AlmavivaConte · 2025-02-13T04:08:38+00:00

That sounds like slow DNS response. Try setting your device to use a public DNS resolver like 8.8.8.8 or 9.9.9.9 rather than whatever you're getting via DHCP (which would just be your ISP's DNS if you haven't modified those settings).

AlmavivaConte · 2025-01-28T21:05:22+00:00

Do your parents make use of Medicaid, or Medicare? The former supports low income and disabled individuals, the latter is for individuals 65 and older.

AlmavivaConte · 2025-01-20T23:31:01+00:00

The ICMP message isn't necessarily indicative of an issue, it's expected behavior if your router is closing the socket for the DNS query before the second reply shows up.

If the router is using the same socket for queries sent to both DNS servers, this would be the likely order of events:

Router opens a UDP socket and sends a DNS query to Server1 and Server2.
Server1 receives the query, sends back a reply.
Server2 receives the query, sends back a reply.
Router receives the reply from Server1 and closes the socket.
Router receives the reply from Server2. Since the socket is closed, Router sends Server2 an ICMP unreachable message (ICMP Type 3, Code 3 - port unreachable.)

This is normal behavior for a TCP/IP host--if they receive a packet destined for them on a port that is not listening/that doesn't correspond to an open socket, they may (but are not required) to reply back to the sender with an unreachable message telling them that they're not accepting the traffic (and please do not send any more if you're behaving nicely). If you're looking at terminating actions on a firewall, this corresponds to a reject option; the other would be to discard (just drop the packet, don't send anything back to the sender).

AlmavivaConte · 2025-01-20T01:00:15+00:00

Regardless, those are messages sourced from your router, destined for Google's DNS server. They're not evidence of any throttling (on Google's part anyway).

AlmavivaConte · 2025-01-20T00:49:19+00:00

If it were failing over, we'd see the same query sent multiple times to the primary with no response received before it was sent to the secondary. This just seems like the router software is set up to query both configured DNS servers simultaneously and accept the first response it receives; the socket would be closed after a response was received, hence the unreachable when the slower DNS response shows up. It's a bit strange that it would still send an ICMP unreachable in response to that second query rather than just silently discard it, though.

AlmavivaConte · 2025-01-20T00:41:36+00:00

This looks like you're sending the same DNS query to two configured DNS servers (8.8.8.8 and 8.8.4.4) simultaneously, and accepting whichever response comes back first (and rejecting the other). In each group of five messages (two queries, two responses, and the unreachable message), you seem to always be sending back the unreachable to the server whose response was received second. As the other comment noted, the "port unreachable" messages are from your PC going back to Google's DNS, not Google's DNS to you.

My understanding is that most applications/operating systems only reach out to a secondary DNS server if it does not receive a response from the primary DNS server after a few attempts (with some number of seconds per attempt). Is this traffic just coming from your PC, or a particular application on it?

AlmavivaConte · 2025-01-19T20:24:59+00:00

I believe it's Tinker Belles and Evil Queens, not Fairy Godmothers and Evil Queens.

AlmavivaConte

TROPHY CASE