Modern day applications deployed in the data centers have become multi-tiered and distributed. This has resulted in an increase
in the amount of east-west traffic seen in the data centers. This includes traffic from physical-to-physical (P-to-P), virtual-to-virtual (V-to-V), and between physical and virtual (P-to-V) workload.
Arista Macro-Segmentation Service (MSS) provides a software-driven dynamic and scalable network service to logically insert
security devices into the path of traffic with complete flexibility on placement of security devices and workloads. It is specifically
aimed at physical-to-physical (P-to-P) and physical-to-virtual (P-to-V) workloads.
What makes MSS unique is that it places the control of policy enforcement directly in the hands of security administrators. This is
accomplished using standards based forwarding with no proprietary frame formats and without placing limitations on where the
service devices must exist within the network.
Arista MSS Deployment Mode:
Many data centers have firewalls deployed in layer-3 mode, acting as first hop for the hosts, serving applications. The Layer 3 Firewall
is connected to the network and configured to enforce policy between different security zones or endpoints.
Instead of using routing policy to attract traffic to the firewall, the Macro-Segmentation Service redirects traffic to the firewall,
dynamically inserting it into the path for traffic between relevant endpoints. L3 Firewall is not configured as a gateway for the
subnet.
Requirements:
• Arista CloudVision running EOS release 4.23.2F or later
• Management Server Versions
• Version R80.30 with API version 1.5 (and above). In addition to this Management Server version, Check Point has provided
a “hot fix” that provides a “Proxy API” ability which allows the user to access the Gateway APIs through a special URL on the
Management Server. This hot-fix is required for MSS to work.
• Gateway Versions: Version R80.30 with API version 1.2 (and above)
Config example:
Direct Flow is enabled on all TOR switches with 100Gbps Interfaces:
!
cvx
no shutdown
!
service mss
no shutdown
policy enforcement rules verbatim
!
dynamic device-set checkpoint
device 10.0.0.200
username admin password 7 xxxxxxxxxxxxxxxx
protocol https 4434
group poc-mss
state active
type check-point management-server
policy tag redirect MSS_redirect
policy tag offload MSS_offload
policy tag modifier verbatim MSS_verbatim
!
service vxlan
no shutdown
Check Point:
Interface Configurations:
Interfaces configured in aggregation groups bond1.100 and bond1.200. bond1.100 is part of the zone ‘Tenant C’ and bond1.200 is
part of the zone ‘Tenant D’
Route Configuration:
The firewall needs to have routes back to the original subnets in which the end hosts reside. Static routes have been created for each subnet. Default GW for the Tenant C subnets is the VLAN 10 interface on the TOR and for Tenant D subnets its the VLAN 20 interface on the TOR.
Policy Configuration:
For Tenant C:
• Web servers can talk to each other directly only on port 443 or port 80 the web servers are connected directly on the same VLAN and IP subnet.
• Web Servers can communicate with the proxy servers on port 8080 HTTP as well.
For Tenant D :
• Web servers can talk to each other directly only on port 443 or port 80 the web servers are connected directly on the same VLAN and IP subnet.
For Tenant C, firewall policy tags defined as “MSS-redirect” (red) are enforced by the Active Firewall.
For Tenant C for proxy, Firewall tags defined as “MSS-offload” (blue) are enforced by the Arista switches locally without being redirected to the Active firewall.
➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips