Hi, >> Hi, >> >> I'm trying to police ingress traffic based on port numbers and IP >> addresses. The u32 match based on IP addresses seems to work without >> issues and I'm am able to police incoming packets. However, the same >> isn't working with u32 matches based on TCP port numbers. For port >> numbers, I added exactly one 'u32 match' rule: >> >> common for both: >> # tc qdisc add dev eth0 handle ffff: ingress >> >> And then: >> >> # tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip >> src \ >> 0.0.0.0/0 police rate 128kbit burst 10k drop flowid :1 >> >> The rule above works, but the same with a port match does not: >> >> # tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match >> tcp dport 0xXYZ 0xFFFF police rate 128kbit burst 10k drop flowid :1 >> >> Is there anything I am missing? >I've never managed to find a way to use the word tcp in a filter without >getting an illegal match - I know it's in the help. The reason it does not work is that the keywords that refer to the L4 protocols (such as tcp) are supposed to be used when: 1) the u32 filter is inserted into a u32 hash table AND 2) you jump to the above hash table from a u32 filter configured with the "offset" option. (unfortunately the U32 classifier is not well documented) >If you want to match tcp use the ip protocol match > >tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match >ip dport 0xXYZ 0xFFFF match ip protocol 0x06 0xff police ..... You should invert the order of the two "match" conditions: first you make sure it is TCP, and then you test the destination port number. This filter works in most cases, but not always: it does not take into account the IP options. IP packets with options in the IP header will not match. The reason is that "ip dport" is equivalent to "offset 22" from the beginning of the IP header. Regards /Christian [http://benve.info] _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
