We have to redesign our WCCP setup at the branch office, because WAAS VB doesn't support standby. Our current design is having 2 WAN routers, one is for the primary WAN (MPLS) and the 2nd is for a GRE backup. Both WAEs GIG 1/0 interfaces are plugged directly into a 4ESW-HWIC module on an ISR router on the primary one, GIG 2/0 interfaces are plugged directly in another 4ESW-HIC module on the backup GRE router. The 4ESW-HWIC doesn't support port-channel so this is my reasoning for the redesign. See attached WAAS_Branch_Current_Design PIC.
The WCCP 61/62 options are currently configured on the LAN facing interface on the routers, 61 out and 62 redirect in for load balancing based on destination IP address. The new design is moving the WAE to the CORE layer and configuring port-channel since we’re going to be using VB at the branches. The WCCP will still be done at the WAN router edge. I was told it’s best to use the WCCP option inbound only, rather than an outbound redirection.
Based on the attached WAAS Branch Redesign PIC, would there be any WCCP routing loops with respect to where I have placed the 61 and 62 options? Some branches will have remote sale centers hanging off of either the WAN primary router or the GRE backup router, but not have WAAS. It’s most likely traffic could be seen twice on a 61 redirect in. One of the designs I’ve seen in a PDF doc from Networkers (BRKAPP-2021) showing the 61 and 62 are on the WAN facing interfaces to avoid WCCP routing loops with a dual router scenario at a branch site. The number of uses will vary from 50 to 400+. I want to keep the design the same for every branch.
I do see one potential issue, but the diagram isn't clear enough to be sure. I can see that both WAEs are on VLAN 73, but I don't know where that VLAN terminates. If it terminates on the switch and then it is a L3 hop to the router, you will have a routing loop. Basically, you have put the WAE in the same path as the user traffic. This "fix" for this is to enable the GRE Egress Method on the WAE. That will also cause the WAE to send the traffic back to the router that sent the traffic to the WAE which also prevents the router1-to-router2 traffic which can also cause loops.
Thank you for your response. The reason for the redesign is to support virtual blades. I don't want to send the VB traffic all the way up to the WAN routers. The VLAN 738 on the new design will live on the core switch and WCCP will be performed on the WAN routers. So yes, I will be using WCCP negotiate returnmethod. The only concern I have is you will be bouncing the traffic in an out of the LAN facing interface on your WAN router. Basically you will be sending all of your original traffic andoptimized traffic out the same LAN interface, possibly doubling your volume on this link if you don't get good compression. Do you see a potential delay in this setup?
Actually, you will potentially triple the traffic between the switch and router.
1, original traffic
2, GRE from router to WAE
3, Optimized traffic from WAE back to the router also in GRE.
This will depend on the model of router, the features running on it and the WAN bandwidth.
So, these questions really need a much deeper dive, especially since you said you'd like a "standard design for your branch sites and they can have between 50 and 400 users. The rule of thumb is 10 TCP connections per user, so with 400 users you will be looking at a 7371 which doesn't support VB anyway.
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
In the Previous articles of ACI Automation, we are using Postman/Newman as the Rest API tool to automate the ACI Configuration.
In this article I’m going to discuss on usin...
One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article wil...