Posted on August 3, 2017 2:35 pm
 |  Asked by Nik Nik
 |  1619 views
RESOLVED
0
0
Print Friendly, PDF & Email

Hello community,we are currently running a POC for TapAggregation at a customer site.
They have a – in my opinion – quite simple requirement:
– Traffic comes in from tap ports e1-e8
– All traffic should leave tool port po25
– A subset of the traffic – defined by an ACL – should also leave tool port po27

Now we have several issues:
– An IP ACL on tool port po27 does not show any effect. I read that egress ACL might not be compatible with every platform so I guess that’s the reason (we use a 7280SE-64)
– An IP ACL on the tap ports doesn’t work since it drops all traffic on ingress so I can achieve my goal for po27 but not at the same time get all traffic unfiltered to po25

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:
ip access-list ACL_NO_SUBNET
   7 deny ip 10.10.10.0/24 any
   14 permit ip any any
  
If we apply that to a class-map and use that class-map to steer traffic to po17 several things happen:
– there is no traffic from the specified subnet at po27, which is good
– all IPv6 traffic disappears from po17, which is not good
– on po25 – which has the default group and should hence collect all data where no match was found – there is ONLY IPv6 traffic and everything else is gone, which is not good

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 …

ip access-list ACL_SUBNET
   10 permit ip 10.10.10.0/24 any
  
… and one that allows all IPv6 traffic:

ipv6 access-list ALLOW-ALL-v6
   10 permit ipv6 any any
  
Now if we use the policy-map to steer ACL_TMP traffic to po27, ACL_SUBNET traffic to po25 and ALLOW-ALL-v6 traffic both to po17 and po25 we get exactly what we asked for.
However this is quite complex and now I’m wondering if this is actually the way it is meant to be.

My question, if someone actually read this far is: Is it really that complicated or am I missing something???
Right now our customer is quite happy with the results but when they see what needs to be done to get there, their smiles will probably fade away quickly.Thank you and kind regards,
NikP.S. I attached the relevant parts of the config.

Attachments:
0
Posted by Tamas Plugor
Answered on August 3, 2017 3:09 pm

Hi Nik,

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)

https://eos.arista.com/tap-aggregation-traffic-steering/

Can you attach your inital config that wasn’t working, not sure if I understand it exactly.

From your inital ACL:

ip access-list ACL_NO_SUBNET
   7 deny ip 10.10.10.0/24 any
   14 permit ip any any

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 support@arista.com and we'd be more than happy to help

Thanks,

Tamas

 

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.
(meaning, if there is a default group any traffic not matched will end up on ports in the default group. This has to do with the afore mentioned no implicit deny).

– 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
set aggregation-group SOME_TOOL

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
10 permit ip 138.246.2.0/24 any

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.

Thanks,

Corey Hines

(coreyhines at August 3, 2017 3:39 pm)

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.
I’ve not tested it yet but I believe that we cannot ommit the class CM_SUBNET because in class CM_NO_SUBNET we deny traffic to the very same subnet and therefore it is dropped and according to my newly gained understandin not sent to the default group.

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!

Nik

(Nik Nik at August 7, 2017 12:03 pm)

Post your Answer

You must be logged in to post an answer.