Date: Fri, 28 Nov 2014 18:12:05 +0200 From: pepe <plaine@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: IPv6 aliases on FreeBSD 10 Message-ID: <CANNwXrb6zgcfBgG9rVbfaywmNJrXi=cuTai=WdyyD27z8PtDrg@mail.gmail.com> In-Reply-To: <CANNwXrZVqr3LadX21N5FEKJR1DGE7K47h1oDcp-4ykO7aXd_5Q@mail.gmail.com> References: <CANNwXrYNw3bdnXDLdEVDhfWBxn2wu1Joyd3WpobweHDjUzFfgQ@mail.gmail.com> <5447AD3F.8060304@bytecamp.net> <CANNwXra7nhsH4m52-SX2PqBwHLP1NoqtZmGx-MF4B8VE8HJFTQ@mail.gmail.com> <CANNwXrZ75XtVv84adpum-DU_kf=KjuJfnFpuhZucXJhqBT3K%2Bw@mail.gmail.com> <54490752.7080504@radel.com> <CANNwXrb89ryxdsw7emsP9b6AKQAcS%2B6z=Vr2ChNkX9CcZCMdDQ@mail.gmail.com> <544BEBB8.7000408@radel.com> <CANNwXrY-BAVfD2nLhYo8ZsXr9EkC1hr12ZQrCUmBxpzurVue_g@mail.gmail.com> <54725884.5060006@radel.com> <CANNwXraLjUB2XSVYbO2V7RD8jENqhLA6A57sMdd__H3Ejw5JdA@mail.gmail.com> <CANNwXrZVqr3LadX21N5FEKJR1DGE7K47h1oDcp-4ykO7aXd_5Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just to let you people know, it was problem on ISP side. They made config changes and now all ipv6 addresses are working just fine. On Wed, Nov 26, 2014 at 3:43 PM, pepe <plaine@gmail.com> wrote: > So, we finally got some answers from isp. They said it seems to be problem > on isps routers. > Now we just need to wait and see if they do something about it. > Thank's for suggestions and help anyways > > On Mon, Nov 24, 2014 at 7:51 AM, pepe <plaine@gmail.com> wrote: > >> Hello. >> >> Sorry about no information. I just realized that too. >> So, server is hosted at isp's server rack. Connected with two gigabit >> ethernets (em0 and em1, but currently we're using only em0 until we get >> everything working, then we're look into duplicating internet connection). >> Server setup is ESXi running two FreeBSD servers. IPv6 problem was very >> same on both machines, but currently for testing we're running it on one >> server only. em0 is connected to cisco switch that is connected to isps >> network with fiber. So, we really can't do any testing or changes with >> hardware because of the setup. >> >> We're not doing firewalling, or well of course we are, but when doing >> ipv6 setup and testing - no ipv6 firewall at all. And actually we tired >> IPv6 setup with firewall completely off too. >> >> I'm not planning to use those 1::1 addresses that are outside /64 of gw, >> but they're in config now for testing purpose. >> >> ndp -an output right now is: >> root@eemeli:/home/pepe # ndp -an >> Neighbor Linklayer Address Netif Expire S >> Flags >> 2001:14b8:1801::1 00:00:5e:00:02:0a em0 23h59m54s S >> R >> 2001:14b8:1801::c001 00:0c:29:b2:57:43 em0 permanent R >> fe81::ca01%em0 00:00:5e:00:02:0a em0 2h49m3s S >> >> >> >> On Sun, Nov 23, 2014 at 11:58 PM, Jon Radel <jon@radel.com> wrote: >> >>> On 11/23/14, 5:14 AM, pepe wrote: >>> >>>> I also tried adding >>>> aliases with /128 instead of /64, but it changed nothing. >>>> With /128 it worked just the same way. >>>> >>> As one of the people mentioning /128s, I'd like to retract that >>> suggestion; I've been reading the ipv6 related documentation given that I'm >>> bringing up my first 10.1 box with ipv6.....and things have changed a bit >>> since 8.4. >>> >>>> >>>> Current rc.conf is: >>>> ipv6_activate_all_interfaces="YES" >>>> #ipv6_defaultrouter="2001:14b8:1801::1" >>>> ipv6_defaultrouter="fe80::1%em0" >>>> ifconfig_em0_ipv6="inet6 2001:14b8:1801::c001 prefixlen 64" >>>> ifconfig_em0_alias59="inet6 2001:14b8:1801::2 prefixlen 64" >>>> ifconfig_em0_alias60="inet6 2001:14b8:1801::c002 prefixlen 64" >>>> ifconfig_em0_alias61="inet6 2001:14b8:1801::3 prefixlen 64" >>>> ifconfig_em0_alias62="inet6 2001:14b8:1801:1:: prefixlen 64" >>>> ifconfig_em0_alias63="inet6 2001:14b8:1801:1::1 prefixlen 64" >>>> >>>> Just making sure that you realize that if the ISP's equipment is >>> addressed 2001:14b8:1801::1/64, it wouldn't necessarily do good things with >>> your address 2001:14b8:1801:1::/64 unless it had a route to that network. >>> But that's an aside and doesn't appear to be the root issue you're dealing >>> with. >>> >>> >>>> I'm starting to think it's problem on ISP side and not ours. But just to >>>> sure - anyone have any ideas what more to try? >>>> >>>> >>>> I read through this thread, and as far as I can tell, you've told us >>> almost nothing useful about the topology of your network. Where does the >>> cable from em0 go? Directly into the ISP's equipment? If so, what kind of >>> equipment are we talking about? What type of media? I admit complete >>> ignorance of the industry norms specific to Finland, but around these parts >>> it makes a world of difference whether you're talking directly to a cable >>> carrier's "modem" or a point-to-point circuit into a high-end router. >>> >>> What I would do, given what little I know about your topology: >>> >>> 1) Run "ndp -an" on your machine. All the addresses you expect to >>> work should show up as permanent entries in this table. >>> >>> 2) You're not doing any firewalling are you? >>> >>> 3) If you don't run em0 into a switch, insert one (preferably one that >>> does L3 and port mirroring, if you just happen to have access to one like >>> that) between the server and your ISP. >>> >>> 4) Attach another ipv6 speaking machine to the switch. Can it ping >>> all the addresses? Does its ndp table show the proper mac address for all >>> the addresses? >>> >>> 5) Optional: mirror all the traffic on the switch port attached to the >>> ISP the test machine you added and using tcpdump or wireshark or >>> what-have-you look at the traffic between the ISP and your server. >>> >>> If the test machine in #4 reaches all the server addresses just fine >>> even though the ISP doesn't, particularly if #5 shows the ISP never sending >>> the traffic that should be going to the "non-functional" addresses, my >>> leading suspicion would be that that the ISP's equipment has very, very >>> limited capacity for a L2 address table, quite possibly as a matter of >>> deliberate configuration, and after it learns about N neighbors, where N is >>> a very small number, it simply ignores any additional addresses. Other >>> than getting your ISP to do something about that, the only fix I can think >>> of is to put a router (which is where a L3 switch would be handy) between >>> your ISP and your server. Then, in theory, your ISP's equipment should >>> have to deal with the only addresses on the outside of your router in L2 >>> and everything else would be L3 routing. My big concern about that, >>> however, is that the default address they've given you is actually in your >>> /48, so it's unclear to me what the heck they're doing with the routing. >>> So you probably have to talk to them in any case about what the outside >>> interface of your router should be addressed as. >>> >>> --Jon Radel >>> jon@radel.com >>> >>> >>> >>> >>> >>> >> >> >> -- >> pepe >> > > > > -- > pepe > -- pepe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANNwXrb6zgcfBgG9rVbfaywmNJrXi=cuTai=WdyyD27z8PtDrg>