Does anybody know of a workaround for using MLS on an interface that has an access-list with the established command on an entry?
I have read that using the established command stops MLS from working. I currently have an interface that I want MLS on, but have an access-list on it with the established command. I cannot really change the list !
Any help would be much appreciated
Is this in or out access-list, the way i would try to get around this (NB!! have not tried it as yet) is manually set the flow mask on the SE with "set mls flow" command. This should override MLSP.
Prior to 12.0(X) forgot what it was you could MLS did not support input access-lists.
There is an inbound AND an outbound access list on this interface both with the established command on one line.
I cannot see it working because the router would need to analyse ALL packets in the flow looking for the ack bit to be set !
PS - what would setting the flow manually do?
Setting the flow mask manually should force the SE and RP to look at say the desitnation IP only, if you have a full flow mask then the flow is switched on L3 and L4.
So of for eg you set set mls flow destination, then this will only create L3 entries in cache based on L3 destination address only, also bear in mind that the longer the info required for the flow the more cache you will take up, also bear in mind a flow is unidirectional in MLS.
But it still wouldn't work would it, because the established statement makes the RP need to look at every packet, stopping the SE from forwarding the flow.
Plus, I believe that MLS will be disbaled as soon as the access list is applied to that interface.
Thanks for your help again !
MLSP carry through the mask from the RP to the SE, this is done so that you get the "correct" flow mask.
So if you have an ACL then MLSP would carry that info up to SE, this would then config the flow mask to whatever closest matches the access-list, hence the reason for FULL FLOW mask which includes IP Src/Dst and TCP/UDP src/dst.
So going back, if you explictly configure the flow mask on the SE (even though you have extended ACL on the RP) to destination then the it should not switch based on the extended ACL but rather DST IP address only.
As stated i have never tried this but looking at debug's and reading the DOC about flow masks this would seem the correct way to go.
Have you tried to force the flow masks. I was doing some thinking " as one does at 1:00am" and forcing the mask should take care of the extended access-list. As said i have not tried this before but can set it up in a LAB.
Theoritically yes, the reason i say that is that the flows will not be built on TCP/UDP but only destination IP address.
The flow matches the access-list, so full flow is IP and UDP/TCP src/dst, whereas destination is Duhh!!! :))) destination IP only so MLS will only build and switch flows based on the flow mask of desination IP hence bypassing the ACL.
But if a flow was established for all traffic to 10.2.2.2 , then this would allow all ports, even if the access list blocked say smtp traffic. This would in effect render the acl redundant?
Am I right in thinking this?
The thing is, I still want the acl to function !
If a flow is established yes it will allow all TCP/UDP ports through. Your original question was to get the established keyword not to affect MLS.
Also bear in mind flow masks are can be set to DST, DST/SRC and Full, so yes you have limited options with regards to MLS and access-lists.
If you want the ACL to function with established then i would suggest dropping MLS on that interface.
The other way is how the ACL is constructed if you can make it granular enough and then apply say a flow mask of src/dst.