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

    2.0RC3 upgrade from 1.2.3 - 3 of 4 WANs fail with "can't allocate llinfo" msgs

    2.0-RC Snapshot Feedback and Problems - RETIRED
    6
    9
    3.1k
    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.
    • A
      aMakUzr
      last edited by

      Upgraded a working 1.2.3 i386 configuration to 2.0RC3.  The upgrade process went smoothly and seemed correct, but only the WAN worked – the 3 Opt WANs failed with constant "kernel: arpresolve: can't allocate llinfo for x.x.x.x" messages being logged.  I had to revert to 1.2.3 to get a working router, again.

      On this setup, the static IPs are allocated via the ISP's DSL box via DHCP based upon configured MAC addresses and that was working fine.  All the static IPs allocated are on the same /23 subnet and the routing tables all looked OK (i.e., as they do with 1.2.3).

      I can supply additional config information if requested and provided a non-public sharing mechanism.

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

        You have 3 (or 4?) pfSense interfaces with IP addresses in the same /23 subnet? That sounds like an invalid configuration. Maybe there is something significant about your configuration that you haven't told us about yet.

        Do you have a copy of your 1.2.3 configuration file. That may be of interest to the developers concerned with the software performing upgrades.

        Exactly what "RC3" file did you attempt to upgrade to?

        1 Reply Last reply Reply Quote 0
        • A
          aMakUzr
          last edited by

          Yes, I can supply the 1.2.3 config file – please send me and email address so I can make it available.

          The 2.0RC3 file used is pfSense-Full-Update-2.0-RC3-i386-20110621-1542.tgz

          Actually, I likely didn't state things correctly.  To (try to) be more clear, the static IPs are:
          WAN - 207.6.221.63
          OPT1 - 207.6.221.161
          OPT2 - 207.6.221.44
          OPT3 - 207.6.221.43
          OPT4 - 207.6.220.40

          and the Routing Tables page (in 1.2.3) shows, in part:
          Destination Gateway Flags Refs Use Mtu Netif
          207.6.220.0/23 link#1 UC 0 0 1500 hme0
          207.6.220.40 127.0.0.1 UGHS 0 0 16384 lo0
          207.6.220.254 00:90:1a:a0:3b:32 UHLW 2 600 1500 hme0
          207.6.221.43 127.0.0.1 UGHS 0 0 16384 lo0
          207.6.221.44 127.0.0.1 UGHS 0 0 16384 lo0
          207.6.221.63 127.0.0.1 UGHS 0 0 16384 lo0
          207.6.221.161 127.0.0.1 UGHS 0 0 16384 lo0

          1 Reply Last reply Reply Quote 0
          • 7
            73agordon
            last edited by

            good luck getting a reply about the "can't allocate llinfo" message. I have had a post up for 2 weeks about this problem and another person posted about the same issue. They must not want to deal with this issue as they are ignoring us. cheers.

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

              i worked around these messages by disabling sticky connections

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

                "can't allocate llinfo" has been harmless every time I've seen it. This particular configuration won't work correctly on any version, you can only have one WAN on any given IP subnet. It may work in different incorrect ways with 1.2.3 vs. 2.0 due to differing behavior of having the same IP subnet on multiple NICs on the different underlying FreeBSD versions.

                1 Reply Last reply Reply Quote 0
                • A
                  aMakUzr
                  last edited by

                  Re: …This particular configuration won't work correctly on any version, you can only have one WAN on any given IP subnet. It may work in different incorrect ways with 1.2.3 vs. 2.0...

                  I don't understand.  This configuration has functioned perfectly for multiple years with 1.x versions.

                  Our ISP only assigns static IPs (vis DHCP & configured MAC addresses) from a single subnet (in this case, it appears from 207.6.220.0/23).

                  Given that limitation, is there a "supported" strategy that would enable pfSense 2.x to work with multiple WANs (if describing, assume I know only enough to be plenty dangerous, but I do have the pfSense book)?

                  1 Reply Last reply Reply Quote 0
                  • G
                    grazman
                    last edited by

                    @aMakUzr:

                    Yes, I can supply the 1.2.3 config file – please send me and email address so I can make it available.

                    The 2.0RC3 file used is pfSense-Full-Update-2.0-RC3-i386-20110621-1542.tgz

                    Actually, I likely didn't state things correctly.  To (try to) be more clear, the static IPs are:
                    WAN - 207.6.221.63
                    OPT1 - 207.6.221.161
                    OPT2 - 207.6.221.44
                    OPT3 - 207.6.221.43
                    OPT4 - 207.6.220.40

                    and the Routing Tables page (in 1.2.3) shows, in part:
                    Destination Gateway Flags Refs Use Mtu Netif
                    207.6.220.0/23 link#1 UC 0 0 1500 hme0
                    207.6.220.40 127.0.0.1 UGHS 0 0 16384 lo0
                    207.6.220.254 00:90:1a:a0:3b:32 UHLW 2 600 1500 hme0
                    207.6.221.43 127.0.0.1 UGHS 0 0 16384 lo0
                    207.6.221.44 127.0.0.1 UGHS 0 0 16384 lo0
                    207.6.221.63 127.0.0.1 UGHS 0 0 16384 lo0
                    207.6.221.161 127.0.0.1 UGHS 0 0 16384 lo0

                    You will lose a lot of functionality to detect dead gateways, since you only have one "real' gateway with your ISP.I am not going to debate your putting the IP's on different interfaces versus adding them as virtual ip's. You probably have your reason for doing this.

                    I have never been able to use multiple interfaces "properly" if the upstream gateway from the provider was the same. It breaks outbound routing rules, etc. I would intead ask them to provision several ip's from different subnets and add them to the interface of their equipment or find a provider that can. For example, we had 2 DSl modems brought in, both had's a static ip on the same subnet/gateway. It could not properly outbound load balance. If the gateway went down, both devices ceased to pass traffic (obviously). Trying to use a different Ip to monitor as the gateway didn't work because outbound routing uses the same gateway and you couldn't get to any if the provider gateway went down. A week after having it re-provsioned with two different ip/subnets, one gateway at the ISP went down, the other did not, and noone noticed except the IT staff.

                    This will probably not matter if you are hosting things and your traffic is inbound.

                    The llinfo is a entropy message. Probably due to dhcp related issues between the isp's dhcp server or relay and your system.

                    The typical reasons for this message is that there are machines not on the same IP network connected to the same LAN. "entropy" is getting an ARP packet from a machine with an IP that does not fall inside the network. An example would be if this machine used a, say .0/28 network, and another machine with an IP of .35 (with a, say, /24 mask) tries to connect to it.

                    I can't tell if this is your problem from your description, but you should perhaps check so that noone accidentally added new machine(s) to the LAN, or even has managed to connect two LANs on "the same wire".  Often, this message is the result of a physical network misconfiguration.

                    Clear your arp and state table, and if it continues ask your ISP to do the same on their equipment. It's quite possible you have set opt1 on the old config to use one ip, but reconfigured it and so the mac address changed for what the ISP's equipment had been using.

                    1 Reply Last reply Reply Quote 0
                    • A
                      aMakUzr
                      last edited by

                      grazman: Thanks for taking the time to respond.

                      Re: I am not going to debate your putting the IP's on different interfaces versus adding them as virtual ip's. You probably have your reason for doing this.
                      –-
                      Well, yes ... unfortunately that reason would politely be called "lack of understanding."  <;-}  I never thought of it as being a problem and, since it always worked, was happy in my ignorance.

                      I'll read up on VIPs and see what I can figure out.

                      If you'd like to make a suggestion, I'd also likely benefit from that.  'Though I do have a second test setup, the only way I can really test a config (i.e., using the direct-to-ISP equipment) is via a live router which, if it doesn't work, causes downtime.

                      The setup (I thought) was relatively simple:

                      • we have multiple static IPs (allocated on the same subnet)

                      • there's one static IP per domain name

                      • automatic outbound NAT is set

                      • all domains are (NAT) port-forwarded (http, https, smtp) to a specific IP where that IP is actually an IP alias with all aliases on one physical server

                      • currently, the LAN is routed by each server (alias) IP to the applicable WAN/Opt interface (even 'though they all end up via the same ISP route)

                      Other than some other specific blocking by IPs, that's really all there is to it, currently.

                      I suspect your analysis of the  "can't allocate llinfo" msgs cause is correct and is at the ISP's end.  Unfortunately, our ISP (Telus) is terrible so I generally get no help from them.  Fortunately we will have an alternative available prior to the end of the year and we'll switch (we use them at another office and they're good).  Hopefully either a different configuration will eliminate the messages or they'll be innocuous.

                      Regardless, thanks for you help on this.

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post