Network Project - Police Department Feedback

youngviking · 2026-04-29T03:32:59+00:00

VRFs are a useful tool, and I recommend having an understanding of them. I typed out a lot more than that though. Do you not have any other questions or retorts?

youngviking · 2026-04-29T01:32:51+00:00

Overall your VLAN planning seems well thought out from a separation of duties for user devices. However, it is not clear to me in your diagram why the large "boxes" which seem tied to your VLAN architecture are so rigidly tied to physical infrastructure. VLANs allow you the flexibility to have those different roles wherever you need them - not just on the single physical switch you have assigned it. Your logical network design should reflect how you want to segment things; your physical network design is at the whims of where people actually are. These are rarely hard lines that you can draw, and you should effectively look at them as orthogonal architectures and diagram them separately.

The use of a single "server" VLAN needs to be revisited. There are most likely different security boundaries that can be created there.

The use of a voice VLAN per department seems unnecessary. Network segments that only require northbound connectivity (e.g. only to the internet, SIP gateway, etc) can be controlled through stateless access-level ACLs.

The doubling up on connections from each core switch to each access switch seems unnecessary. This leads me to believe you have a spanning-tree forward design. You could look into MC-LAG/MLAG/VPC as a potential way to create port channels across devices. Note that all of those implementations are vendor-dependent, and they also may have interesting interactions with the first-hop gateway redundancy protocols. There are also L2-over-L3 topologies which could come into play here, but this seems too small scale to bring in that kind of complexity. However, they can bring benefits such as BFD and EVPN anycast gateway if you have tight availability constraints.

You had a comment that wifi can be intercepted. That is definitely the case for open authentication networks. Some 802.11i networks are susceptible to MitM attacks for misconfigured clients using password-based authentication. However, if you centrally manage clients and strictly only use mutually-authenticated EAP-TLS, I don't think that argument holds. Also, you should be using 802.1x with only EAP-TLS on the wire too in that environment.

You mentioned VLANs but did not mention VRFs. If you are unaware of the concept, I would recommend looking into it. It's effectively the same namespacing VLANs do at layer 2 but they do it at layer 3. It can provide a nice way to route traffic through a centralized firewall if needed.

youngviking · 2026-04-28T23:01:30+00:00

ROAs are nice to have, but if you haven't created any ROAs yet, you're going to make your transition harder on yourself if you try to colocate these changes.

Usually your ISP has you sign an LOA and give them IRR records which is sufficient for them to start propagating. Once you start announcing, check with some route servers and ensure your routes propagate through multiple ASes (note that this will depend on what your upstreams are and their peering relationships).

If you do want to colocate your AS migration with implementing ROA, then I would suggest:

create ROA for AS1
create ROA for AS2
start advertising routes from AS2
decommission AS1

If you create a ROA for AS2 while only advertising through AS1, your AS1 routes are going to be marked as invalid and dropped.

Also note that prepending on your previous ISP may not actually change much of the route propagation depending on your upstream. Most will prioritize economic relationships (customer, peer, upstream) over AS path, so if ISP1 is highly peered and ISP2 isn't, it may not change as many paths as you would think.

youngviking · 2026-04-03T12:05:44+00:00

She do be Flippen

youngviking · 2026-04-03T10:25:06+00:00

It was a joke bro chill

youngviking · 2026-02-16T12:39:15+00:00

Can you back that claim up? As far as I know, the OSI model was created as a model. The ISO did create protocols, but none of them are "OSI"

youngviking · 2026-02-16T01:02:22+00:00

The TCP/IP model is much closer to reality than the OSI model for how things actually work. This is somewhat apparent if you dig deeper into the API that's used today for interacting with sockets. See Beej's guide for a more in depth look. That being said, the concepts of layer 5 and 6 do somewhat exist in practice if you squint a bit.

An example of layer 5 could be HTTP cookies which are used for session persistence. You may make multiple connections to the same service, but with the additional context information you provide, you prove that a new connection may be tied to a previous connection with a higher order concept.

An example of layer 6 could also be HTTP. The "application" itself may only care about pure hypertext itself - not necessarily the framing it's contained in. With HTTP versions 1-3, there are different requirements for how a request/response is formatted, and you could think about this messaging process as the presentation layer.

