How routers understand the layer 4 port numbers to be blocked in ACL? When an ACL to block TCP/UDP traffic with certain port numbers is applied on a router/L3 interface , how will router understand the port numbers as it works at layer 3.The IP header contains protocol field which point to TCP/UDP traffic but there is no way a port number can be referenced.
Cisco routers (and others) can filter packets based on tcp and udp ports.
When we say routers are only layer 3 devices, we are talking about idealized routing functions. In practice, manufacturers add lots of other features to their devices, like firewalls that blur the line between the layers.
In general all routers have header inspection capabilities, this is just parsing the TCP or UDP headers so after this parsing or decoding phase they can search on the ACLs in order to accept the flows or reject.
In the IPv4 header, there is the Protocol field (IPv6 has the Next Header field that does the same thing). That field has the protocol number (
255) to which the IP payload should be sent on the destination host. IP itself really doesn't know or care about what is in the payload, only where to deliver it, and the field facilitates that. It is an easy matter for a router ACL to grossly block any particular protocol based on that field.
Beyond that, the ACL process in a router can know about some protocols (enough about some of them to decode the protocol header). Since TCP and UDP are the most common transport protocols, they will certainly be included in that knowledge if the router has that ability, and ICMP is an integral part of IP so it will also be included. The router manufacturer may also include the knowledge to decode the headers of other protocols. For example, this is a list from a Cisco ISR for the protocols of which an IPv4 ACL process has knowledge:
Router1(config-ext-nacl)#deny ? <0-255> An IP protocol number ahp Authentication Header Protocol eigrp Cisco's EIGRP routing protocol esp Encapsulation Security Payload gre Cisco's GRE tunneling icmp Internet Control Message Protocol igmp Internet Gateway Message Protocol ip Any Internet Protocol ipinip IP in IP tunneling nos KA9Q NOS compatible IP over IP tunneling object-group Service object group ospf OSPF routing protocol pcp Payload Compression Protocol pim Protocol Independent Multicast sctp Stream Control Transmission Protocol tcp Transmission Control Protocol udp User Datagram Protocol
Notice that you can completely block any transport protocol (
255), and the ACL process has some specific knowledge of a few protocols. (There are also other options for IPv4 itself and you can filter on object groups that you may have created.)
Other router vendors may have more or less ability to filter transport protocols. Also, because the ACL process is a separate process that must dig deeper into a packet, it can cause a performance impact on routing because every packet needs to be checked against an ACL that could be rather large.
Attributes like IP protocol type, port numbers, IP src/dst address, DSCP, etc are all just values at predetermined offsets into a packet. The only real significance of the OSI layers for a given network device is where information is parsed to determine how to forward. A router (L3) device might normally only parse the destination IP of a packet but all of the information associated with L4 (or, indeed, L4-7) is generally handled as payload.
That said, an ACL is basically just looking for values at a particular offset. By convention we know that 12 octets in from the start of the L3 packet we'll find a source IP and that the next four will be a destination IP. Shortly before that (at 9 octets from the start of the L3 frame) we'll find the IP protocol number. If that value corresponds to the value for TCP then we can jump forward a fixed number of bytes and find source and destination ports - or, really, just about anything. By convention the header values and types of higher level protocols are often optimized for easy parsing by network devices but there's nothing inherently that says even an L1 or L2 device couldn't look for information that's very much at the application layer.
Now, the real question is whether / how a given device can understand things like protocol state. This is the difference between knowing that, for example, a packet is TCP and on port 443 vs knowing that said packet is part of an existing session or, for that matter, which existing session and whether there's other variable data to be had to make intelligent decisions.
Put another way it's the difference between a rule that analyzes each packet independently (i.e. is the source IP X?) versus a rule that controls how future packets are handled based on observation and handling of prior packets (TCP session was established correctly and traffic is validated as being a member of said session). This is why firewalls and load balancers can act as routers but routers generally can't do the same things as firewalls and load balancers... and also why routers (or L3 switches) tend to handle orders of magnitude more traffic than firewalls and load balancers.