This topic is to discuss the following lesson:
The policy is to police inbound traffic to ge0/3 of vEdge2 but why did you apply or enable it in the Egress direction under the ACL/QoS in the feature template?
I see I have the wrong screenshot here, it should show ingress. In the verification, you can see it is applied inbound.
Thanks for letting me know!
Rene
Hi Rene,
thanks once again for your great explanation. Just want to add some notes here.
I believe your configuration is correct. However with the rate of 15000 i didn’t get any drops.
I believe you also didn’t get any policy related drops as stated when you verified it with the commands:
vEdge2# show policy access-list-policers
OOS OOS
NAME POLICER NAME PACKETS BYTES
---------------------------------------------------
ACL-SITE2-POLICER 1.POLICER-TEST 0 0
vEdge2#
and
vEdge2# show interface detail ge0/3 | include policer
rx-policer-drops 0
cpu-policer-drops 0
tx-icmp-policer-drops 0
rx-policer-remark 0
vEdge2#
Your drops / packetloss seemed to be of a different nature and are not related to the policy drops.
When i did the same lab my ping tests were without any packet loss from SW2 to SW3.
I then played around with the policer rate in the “group of interest”.
When i change it down to 8000 i receive ~50 % packet loss.
And this time it is also displayed in the verification on vedge2:
You can clear the statisics using following commands:
vEdge2# clear interface statistics
vEdge2# clear policy access-list
vEdge2#
vEdge2#
vEdge2# show interface detail ge0/3 | include policer
rx-policer-drops 0
cpu-policer-drops 0
tx-icmp-policer-drops 0
rx-policer-remark 0
vEdge2#
vEdge2#
vEdge2# show policy access-list-policers
OOS OOS
NAME POLICER NAME PACKETS BYTES
---------------------------------------------------
ACL-SITE2-POLICER 1.POLICER-TEST 0 0
vEdge2#
SW2#ping 10.3.0.103 re 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 10.3.0.103, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!U!
U!UU!UU!U!UU!UU!UU!UUU!UU!UU!UU!U!UUU!UUU!UU!UU!UUU!UU!UU!U!U!UUU!UU!U
U!UU!UU!UU!UU!UU!UU!UU!UU!UU!U!UU!UU!UU!UU!UU!UU!UU!UU!UU!UU!UU!UUU!UU
!UUU!UU!UUU!U!UU!U!UUU!UU!UU!UU!UU!UU!UU!UU!UU!UU!UU!UU!UUU!UUU!UU!UU!
UU!UU!UU!UUU!UU!UU!UU!UU!UUU!UU!U!UU!UU!UU!UU!UU!UU!UUU!U!UU!UU!UU!UU!
UU!UU!UUU!U!UU!UU!U!UU!UU!U!UUU!U!UU!UU!UUU!U!UU!UU!UU!UUU!UU!UU!UU!UU
U!UU!UU!UU!U!UU!UUU!UU!UU!UU!UUU!UU!UU!UU!UUU!UUU!UU!UU!UU!UU!UU!UUU!U
U!U!UU!UU!UU!UUU!UUU!UUU!UU!UU!UUU!UU!UU!UUU!UU!UU!UU!UU!UU!UU!UU!U!UU
U!!UU!UUU!UU!UU!UU!UUU!UU!UU!UU!U!UU!UU!UU!UU!UU!U!UUU!UU!UUU!UU!UUU!U
U!UU!UU!UU!UU!UUU!UUU!UU!UU!UUU!UU!UU!UUU!U!UU!UUU!U!U!UUU!UU!UU!UU!UU
!U!UU!UU!UU!UU!U!UU!
Success rate is 56 percent (561/1000), round-trip min/avg/max = 37/64/101 ms
SW2#
561 packet went through and 439 got blocked. You can see this also in the verification commands:
vEdge2# show policy access-list-policers
OOS OOS
NAME POLICER NAME PACKETS BYTES
---------------------------------------------------
ACL-SITE2-POLICER 1.POLICER-TEST **439** 50046
vEdge2#
vEdge2#
vEdge2# show interface detail ge0/3 | include policer
rx-policer-drops **439**
cpu-policer-drops 0
tx-icmp-policer-drops 0
rx-policer-remark 0
vEdge2#
vEdge2#
Also the U (Unreachable) indicates if an access list blocks the packet:
Interesting is that the first 100 packets are always without drops. it looks like that it takes some time to kick in.
Perhaps you can update the document if you like 
Kind Regards,
Olli
1 Like
Hello Olli
Thanks for sharing your findings, this is very helpful. Can you also share version numbers of the SD-WAN you’re using? I’ll let Rene know to take a look at your findings and make any necessary adjustments.
I hope this has been helpful!
Laz
Hi, i am using 20.3.4 (except for vBond, which is on 19.2.4).
Rgds,
Olli
1 Like
Hi!
Outstanding video, I’ve had a need to implement ACL’s to restrict access to my data center and also block inter-vlan routing between SD-WAN sites. Your video has gotten me closer but I’m missing a few things. Do you know if this would work when applying it to a data sub interface as egress?
My plan is to control egress traffic from the data sub interface at each site and basically allow traffic to the datacenter but then drop traffic to all other RFC_1918 private address. Essentially my sites only need to communicate to the data center besides their own LAN. It should look something like this, please let me know if you see any mistakes in my thought process on this any help is greatly appreciated:
policy
access-list Localized_ACL_Policy
sequence 1
match
destination-data-prefix-list Data_Center_Prefix
!
action accept
log
count Data_Center_Counter
!
!
sequence 11
match
destination-data-prefix-list VLANXXX_Prefix
!
action accept
log
count VLANXXX_Counter
!
!
sequence 21
match
destination-data-prefix-list RFC_1918_Prefix
!
action drop
log
count RFC_1918_Counter
!
!
default-action accept
lists
data-prefix-list Data_Center_Prefix
ip-prefix X.X.X.X/24
ip-prefix X.X.X.X/24
ip-prefix X.X.X.X/24
!
data-prefix-list RFC_1918_Prefix
ip-prefix 10.0.0.0/8
ip-prefix 172.16.0.0/12
ip-prefix 192.168.0.0/16
!
data-prefix-list VLANXXX_Prefix
ip-prefix X.X.X.X/24
!
Hello Evan
Glad you found the video and the content useful!
At first glance, your policy looks good overall. It’s a good start to implement ACLs to restrict access to your data center and block inter-vlan routing between SD-WAN sites. And yes, it would work if you apply the ACL to a sub interface as an egress filter. Make sure to apply it in the outbound direction on the sub interface that leads to your WAN/Internet connection.
Let us know how you get along, and if we can be of further help!
I hope this has been helpful!
Laz