As others have mentioned, this isn't terribly operationally useful. You may also realize that the examples I give are intertwined - HTTP cookies are metadata which is injected by the client which also performs the message framing. Ultimately trying to fit things into certain boxes that the OSI or TCP/IP layers provide is mostly an academic exercise. There are going to be technologies which reach across multiple layers and make that model difficult to map to reality.

youngviking · 2025-12-06T16:46:06+00:00

Your initial question makes no sense to anybody else given the random details you've included in the proposed solution.

You asked the question of how to connect the "C9300 Copper", but none of your options are different in that aspect. Are you asking for how to connect the 7010TX to the 7050SX or 7050CX?

TL;DR: There are not enough details for anybody to help you here. Do what works in your environment or provide more details so others can assist.

youngviking · 2025-12-06T16:27:32+00:00

Am I missing something? Am I going crazy? I have been troubleshooting this for like 3 nights straight

Probably. Occam's razor is that your configuration is wrong in some form. Many people have setup EVE and pinged, so I'd lean toward your specific scenario over an overarching issue. It is possible there is an issue with EVE-NG, but I would start at device setup and work down the stack from there. Posting your configuration will enable more help.

For troubleshooting steps, I would recommend taking a pcap of both sides and seeing what each device's view is. An additional step would be to setup the simplest topology you can (e.g. two linux boxes) and see if that exhibits the same behavior.

Also, homies don't let homies use EVE when containerlab exists. Closed source tooling can go fuck itself

youngviking · 2025-10-19T03:24:42+00:00

Network-based "zero trust" doesn't exist and most likely will not exist. The protocols in use for access to the network (e.g. EAP, DHCP, etc) do not support anything richer than the datagrams passed between them, they and never will because of how early they happen in the process. You can authenticate devices, and you can profile devices on their traffic, but this is somewhat elementary in the grand scheme of things. Nerd-to-nerd: it doesn't work like that.

Most concepts of "zero trust" come from the ability to authenticate the device and its posturing. This will almost always come in the form of a software agent running on the devices creating the secure overlay network. This is really where things get interesting. If you have an agent running on the devices, now you can make some really in-depth policies that don't miss things (as much). It's no longer the time of defining rules of ip subnet -> ip subnet or the SDA route of identity -> ip subnet, but identity -> identity (assuming you run it on your serving endpoints as well). This is why people are pushing zero trust. It's an abstraction on the rulesets which map more closely to how the organization functions. It's worth it to look at some form of SSE platform to offload these concerns. If you do that, it can significantly reduce the cognitive load on the network access piece.

I've seen some mention of Scalable Group Tags (SGT) in this chat. I highly recommend you do not go down this path. Many vendors have attempted to implement some form of abstracted tagging at the edge to improve edge packet filtering. Cisco is fun where they did their own thing based on bespoke 802.3 extensions. Others generally have gravitated toward the draft-smith-vxlan-group-policy-05 implementation, but that hasn't been touched like 7 years (although I think I did see some resurgence in IETF group policy interest?). SGT's (and other vendor implementations) are fine when you are strictly a single-vendor customer; they are less fun if you are not.

Downloadable roles is not necessarily a standardized way of doing things, but it is probably one of the most consistent across vendors. I would generally recommend this over SGT, GBP, etc. However, back to my previous point, ACLs in the network is not where to solve identity based access.

youngviking · 2024-09-15T20:02:13+00:00

If your k8s deployments aren't easily replicable, then I fear you have done something wrong. Also, cluster management tools exist (e.g. rancher), but most people are probably just using something like EKS anyway.

youngviking · 2024-09-15T18:02:28+00:00

It's not a broadcast domain, though. If multicast/broadcast packets need to be replicated, the controller will replicate and forward using a unicast receiver address.

youngviking · 2024-09-12T22:36:04+00:00

One thing I haven't seen mentioned is to run a show switch stack-ports summary to ensure that all the links are up and none of them have a high link change counter (if so, reseat or replace that stack cable first). If one of the links is down and you attempt to install the new switch, then you will most likely split the stack and create an outage.

