I'm evaluating Checkpoint Quantum and Quantum Spark. I come from Fortinet and Palo and have very little experience with Checkpoint by comparison. I'd like to hear some subjective opinions on the platform from people who have experience with it.

Hi

I`m review now MPLS FEC topic.

R1----R2----R3----R4----R5----10/8,20/8

FEC is a group of packet one or more packet are treated the exact same way. Does that means if R1 received :

10.1.1.1,10.2.2.2,20.1.1.1,20.2.2.2

and these 4 packets are treated on R1 the exact same way

and on R2 are treated a different way, R3 another way,R4 another way. Does that mean each hop must treat these 4 packets as the exact same way like R1 in order to be on the same MPLS FEC ?

OR

It`s normal for each hop to treat them on a different way and still on the same MPLS FEC?

What i mean does the MPLS FEC is controlled on the ingress PE only ?

OR

MPLS FEC could be controlled on each hop and the FEC is locally significant?

Not sure how to word this lol.

Im talking like weird one off issues that might reoccur, do you have a way to query your ticket system with key words to search for specific issues or do you keep a notebook of these types of things to go back and reference?

Im trying to build out a troubleshooting guide and wanna look for ways to catalog this type of stuff to have something to reference when youre banging your head against the wall.

Edit: ill add i work on a global network - likely large MSP volume (my noc gets probably 20-30 tickets per day shift)

Looking for some advice on a VeloCloud/SonicWall setup.

Our topology is:

Dual ISP → VeloCloud 720 → SonicWall → Layer 3 core → LAN

We're adding VeloCloud 720s in front of our existing SonicWalls. The SonicWalls and network are staying in place; we're simply migrating the public IP termination from the SonicWall to the VeloCloud.

The SonicWall currently has several site-to-site IPsec VPNs as well as several port forwards. As part of the migration, we're configuring a dedicated VLAN/subinterface between the VeloCloud and SonicWall, with the SonicWall using that interface/IP to connect to the VeloCloud.

Our SD-WAN team says we can keep the existing VPNs working by using the remote VPN peer IPs defined in the SonicWall VPN policies as the source restrictions on the VeloCloud NAT/forwarding rules.

We tested this approach successfully at another location. The difference is that the public IP at that location didn't have any existing port forwards.

At this site, the public IP we're moving from the SonicWall to the VeloCloud currently has port forwards for:

• TCP 722
• UDP 21000
• TCP 8080/8880

We also need the existing site-to-site VPNs to continue working with:

• UDP 500/4500
• ESP

So our main question is:

Can the VeloCloud 720 use the same public IP for the existing port forwards while also forwarding IPsec traffic from the specific remote VPN peer IPs to the SonicWall?

Has anyone deployed this type of setup?

We're mainly wondering if the peer-IP-restricted NAT/forwarding approach will coexist correctly with the existing port forwards on the same public IP, or if there are any NAT precedence, IPsec, or NAT-T gotchas we should be aware of.

Thanks!

With my limited IT knowledge, I'm looking to buy a simple switch with a couple of network cables to expand the ports in an office floor box to include another PC and possibly printer.

From my understanding, the switches are simple and all I need is something like this:

https://www.amazon.co.uk/gp/aw/d/B07PYSNSDD?th=1

The floor port sockets run to the main switch in a rack mount.

Am I missing anything that will stop this from working?

I'm assuming some set-ups could only assign certain devices or IP addresses to specific ports in switches but I don't think anything like that has been configured.

Thanks very much and hope you can help.