Today's IPv6 Buzz discusses different strategies for going IPv6-only in both greenfield and brownfield environments.
The post IPv6 Buzz 096: Greenfield Vs. Brownfield IPv6-Only Deployments appeared first on Packet Pushers.
Social media is one of the most used sites all over the world used by most mobile users counting to hundreds of millions of users. It provides different services to its users. It can be used as a fun site to upload images and videos, as a means of communication, as a way to meet different people of different beliefs and cultures all over the world, to learn and explore new and different things, and also as a business place. You reading this article also includes you among the social media users and you’ll know that there is a lot to benefit from using these sites. Let’s consider some of the most popular social media sites and what you should know about them.
LISP started as yet-another ocean-boiling project focused initially on solving the “we use locators as identifiers” mess (not quite), and providing scalable IPv6 connectivity over IPv4-only transport networks by adding another layer of indirection and thus yet again proving RFC 1925 rule 6a. At least those are the diagrams I remember from the early “look at this wonderful tool” presentations explaining for example how Facebook is using LISP to deploy IPv6 (more details in this presentation).
Somehow that use case failed to gain traction and so the pivots1 started explaining how one can use LISP to solve IP mobility or IP multihoming or live VM migration, or to implement IP version of conversational learning in Cisco SD-Access. After a few years of those pivots, I started dismissing LISP with a short “cache-based forwarding never worked well” counterargument.
LISP started as yet-another ocean-boiling project focused initially on solving the “we use locators as identifiers” mess (not quite), and providing scalable IPv6 connectivity over IPv4-only transport networks by adding another layer of indirection and thus yet again proving RFC 1925 rule 6a. At least those are the diagrams I remember from the early “look at this wonderful tool” presentations explaining for example how Facebook is using LISP to deploy IPv6 (more details in this presentation).
Somehow that use case failed to gain traction and so the pivots1 started explaining how one can use LISP to solve IP mobility or IP multihoming or live VM migration, or to implement IP version of conversational learning in Cisco SD-Access. After a few years of those pivots, I started dismissing LISP with a short “cache-based forwarding never worked well” counterargument.
VMware-based workload environments are the norm in private clouds for enterprise-class customers. 100%[1] of Fortune 500 companies deploy vSphere/ESXi. Further, ~99% of Fortune 1000 and ~98%[2] of Forbes Global 2000 companies deploy vSphere/ESXi. VMware’s deep presence in enterprise private clouds has made NSX Firewall the preferred micro-segmentation solution for these enterprises.
Below, we expand on how the NSX Firewall has developed its prominent position in enterprise private clouds.
Virtualized x86 workloads on hypervisors represent ~80%[3] of all enterprise workloads. VMware’s hypervisor-based micro-segmentation solution – NSX Firewall – is the preferred agentless solution for such workloads because of the solution’s tight integration with the rest of the VMware eco-system.
~15% of workloads at enterprises are x86-based (Windows, Linux) but not virtualized. The NSX Firewall handles these workloads with NSX agents.
~5% of workloads at enterprises are non-x86-based. VMware provides an (agentless) layer 2-7 gateway firewall that supports micro-segmentation for these workloads. Note that the gateway firewall eliminates the need for integration with physical switches, routers, and load-balancers.
Between these mechanisms, 100% of all workloads in the private cloud are protected. In practice, given VMware’s penetration of enterprises, VMware’s agentless solutions apply to the vast Continue reading
Can computation be drawn into the network, rather than always being pushed to the edge of the network? Taking content distribution networks as a starting point, the COIN research group is looking at ways to make networks more content and computationally aware, bringing compute into the network itself. Join Alvaro Retana, Marie-Jose Montpetit, and Russ White, as we discuss the ongoing research around computing in the network.
In this Tech Bytes episode we welcome back Singtel to discuss real-life examples of WAN problems from customers and how Singtel helped solve them.
The post Tech Bytes: Solving WAN Problems With Singtel Solutions (Sponsored) appeared first on Packet Pushers.
On the morning of March 8, a post to Hacker News stated that “All .fj domains have gone offline”, listing several hostnames in domains within the Fiji top level domain (known as a ccTLD) that had become unreachable. Commenters in the associated discussion thread had mixed results in being able to reach .fj hostnames—some were successful, while others saw failures. The fijivillage news site also highlighted the problem, noting that the issue also impacted Vodafone’s M-PAiSA app/service, preventing users from completing financial transactions.
The impact of this issue can be seen in traffic to Cloudflare customer zones in the .com.fj second-level domain. The graph below shows that HTTP traffic to these zones dropped by approximately 40% almost immediately starting around midnight UTC on March 8. Traffic volumes continued to decline throughout the rest of the morning.
Looking at Cloudflare’s 1.1.1.1 resolver data for queries for .com.fj hostnames, we can also see that error volume associated with those queries climbs significantly starting just after midnight as well. This means that our resolvers encountered issues with the answers from .fj servers.
This observation suggests that the problem was strictly DNS related, rather than connectivity related—Cloudflare Radar Continue reading
I got an interesting question that nicely illustrates why Segment Routing (the MPLS variant) is so much better than LDP. Imagine a redundant hub-and-spoke network with hundreds of spokes. Let’s settle on 500 spokes – IS-IS supposedly has no problem dealing with a link-state topology of that size.
Let’s further assume that all routers advertise only their loopbacks1 and that we’re using unnumbered hub-to-spoke links to minimize the routing table size. The global routing table thus contains ~500 entries. MPLS forwarding tables (LFIB) contain approximately as many entries as each router assigns a label to every prefix in the routing table2. What about the LDP table (LIB – Label Information Base)?