Hello community,we are currently running a POC for TapAggregation at a customer site.
Now we have several issues:
That leaves us with traffic steering via policy-map but that also comes with surprises. For testing we have a simple ACL denying traffic from a certain subnet:
To achieve our initial goal I have to create two more ACLs and class-maps, one that allows the subnet that I don’t want …
My question, if someone actually read this far is: Is it really that complicated or am I missing something???
Yes, you’re right, egress ACLs on 7280SE are not supported.
To clarify something there is only po25 and po27 right? I saw you wrote po17 as well, I assume that is po27?!
Afaik, using the class-map/policy-map approach is the right way to go.
These articles might be useful for you:
https://www.arista.com/custom_data/aws3-explorer/download-s3-file.php?f=/support/download/DANZ-TOI/DANZ-TOI-5.0.pdf (if this link is not available than you can go to http://www.arista.com — Support — software downloads — TOI tab and you’ll find it there)
Can you attach your inital config that wasn’t working, not sure if I understand it exactly.
From your inital ACL:
On the IPv6 issue, where you aren't seeing the IPv6 traffic on Po27, I suspect that the cause may be that you don't have a permit statement to cover IPv6 traffic and are hitting the implicit deny. Please try adding the permit ipv6 statement to the ACL. Feel free to open a case anytime you have an issue by emailing email@example.com and we'd be more than happy to help
I think I can help a bit here but you are on the right track. Here are a couple of items that pertain to this from the DANZ TOI
– Tap Aggregation policy maps do not have an implicit deny associated with them. (whether you figured that out or not, your second example accounts for this.)
– Any packet not matching a policy map used for traffic steering will be replicated out all tool ports in the default aggregation group corresponding to the tap port the packet was received on.
– If no default group is selected, the packet will be dropped.
An explicit deny will also drop the traffic. So the permit statement match is what is used in the policy map to direct matched traffic and deny simply drops it.
I think there are ways to optimize your class maps though. For example, from your config:
10 class CM_SUBNET
SOME_TOOL is the default group on ports et1-8 so this traffic associated with class CM_SUBNET should already be going to the default group, from what I can see you are not attempting to ”steer” this traffic as it will pass to all ports in the default group naturally:
ip access-list ACL_SUBNET
There may be some additional things you can do to reduce the config. Are you a reseller and working with an Arista SE or an end user customer? We can work with the account team and support to engage and help with more detailed advice.
Please let me know if this is helpful.
Thank you Tamas and Corey for providing some valuable input!
The configuration we assumed would work but didn’t was simply using the ACL_NO_SUBNET to steer traffic to po27 (yes, po17 was a typo) and hope that automatically all traffic would go to po25. Turned out that’s not the case and you provided the reasons why.
Yes, we’re a reseller working with the customer. We have an SE involved, too but he’s quite busy and this wasn’t a particularly urgent topic so I thought I’d give the forum a try. Turned out to be a good move :)
What I deduct from the sources provided and Corey’s comment is that we pretty much configured things correctly.
The problem with IPv6 – well it’s not really a problem, just something one needs to know – is that it’s not possible to allow IPv6 traffic in an IPv4 ACL. I still wonder why it’s not send to po27 then since there is neither a permit nor a deny for any IPv6 but I can accept that that’s the way it works.
I will do some further testing before I mark this question as resolved but I’m quite sure we’re good now. So thank you once again!
Post your Answer
You must be logged in to post an answer.