Announcing /48 to BGP peer
-
@stepheng said in IPv6 broken beyond pfSense after 2.5 upgrade:
在
i running pf2.5 newest version and frr bgp for ipv6, I have also experienced ipv6 loss connection capability here. I can see that there is ipv6 routing, but I can’t go online
-
@yon-0 Perhaps need a little more detail to see if it is a similar problem? Are your LAN devices getting global IPv6 addresses? That was essentially my problem which was resolved by getting the IPV6 DHCP server and the associated leases server to start / restart. As I said, I'm not really an expert.
-
@stepheng said in IPv6 broken beyond pfSense after 2.5 upgrade:
Are your LAN devices getting global IPv6 addresses
yes, i have myself ipv6 /48 address setup in LAN interface, ipv6 route seem is normal, but i don't know why i can't visit ipv6 network sites.
-
@stepheng said in IPv6 broken beyond pfSense after 2.5 upgrade:
Hi, I've been using pfSense for several months on 2.4.5p1 and had IPv6 enabled successfully distributed IPv6 addresses to my computers and devices. My ISP in the UK is Zen and I have a /48.
Since upgrading to 2.5, I still have a IPV6 address on my pfSense WAN interface (and on the LAN interface), but none of my computers or devices seem to be getting an IPV6 address. I assume that something has happened to the DHCPv6 / RA configuration / process in the upgrade but I would appreciate some suggestions / pointers as to what to look for. I'm happy to provide more information but am not clear what would be helpful at this stage. IPV4 seems to be working fine, and everything else seems OK as well.
Unlike others I see to have the IPV6 gateway working and IPv6 working OK on pfSense itself - just not getting passed onto other systems on the LAN.
pf2.5 seem is change not allow use /48 in LAN interface, pfsense 2.4.5 can setup /48 in LAN interfacfe is work. pf 2.5 should not allow use /48 in WAN.
-
@yon-0 As has been mentioned in the redmine, putting a /48 on an interface is not something anyone should do.
-
@derelict said in IPv6 broken beyond pfSense after 2.5 upgrade:
putting a /48 on an interface is not something anyone should do.
Yeah that is just not something that would ever be done - ever!! A /48 is a route prefix, or maybe a firewall rule - not something that would be on a interface..
It sure and the hell would not be a mask on a dhcpd - your talking 65k /64s - which would be a normal prefix on an interface.. Or a single L2 network.. A /48 your talking what like
1,208,925,819,614,629,174,706,176
Addresses ;) What is that 1.2 Septillion.. dude - really!!
-
/48 is the smallest range among BGP and bgp anycast. Less than /48 will be filtered out by the internet. No matter how much you use, you must set IP prefixes greater than or equal to /48 on at least one interface. Otherwise BGP will not broadcast ip prefixes smaller than /48.
I set at least 5 /48 IP prefixes. only config /48 or above perfixes in frr bgp, it is will can't work. it is must use /48 or greater setup in interfacePF is a routing system, not a client. It must follow professional practices and allow any possibility. It can even allow /29 or greater, because this is running a BGP router, and it can be distributed to other customers. No matter what, it is not Toys, can be ISP routers.
Because RIPE allocates at least one /29 to the customer.As far as I know, AS4134 uses your system.
-
@yon-0 said in IPv6 broken beyond pfSense after 2.5 upgrade:
/48 is the smallest range among BGP and bgp anycast
And what does that have to with assigning a /48 to an IP on an interface -- let me think.. Yeah NOTHING!!
-
@yon-0 Announcing a /48 via BGP and placing a /48 on an interface are two completely different things.
In your BGP configuration:
network 2001:db8:abba::/48
On interfaces:
2001:db8:abba:1:::/64
2001:db8:abba:2::/64
2001:db8:abba:3::/64
2001:db8:abba:4::/64 -
@derelict said in IPv6 broken beyond pfSense after 2.5 upgrade:
@yon-0 Announcing a /48 via BGP and placing a /48 on an interface are two completely different things.
In your BGP configuration:
network 2001:db8:abba::/48
On interfaces:
2001:db8:abba:1:::/64
2001:db8:abba:2::/64
2001:db8:abba:3::/64
2001:db8:abba:4::/64only network 2001:db8:abba::/48 setup , BGP will not broadcast /48 out. In addition, there is no technical requirement that it must not be used /48 or greater in interface.
-
This is similar to how I have many big houses, but you said that one person can live in a small house, and the big house must be divided into the smallest house.
Then I have a lot of houses that are in greater demand. And I like to live in big houses. It doesn't say that people cannot live in big houses.
There is no problem if the interface is set to /48 or greater in linux, is it that the freebsd restriction does not allow the use of /48?
I Can't understand this, everyone has their own resources and preferences. There are different needs, if it is not a technical problem, it should not be restricted to the smallest /64. Otherwise, BGP will not stipulate that the minimum is /48
-
@yon-0 said in IPv6 broken beyond pfSense after 2.5 upgrade:
@derelict said in IPv6 broken beyond pfSense after 2.5 upgrade:
@yon-0 Announcing a /48 via BGP and placing a /48 on an interface are two completely different things.
In your BGP configuration:
network 2001:db8:abba::/48
On interfaces:
2001:db8:abba:1:::/64
2001:db8:abba:2::/64
2001:db8:abba:3::/64
2001:db8:abba:4::/64only network 2001:db8:abba::/48 setup , BGP will not broadcast /48 out.
Yes, it will if it is configured correctly.
In addition, there is no technical requirement that it must not be used /48 or greater in interface.
Yes, actually, there is. See Also RFC7421.
The de facto length of almost all IPv6 interface identifiers is therefore **64 bits.** **The only documented exception** is in [RFC6164], which standardizes 127-bit prefixes for point-to-point links between routers, among other things, to avoid a loop condition known as the ping-pong problem. -
I tested it, there must be an interface setting /48 to bgp broadcast. if LAN or other interface has no /48 or greater, pfsense 's frr can't normal broadcast. to upstream.
-
@yon-0 I can guarantee you that nobody who is successfully announcing an IPv6 /48 has that /48 on an interface.
-
In addition, for larger IP segments, the shortest IP address can be used.
For example 2400:3200::1 2400:da00::6666 -
Anyone else?
-
@derelict said in IPv6 broken beyond pfSense after 2.5 upgrade:
@yon-0 I can guarantee you that nobody who is successfully announcing an IPv6 /48 has that /48 on an interface.
i using /48 setup interface in ubuntu 20.10 system and runing frr 7.5
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 inet 185.154.1.130 netmask 255.255.254.0 broadcast 185.154.1.255 inet6 2a0d:2405:512::1 prefixlen 48 scopeid 0x0<global> inet6 fe80::278:34ff:fee6:2f3f prefixlen 64 scopeid 0x20<link> ether 00:70:30:e6:2f:3f txqueuelen 200000 (Ethernet) RX packets 35921977 bytes 19914818009 (19.9 GB) RX errors 0 dropped 8 overruns 0 frame 0 TX packets 24672157 bytes 19845868488 (19.8 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 -
@derelict said in IPv6 broken beyond pfSense after 2.5 upgrade:
Anyone else?
240C::6666 240C::6644
DIG Output:
dig @240C::6666 yahoo.com SOA; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 <<>> @240C::6666 yahoo.com SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58824
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;yahoo.com. IN SOA;; ANSWER SECTION:
yahoo.com. 1800 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2021022619 3600 300 1814400 600;; Query time: 18 msec
;; SERVER: 240c::6666#53(240c::6666)
;; WHEN: Sat Feb 27 00:52:23 CET 2021
;; MSG SIZE rcvd: 99---- Finished ------
https://bgp.he.net/ip/240C::6666
it is using /28 ipv6 for interface and bgp
-
DIG Output:
dig @2001:da8::666 yahoo.com SOA; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 <<>> @2001:da8::666 yahoo.com SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41270
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;yahoo.com. IN SOA;; ANSWER SECTION:
yahoo.com. 1800 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2021022619 3600 300 1814400 600;; Query time: 418 msec
;; SERVER: 2001:da8::666#53(2001:da8::666)
;; WHEN: Sat Feb 27 01:00:26 CET 2021
;; MSG SIZE rcvd: 102---- Finished ------
-
@yon-0 Yet here you are with problems.
Instead of arguing with me about it, please argue with Douglas Comer instead.
-
@yon-0 You are confusing routes and allocations with interface addressing. Please read up on the difference. Happy to help you but in this case you are wrong (and continue to belabor an incorrect position) and your IPv6 journey will be much more successful if you adhere to the established rules, standards, and protocols instead of making up your own.
-
I tested it with a previous version of pfsense before, and /48 works. DHCP can work with /48 test in windows 10. /48 SLAAC maybe can't work for andriod system. This is the result of the previous test. But if you set static ip, there is no problem. for all system.
I have always used /48 on the LAN interface and BGP broadcasts, and it has been working. This time you adjusted the limit, so I found this change. I suggest that the decision is given to users to decide how large the IP segment to use.
You can prompt the recommended value and other information, but don't force the user to use what -
I used to set /48 on the LAN interface to work, but it pf2.5 doesn’t work anymore now. This is the actual change
-
@yon-0 said in IPv6 broken beyond pfSense after 2.5 upgrade:
it is using /28 ipv6 for interface and bgp
Just because AS45275 is a /28, where did you get that idea that address is 240C::6666 is using a /28 on some interface?? Sorry but that is just insane!
I used to set /48 on the LAN interface to work, but it pf2.5 doesn’t work anymore now. This is the actual change
Yeah because they prob put in logic to stop users from doing insane shit ;)
I suggest that the decision is given to users to decide how large the IP segment to use.
Not when they are going to BREAK all logic and think they could put a /48 on an interface..
-
These IP addresses run DNS servers, so the 240C::6666 IP must be set in the interface. if that ip has no setup in interface, how we can connect it? if your not allow /48 or other setup interface , how i do setup use /32 or /48 Shortest ip in LAN's servers?
No, I don’t think so, I think you force others what you think is impossible.
DIG Output: dig @2620:0:ccc::2 yahoo.com SOA ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 <<>> @2620:0:ccc::2 yahoo.com SOA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38691 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;yahoo.com. IN SOA ;; ANSWER SECTION: yahoo.com. 127 IN SOA ns1.yahoo.com. hostmaster.yahoo-inc.com. 2021022619 3600 300 1814400 600 ;; Query time: 7 msec ;; SERVER: 2620:0:ccc::2#53(2620:0:ccc::2) ;; WHEN: Sat Feb 27 01:24:57 CET 2021 ;; MSG SIZE rcvd: 99 ---- Finished ------ -
@yon-0 said in IPv6 broken beyond pfSense after 2.5 upgrade:
2620:0:ccc::2
That is 2620:0:ccc:0::2/64. Guaranteed. You do realize that zero compression can include bits from both the subnet and interface portion of the address, right?
-
Does this 240C::6666 ip use /64 or what?
My point of view is to leave it to users to decide what is right, and we can provide suggested values. -
@yon-0 The standards and RFCs dictate what's right.
-
@yon-0 said in IPv6 broken beyond pfSense after 2.5 upgrade:
Does this 240C::6666 ip use /64 or what?
Yes, if it is on an interface it is 240c:0:0:0::6666/64
You certainly cannot tell from afar based on the allocation or the route. I GUARANTEE they do not have a 240c::/16 on an interface though.
-
@yon-0 You are just flat out wrong. The largest subnet to be used on an interface is /64. To suggest anything else just means you do not understand or have not read the RFCs for IPv6.
-
https://www.ripe.net/publications/docs/ripe-690
-
Yeah so.. What does that have to do with anything?
The part where they say you should allocate a /48 to users? Completely agree - that has ZERO to do with putting a /48 on an interface.
I have a /48 from HE for example.. Putting a /48 on interface would make all 65k of those 64's useless!
-
FRR v7.5.1 change to must setup /48 or above in Lan interface now, if the pfsense has no any interface setup /48 prefix, then ipv6
lost normal work. i have been test frr7.5.1 in ubuntu 20..10 system get the same result. -
@yon-0 said in IPv6 broken beyond pfSense after 2.5 upgrade:
FRR v7.5.1 change to must setup /48 or above in Lan interface now
Dude NO is doesn't... I am sorry you are not understanding how this works... But you DO NOT PUT a /48 on an interface - PERIOD!!
-
Maybe I don't understand the theory, I just summarize the practical experience, if I run FRR7.5.1 then this happens. I just reflect the situation encountered.
-
Your not understanding how to setup a route without putting in on the interface??
This goes same for IPv4... If have a /30 that connects 2 routers, are you saying I can not route a /8 through those? Or a /16 etc.. Because the network needs to be on the interface? How would routing ever work..
-
@yon-0 The whole point of BGP is to announce routes that are reachable. If the route is not reachable, it will not be announced.
That does not mean that the only method of making a route reachable is to number an interface with it.
This is what you get when you simply add a network statement for a /48 without the route being reachable:
# show bgp ipv6 BGP table version is 5, local router ID is 172.25.232.1, vrf id 0 Default local pref 100, local AS 65001 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> ::/0 fe80::bc7f:82ff:feea:ecf8 0 32768 ? 2001:470:beef::/48 :: 0 32768 i Displayed 2 routes and 2 total pathsNote there is no
*indicating a valid route. That means it will not be announced by BGP.Now,
Now it is both active
*and best>and announced to the peerCodes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup K>* ::/0 [0/0] via fe80::bc7f:82ff:feea:ecf8, lo0, 00:01:15 S>* 2001:470:beef::/48 [1/0] unreachable (blackhole), weight 1, 00:01:15vtysh# show bgp ipv6 neighbors 172.25.228.58 advertised-routes BGP table version is 3, local router ID is 172.25.232.1, vrf id 0 Default local pref 100, local AS 65001 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> ::/0 :: 0 32768 ? *> 2001:470:beef::/48 :: 0 32768 ?I sent that traffic to Null/Blackhole but if there are any longer prefixes (like /64 interface routes) they will be the preferred route for that traffic. It also has a status of unreachable because it is a null route but BGP is coerced into announcing it.
-
I had used /48 in pf 2.4.5 and pf 2.5beta was
normal work. -
@yon-0 You share one bit in common with a /48, quite dense.
-
@yon-0 said in IPv6 broken beyond pfSense after 2.5 upgrade:
I had used /48 in pf 2.4.5 and pf 2.5beta was
normal work.It is going to be very difficult to get developer time to "fix" something in what amounts to a nonsensical configuration.
