Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Max Mac Count

    General pfSense Questions
    7
    20
    6.9k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      wallabybob
      last edited by

      @blackbrayn:

      bump.

      What do you mean? You still have an unanswered issue?

      As has been already stated, you can't get 8K devices on a distinct VLAN per device on a single NIC. The limitation is the 12 bit VLAN id field in the frame.

      1 Reply Last reply Reply Quote 0
      • B
        blackbrayn
        last edited by

        8k is the Total mac count , meaning this 8k is split among the diferent vlans. Switches and routers have a TOTAL mac adress limit .

        1 Reply Last reply Reply Quote 0
        • B
          blackbrayn
          last edited by

          check this out , this is the real problem like stated here : http://www.vyatta.org/forum/viewtopic.php?p=53428

          1 Reply Last reply Reply Quote 0
          • W
            wallabybob
            last edited by

            I can't find any evidence of a limit on the FreeBSD arp table size, but that may just be an indication I don't know where to look.

            1 Reply Last reply Reply Quote 0
            • M
              Metu69salemi
              last edited by

              If I recall correctly, pfsense is limited only the amount of ram you have installed. and continuying the same remembering line, one mac entry is one kB of ram, so 8MB would handle 8k mac-addresses.

              But this was only that if I remember correctly.

              Comparison between Switch and pfSense is not reasonable anyway. Those are different kind of beasts for it's own purpose.

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                FreeBSD uses the routing table for ARP entry storage, as such it's limited by the routing table size. The routing table doesn't have a fixed limit. You'll eventually run out of kernel memory, but we're talking very large numbers, into the millions. There are many production systems that have 400,000+ routes (full BGP feed), which is basically equivalent to having a small number of routes and 400,000+ ARP cache entries. So I don't think you'll have any issues unless you have millions of directly-connected devices, which would probably be a really poor network design and probably generate enough traffic it would melt down any firewall you can get.

                1 Reply Last reply Reply Quote 0
                • B
                  blackbrayn
                  last edited by

                  so you're saying i don't need to modify the "net.ipv4.neigh.default.gc_thresh3=8192" to a value of my needs? 8192 is arbitrary , i chosed this large number.

                  1 Reply Last reply Reply Quote 0
                  • D
                    dhatz
                    last edited by

                    @blackbrayn:

                    so you're saying i don't need to modify the "net.ipv4.neigh.default.gc_thresh3=8192" to a value of my needs? 8192 is arbitrary , i chosed this large number.

                    There is no such tunable on pfSense.

                    pfSense is based on FreeBSD, not Linux (like Vyatta you mentioned, and most other router/firewall distros), so the base system is very different "under the hood".

                    1 Reply Last reply Reply Quote 0
                    • B
                      blackbrayn
                      last edited by

                      So the question remains , is there a limit on the arp entries after all? till now nobody can say for sure , a definitive answer would be good , since i plan to deploy a install and the sucess is based on pfsense suporting such a high number or arp entries.

                      1 Reply Last reply Reply Quote 1
                      • W
                        wallabybob
                        last edited by

                        @blackbrayn:

                        Switches and routers have a TOTAL mac adress limit .

                        Many of them have much less memory than the pfSense minimum.

                        @blackbrayn:

                        So the question remains , is there a limit on the arp entries after all? till now nobody can say for sure , a definitive answer would be good

                        I doubt you will get a more definitive answer than
                        @cmb:

                        FreeBSD uses the routing table for ARP entry storage, as such it's limited by the routing table size. The routing table doesn't have a fixed limit. You'll eventually run out of kernel memory, but we're talking very large numbers, into the millions. There are many production systems that have 400,000+ routes (full BGP feed), which is basically equivalent to having a small number of routes and 400,000+ ARP cache entries. So I don't think you'll have any issues unless you have millions of directly-connected devices, which would probably be a really poor network design and probably generate enough traffic it would melt down any firewall you can get.

                        FreeBSD has a number of memory "pools" that are used to allocate memory for different purposes. The sizes of these pools depends on the memory in the system. Hence the routing table might be able to grow to a significantly larger size on a system with 2GB RAM than it can on a system with 256MB RAM.

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          Here's a second opinion from a few years ago:
                          http://freebsd.1045724.n5.nabble.com/Maximum-ARP-Entries-td4017394.html

                          Steve

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.