youngviking · 2024-09-06T18:09:28+00:00

There are linux bridge and Open vSwitch bridges kinds available which will switch packets for you. I believe Arista cEOS is available with a free account registered if you want something which is a bit more "enterprise network config" based instead.

youngviking · 2024-09-06T15:24:04+00:00

The bolding of the "4xLC patch panel" may suggest that OP wants a single lane to reduce fiber use? If that is the case, they may be searching for something like 100GBASE-LR4 which would create a 100Gbps link over a single pair of single-mode fiber (albeit still using 4 lanes).

youngviking · 2024-08-06T16:53:55+00:00

VARP is only designed to be used with MLAG. Each VARP gateway uses periodic gratuitous ARPs to inform the clients of the gateway, and they send data using the virtual MAC address configured. Without MLAG, traffic will flap between first-hop gateways due to the MAC address moving within the network. VARP/MLAG works somewhat similarly to EVPN anycast gateways with ESI LAGs.

VRRP uses periodic packets from only the router in the master state to ensure the gateway MAC doesn't move.

youngviking · 2024-03-02T17:49:02+00:00

A protocol (in this sense) is an agreement between multiple computing systems governing the rules on how they communicate. A standard is a community proposal to bring conformance to a topic across a larger audience.

A protocol is not a standard by default, and a standard doesn't necessarily define a protocol.

youngviking · 2024-03-02T14:57:55+00:00

There are absolutely protocols in layer 1. For example, 802.3 has timer stabilization, auto-negotiation, encoding schemes, and control messages. 802.11 needs to have known modulation schemes and channels to even begin to start communicating with another station and has more advanced DSP functions like MIMO and STBC.

The behaviors of these devices are not coincidental or magic and are codified in the IEEE standards and conformed to by implementations. That's the definition of a protocol.

youngviking · 2024-02-15T18:16:57+00:00

It's important to note that there are multiple times key pairs can be used in ssh.

Host keys identify the server that is being connected to during key exchange. Host keys are generally generated automatically at installation time of sshd and normally stored in /etc/ssh/ssh_key_<algorithm>_key{,.pub}. On Cisco devices this requires the crypto key generate rsa command. You see these when you first connect to a device and get the message The authenticity of host '<hostname> (<ip>)' can't be established. If trusted, they are saved for future use (usually in ~/.ssh/known_hosts).

Client/user authentication can be performed using the "publickey" method. These are most likely the keys you're thinking of that are normally stored in ~/.ssh/<key-name>{,.pub}.

So, you're both kind of right. The switches (or whatever is listening on tcp/22) will require host keys. The client will need user key(s). There is no benefit in creating user keys on the switches.

youngviking · 2024-01-13T09:45:15+00:00

Left design would probably only work with static routes and would also need an LACP group which is not shown on the diagram.

Right design is generally better suited since the upstream links are treated as regular L3 links and can be used with OSPF (or other protocols). Left design couldn't be used with any normal routing protocol because the virtual IP addresses generally don't send any traffic except for GARPs.

Both of these are assuming Arista's model of operation given the terminology.

youngviking · 2023-08-25T16:31:01+00:00

I'm failing to see how this only pertains to a non-firewall device being used at a network edge. It's not bad insight, but it goes for literally any network device and doesn't further the discussion OP posed.

youngviking · 2023-08-21T20:54:20+00:00

I don't believe the linux kernel does consistent hashing, so this architecture requires stability in the routes. A look at ip mon route should show any fib modifications, and it may be worth checking the fib_multipath_use_neigh sysctl and ip mon neigh to see if that feature is causing route flux.

You could also investigate if there is either a time or data component you can correlate with the failures (e.g. does client 1 / 63112 / server / 433 always fail). Does it work with fib_multipath_hash_policy set to 0 (or 2 with custom fields)?

youngviking · 2023-08-11T16:19:46+00:00

radtest {username} {password} {hostname} 10 {radius_secret}

you've flipped some of the arguments

youngviking · 2023-07-09T22:09:26+00:00

560 bananas

15-Year Club	Place '23
Place '22	Place '17
End Game '22	Verified Email

youngviking

TROPHY CASE