- Jan 11, 2016
See hidden discussions | Win great prizes | Get free support
Our backbone team confirms they are working on scaling the faster path we have to Frankfurt from South Africa, but we remain reliant on the slower path until that scaling is complete. The expected delivery date for that new capacity and switch over is end of May. Unfortunately until then our customers will remain traversing the slower path. Do you want to revert your changes and haul the traffic to our EU peerings until that work is complete? It should remediate the issue until we can fix it long term, and we certainly don’t want gaming customers impacted while we wait on this work to complete. Let us know if you’d like to do that or simply wait the few weeks for this to be delivered and fixed long term. Thanks.I have requested an update from them.
Thank you very much for the feedback!Our backbone team confirms they are working on scaling the faster path we have to Frankfurt from South Africa, but we remain reliant on the slower path until that scaling is complete. The expected delivery date for that new capacity and switch over is end of May. Unfortunately until then our customers will remain traversing the slower path. Do you want to revert your changes and haul the traffic to our EU peerings until that work is complete? It should remediate the issue until we can fix it long term, and we certainly don’t want gaming customers impacted while we wait on this work to complete. Let us know if you’d like to do that or simply wait the few weeks for this to be delivered and fixed long term. Thanks.
So we will probably look to revert until then.
Upgrade is done, I just tested and my line is running at 200/200Mbps.Hi guys,
I created a line speed upgrade request to 200/200Mbps and was hoping that you may be able to have it processed as soon as possible. I saw now that the website indicates upgrades/downgrades can only be processed before the 20th of the month (my bad for only seeing this now, doh!).
#COOL-20210522-687651 - Upgrade Request for service:66429
Good write up and my two cents. IPSEC is a dog.Realistically, for the average user, there should be no change, or difference of any kind. It's not "magically" better than IPv4, which can be discussed by reviewing the alleged benefits.
1. More efficient routing.
A moot point. Not something that benefits a consumer. The IPv4 internet works just fine with the current routing tables. The IPv4 global routing table will remain for decades, so adding global V6 on top of it, will in fact increase the size of the global routing table. The statement assumes that only V6 will be in the global routing table.
People will also want to engineer networks in a huge V6 address space to be more efficient in terms of latency/localisation, e.g. split prefixes to localise between CPT and JHB. This will eventually end up being at LEAST the size of the V4 routing table, BOTH of which routers will have to carry for a very long time....
2. More Efficient Packet Processing
A moot point. Modern routers do this in hardware in any case. Not something that benefits a consumer.
3. Directed Data Flows
V4 also had multicast, the applications for which has not really benefited any consumer directly. Most IPTV/Streaming is unicast. Multicast is not "new" in IPv6, and the number of multicast consumer applications are minimal.
4. Simplified Network Configuration
This is a solved problem in V4 too, DHCP, PPPoE address assignment and other "legacy" technologies already take care of this. It's a solved problem. In fact, DHCPv6 is not too dissimilar from DHCPv4. Ask for an IPv4, get an IPv4. Ask for an IPv6, get an IPv6. Ask for a SLAAC based address, get a SLAAC based address.
5. Support For New Services
Stateful firewalling is still required in order to protect consumer devices, which still requires applications to be able to "hole punch" through a firewall from "inside" a network, rather than just blindly allowing incoming connections from the internet... Again, not super beneficial to a consumer.
The elimination of NAT does not mean that firewalls are eliminated, nor is the need for a device to establish an "outbound" connection before being able to traverse an inbound firewall rule eliminated.
It's just not NAT'ed that's all.
Sure, if you're willing to leave these devices without any firewalling which requires an "established-related" outbound connection, which in effect means leaving them naked on the internet.... Seems like a great idea. Outbound "firewall hole punching" isn't going to go away, unless consumers are willing to have their devices "naked" on the internet.
IPSec works just fine over IPV4 too.
ICMPv4 is not a malware carrier or security risk, except for very old or poorly implemented IP stacks.
"May be permitted". I predict most corporate firewalls will carry on filtering inbound ICMPv6.
ICMP is again not a feature that benefits consumers, regardless of whether it is IPSec secured or not.
IPV6, is mostly beneficial to an ISP, because it helps to provide more publically addressable space now that IPV4 is depleted. Firewalls are still required on consumer devices, even in the absence of NAT. Stateful connectivity is still required, even in the absence of NAT, which means devices would still prefer "outbound" connections rather than sitting unprotected and accepting random "inbound" connections. (I certainly would).
IPV6 is not a magic bullet, and if properly implemented, the customer won't even know, or see a difference. There is no "major" direct benefit to an end user. It's not faster than IPV4. It's just another IP address, with a lot more digits.
So, yes, we are deploying V6, and we have had V6 live since our AS went live. https://bgp.he.net/net/2c0f:f9a8::/32, and have suplied free IPv6 transit to JAWUG, and at least one ISPA iWeek that we were involved in.
But it's not just case of "switching" it on. There is quite a bit of engineering, and technical support gearing that needs to happen.
We are moving our Openserve to L2TP terminated which means we can start offering V6 on OpenServe, and for the rest of our PPPoE connected clients such as Octotel, MFN, Vumatel Aerial we will also start offering it.
It's in our interest to do it, but at the end of the day, most of our customers wouldn't even know, or realize.
Many ISPd dished out a large number of /28, /29, /30's that can all go to /31's. Would easily double up the space for those.The peering isn't the issue, we have V6 peering sessions up wherever we can and where a peer supports it. It's just not really going anywhere to a customer.
For that, we have to deploy OSPFv3 on our entire network, which is something on our "to-do" list. Setting up more route reflectors to support BGP/V6 is also on the list, which is also part of the picture.
It's not so much a peering issue, as enabling V6 on our entire core, right up to the access networks, which is on our list of priority things to-do. Deploying IPv6 pools on each and every access router we have is also on the list.
Trust me, it's not an insignificant task.
V6 basically means running another network on top of your current fabric, which means revisiting everything, every router, every point-to-point link, every subnet, and every IP pool. I have already devised a cunning plan to script/deploy this in a phased fashion, effectively mirroring our IPv4 deployment but in an automated fashion, since the entire IPv4 space is easily encapsulated in our entire IPv6 space, which allows us to mirror every IPv4 link "inside" our IPv6.
For us, it is a priority, but frankly it seems that our customer base is more concerned with Bahrain, Frankfurt and AWS pings than anything else.
Yeah, bugger IPv6 - jumbos are more important.That is my understanding about IPv6, it just adds a whole lot more IP address as IPV4 has run out, but the internet would still work the same, no speed benefit, no magic is going to happen, all transparent, not gaining any new abilities. Thanks for clarifying Roelf.