Wired Intelligent Edge

 View Only
last person joined: yesterday 

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution
Expand all | Collapse all

Aruba CX10000 capabilities

This thread has been viewed 30 times
  • 1.  Aruba CX10000 capabilities

    Posted 8 days ago

    With curiosity I am reading  about the Aruba CX10000 switch and its L4-7 capabilities through the AMD Pensando DPU. I can see the benefits from being able to offload some of the functions traditionally done by Firewalls of platforms such as NSX. But what UTM functions such as Antivirus, or IPS? Is that something that is possible with the CX10000? Or is the current capability more focused on L4-7 filtering not necessarily other UTM functions?

    It would also be nice if someone can point me to a more detailed design/validated datacenter design VXLAN EVPN with ToR segmentation.


  • 2.  RE: Aruba CX10000 capabilities

    Posted 8 days ago

    C10K switches are positioned for controlling east-west in a DC and support firewalling, NAT and encryption, they don't provide IDS/IPS or AV functionality.

    If my post was useful accept solution and/or give kudos.
    Any opinions expressed here are solely my own and not necessarily that of HPE or Aruba.

  • 3.  RE: Aruba CX10000 capabilities

    Posted 7 days ago

    This is L4 FW not L7 FW/IDS/IPS.

  • 4.  RE: Aruba CX10000 capabilities

    Posted 7 days ago

    Can I assume that the L4 FW is just the beginning, that seems very similar to programming TCAM. I thought the power of the DPU is its programmability and thus the ability to program IPS capabilities or at least URL filtering. Maybe this will be a future add on. 

  • 5.  RE: Aruba CX10000 capabilities

    Posted 7 days ago

    CX10000 does L4 FW, IPSEC, IPFIX, NAT.

    Regarding L4FW, it is not like configuring TCAM. Configuring TCAM does not provide stateful firewall. Return packet with 10K is allowed thanks to the fact that previous outgoing packet has been seen. 

    Hope this clarifies.

  • 6.  RE: Aruba CX10000 capabilities

    Posted 7 days ago

    Thank you,

    Does this mean that traffic is filtered both at the ingress direction (source) as well as at the egress direction (destination) and that it acts as a reflexive access-list?

  • 7.  RE: Aruba CX10000 capabilities

    Posted 6 days ago

    The  terminology and some concepts are different. The CX 10000 has two types of policy.

    • Traffic leaving the a workload/host and entering the switch is subject to an 'Egress Policy'.
    • Traffic coming into the host will be subject to an 'Ingress Policy'.

    Policy rules are applied using the standard convention of leveraging source-dest protocol port combinations, the 5 tuple values. To take a simple example:-

    • Policy is applied between src-dest IPs as an 'Egress' policy
    • Source 'IP A' will be the initiator flow (I)
    • Destination 'IP B' will be the 'responder' flow (R)
    • Both 'I' & 'R ' flows will be allowed if a permit rule is applied between 'IP A >>>> IP B'

    So like a reflexive access list, which dynamically allows the return traffic for an established  connection, the policy allows the return path for the 'R' flow without the requirement of an additional 'return path' rule. There the similarity ends with reflexive access lists as the CX 10000 is a 'Stateful Firewall' and is far more secure than a reflexive access list.

    High level Data center with policy design with CX 10000 can be found here in one of the DC VRDs:-


    Steve Bartlett

  • 8.  RE: Aruba CX10000 capabilities

    Posted 5 days ago

    Thank you for explaining the difference and providing the link, this clarified a lot! Intuitively I thought of ingress and egress exactly opposite prior to your explanation. So if I understand correctly, the ingress policy is meant more to filter traffic directed to a host, for example a webserver, only allowing port 443 or 80 for example. 

    The egress policy is the policy that is more suited the stateful firewall, although probably both ingress and egress policies are stateful.

    Part of the explanation on the website confuses me though (see bold), is ingress only applicable to hosts on the same switch? TY again for trying to explain this


    Ingress policy applies to traffic destined to a host in a VLAN with an associated PSM Network, with the exception of traffic between two hosts in the same VLAN attached to the same CX 10000. Ingress policy is generally applied to filter inbound traffic destined to an application server.

    Ingress policy applies to traffic routed between hosts attached to the same CX 10000, when running AOS-CX 10.10.1000 and above. Previous versions of AOS-CX are constrained to applying egress policy between hosts attached to the same switch for both routed and bridged traffic.

  • 9.  RE: Aruba CX10000 capabilities

    Posted 5 days ago

    Yes the terms 'Ingress/egress' are counter intuitive for us networking folk from a network (traffic)  perspective, but  they do work well in describing  FW policies and traffic flows  'from and to' a host/device relative to the CX 10000 FW .

    The stateful FW function applies to both Egress & Ingress FW policies on the CX 10000.

    Typically, 'Egress FW policies' are used for hosts and devices, that are attached to a CX 10000 at the Top of rack. Think  as securing 'East-West' as in 'Horizontal' traffic profiles. This is the 'go to' policy  framework to be applied when hosts/devices are connect to the CX 10000 switch.

    'Ingress FW policies' are very useful to apply policy to secure traffic profiles originating from devices/host that are not connected to a CX 10000 switch. This could be traffic  originating from a host from another Top of Rack switch which is not a CX 10000 , or with a North/South profile - traffic inbound to a DC or 'Pod'. 

    In addition , 'Ingress policies ' support many instances where it enhances the overall security policy framework in conjunction with an 'Egress' policy.

    Ingress policies can be applied to traffic profiles from hosts switched/bridged locally on the same CX 10000 switch or traffic arriving  from  the network spine or core destined to a host on the CX 10000 switch.

    The software constraint you highlighted in the statement in bold,  I read as:-

    applied to software versions prior to 10.10.1000, where an ingress policy could only be applied to traffic arriving from the network 'spine/core' destined to a host on the CX 10000 and not to traffic switched/bridged locally on the CX 10000. 

    From 10.10.1000 release onwards, an ingress policy can be applied to both traffic profiles, locally switched/bridged traffic traffic between hosts  connected on the same CX 10000 and traffic profiles inbound to the CX 10000 from elsewhere in the network, destined to a locally connected CX 10000 host/device.

    The statement is perhaps  a little bit ambiguous, maybe it needs to be read in context, can you provide a link to where you found it so that I can review in it's entirety?

    thank you,
    Steve Bartlett