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.

  • Look at it this way, routing is only a layer-3 function (the destination network address is all that is used to route a packet normally), but some routers can have other processes providing other functions and features that may look at different layers. As other features/functions are added to a router, software, and possibly hardware, must be added to the router, and this increases the vendors' costs. A simple router could be relatively inexpensive, but adding software and hardware for other features can make it expensive.
    – Ron Maupin
    Nov 2, 2019 at 20:02

4 Answers 4


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.

  • So that means a router will be able to process the L4 header to know the exact port details (source and destination) so that it can match it to the ACL configured on the interface? Oct 1, 2019 at 11:58
  • Yes. Also consider a function like NAT: the router needs to understand ports in order to perform NAT or PAT.
    – Ron Trunk
    Oct 1, 2019 at 12:30

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 (0 to 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 (0 to 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.