Hi,
The items that you mentioned have been significantly increased:
Example for BGP on 6300:
6300# show capacities bgp
System Capacities: Filter BGP
Capacities Name Value
-----------------------------------------------------------------------------------------------------------
Maximum number of AS numbers in BGP as-path attribute 32
Maximum number of BGP as-path entries in a single aspath-list 128
Maximum number of aspath-lists 256
Maximum number of community entries in a single community-list 128
Maximum number of community-lists 256
Maximum number of equal cost paths 8
Maximum number of BGP neighbors allowed across all VRFs 256
Maximum number of BGP peer groups allowed across all VRFs 50
Maximum number of routes accepted from a BGP peer 64000
Maximum number of routes in BGP RIB 128000
Maximum number of BGP route reflector clients allowed across all VRFs 256
Maximum number of prefix entries in a single prefix-list 128
Maximum number of prefix-lists 256
Maximum number of route map entries in a single route-map 128
Maximum number of route-maps 256
256 route-reflector clients is not a problem assuming we stay in a reasonable RIB size.
I agree that documentation for large scale deployment would be helpful. This is work pending.
In parallel, for large scale deployment, I would to validate the design with the help of your local Aruba SE (or partner)
who will link with R&D for recommendation. Multi-dimensional scale is always a complex exercise that is often a case per case validation.
------------------------------
Vincent Giles
------------------------------
Original Message:
Sent: Dec 14, 2020 01:59 PM
From: Dik van Oeveren
Subject: EVPN in larger campus environment
Hi,
All I can say is: watch the space. I am totally with you and you have the right platform (6300) for the future. :-).
------------------------------
Dik van Oeveren
Original Message:
Sent: Dec 14, 2020 11:41 AM
From: Jukka Aaltonen
Subject: EVPN in larger campus environment
Yep the CX is evolving platform and we've hit few bugs along the way as we implement them in the access layer. Nothing major, and it's going to the right direction. However i'd like Aruba to have some guidelines how to deal with larger networks with EVPN. As there are options like just doing VLANs from access to aggregation and then use EVPN in the core, or do iBGP within a building/pod/zone/whatever you want to call it (which is sort of uncertain now as it would require lot more iBGP peerings), or do eBGP between the switches. It's not very feasible to change the whole architecture whenever new limits are released, so it'd be nice to have at least some guidelines where to aim :)
Or maybe even transition to model where every building has a gateway? Though it's probably bit too expensive now for us when you compare the performance of switches/separate firewall devices to gateways ;)
And now that there is 6200F without EVPN support, should we go with those instead of 6300F which are more expensive and you don't know whether we can implement the EVPN at all in their lifespan...
So far we've been doing dynamic segmentation with 6300Fs and it has been working great. I don't think we have a real need for EVPN at the moment but as these things tend to be decisions for many years it'd be nice to have some ideas how to build larger EVPN networks too should there be any need. For example even in zero trust architecture we might just have all our workstations in a single /16 subnet to make configuration easier, as clients would have all those fancy new softwares to protect them. It would make configurations lot easier when you wouldn't need to worry about and configure different sized subnets everywhere. And maybe we could just call that client VRF "internet".
We've been doing lot's of stuff regarding dynamic segmentation and SD-WAN with our SE so I'd rather have him figure out those and not these future EVPN plans. I'm however hoping that I'm not the only person with Aruba gear trying to figure out how larger EVPN networks would work and someone else also would have thought about these :)
Original Message:
Sent: Dec 14, 2020 11:06 AM
From: Dik van Oeveren
Subject: EVPN in larger campus environment
Hi,
Typically, the way this works is that when a switch is released, the functionality and limits are verified. This is a very intensive process, and once the capabilities are verified and qualified, then these become the supported capabilities. The hardware is capable of supporting more, however before these capabilities are committed, extensive testing is conducted. As an example, when the 8325 was first released, it supported 8 VRF's. With the release of 10.06 code, the 8325 now supports 65 VRF's (on the same hardware). The 6300 and 6400 have just been released this year and I am confident that the capabilities of the switches will increase in the future.
In addition, VTEP's in campus are usually deployed in a situation where east-west traffic is a better option than north-south. Aruba is very much in favor of a zero trust architecture, where all traffic is inspected by a security device (being an Aruba gateway, or a Layer 7 stateful firewall) instead of uninspected (stateless Layer 4) between devices through VxLAN.
Aruba has deployed many VNBT (User Based Tunneling) solutions with very large customers, so I am confident that the Aruba ESP solution will also fit in your network.
Have you talked with your local Aruba Systems Engineer?
------------------------------
Dik van Oeveren
Original Message:
Sent: Dec 13, 2020 05:45 PM
From: Jukka Aaltonen
Subject: EVPN in larger campus environment
10.06 IP Services Guide says: "Maximum route reflector clients allowed across all VRFs: 16"
I really hope this is a typo in the documentation. In our newest building we have 350 x 6300F and 6400 aggregation, if 16 is limit for RR clients then it would not be possible to configure those in a single OSPF domain. We would probably have stack of 2-4 members so we could cut the neighbor amount down. And also licensing, as with dynamic segmentation you only need one license ber stack.
Also maximum amount of VTEPs is 128 so if we'd like to do VNBT we would need to push the amount of logical switch stack under that. And then use eBGP from the building to next switches.
As the limits are so low I wish Aruba would provide some guides how to configure VNBT in an environment larger than 126 access switches. Which isn't that much I would say.
Original Message:
Sent: Dec 05, 2020 09:07 AM
From: Jukka Aaltonen
Subject: EVPN in larger campus environment
Is there any documentation available on how to configure larger EVPN/VXLAN based campus networks? I've seen the VNBT guide from the support files but that's only like 2 core switches and then couple campuses with few switches each. How about if we're talking about 2000-3000 access switches? I guess it's not very reasonable to do VXLAN tunnels from every access switch to every other access switch but we would need to somehow split the EVPN domain to different parts.
Maybe one OSPF area 0 and iBGP per campus building (200-400 switches per building) and then eBGP between the building and the core switches? Or maybe go full BGP from the beginning?
From what I've understood so far I would need to have "leaf" type of switches as the border nodes too to terminate the VXLAN tunnels from the building and then stitch it to the next building and all withing one tunnel or something like that? But I'm not yet quite sure how this would work.