The previous chapter describes how Edge-xTR-11 used LISP Map-Register message to advertise EID-to-RLOC information to MapServ-22. It also explained how MapSrv-22, as a role of Mapping Server, stores the information into Mapping Data Base. MapSrv-22 is also Map-Resolver. This means that when it receives the LISP Map-Requestmessage from the xTR device, it will respond with a Map-Reply message. If MapSrv-22 knows the EID-to-RLOC mapping, it places this information into the Map-Reply message. If MapSrv-22 doesn’t have mapping information, it instructs requesting xTR to forward traffic to its Proxy-xTR. This, however, is not the case in our example. What we want to do is advertise the EP1 reachability information to Border-PxTR. In order to do that, we need to a) export EID-to-RLOC information from the Mapping Data Base to instance-specific VRF_100 RIB. Then we can advertise it by using BGP and because we want to include virtual network identifier into update we use MP-BGP VPNv4 because there we have Route Target Attribute. The next sections describe the process in detail.
LISP Map-Server doesn’t install EID-to-RLOC mapping information from the Mapping Database into a RIB by default. To do that we need to export the information from the LISP Mapping DataBase to RIB by using the LISP Instance-specific command route-export site-registrations. Example 1-6 illustrates the update process. Example 1-7 shows the RIB entry concerning EP1 IP address 172.16.100.10/32 in VRF 100_NWKT. Due to redistribution, the route is shown as directly connected, via Null0. If you take a look at the timestamps in example 1-6 and compare it to timestamps in example 1-3, you will see that the RIB update happens right after the unreliable EID-to-RLOC registration process.
Complete device configuration can be found in chapter 1 Appendix 1.
Figure 1-10: EID-to-RLOC information from LISP to RIB.
Continue reading
Today, we are excited to announce an expansion we’ve been working on behind the scenes for the last two years: a 25+ city partnership with one of the largest ISPs in Brazil. This is one of the largest simultaneous single-country expansions we’ve done so far.
With this partnership, Brazilians throughout the country will see significant improvement to their Internet experience. Already, the 25th-percentile latency of non-bot traffic (we use that measure as an approximation of physical distance from our servers to end users) has dropped from the mid-20 millisecond range to sub-10 milliseconds. This benefit extends not only to the 25 million Internet properties on our network, but to the entire Internet with Cloudflare services like 1.1.1.1 and WARP. We expect that as we approach 25 cities in Brazil, latency will continue to drop while throughput increases.
This partnership is part of our mission to help create a better Internet and the best development experience for all — not just those in major population centers or in Western markets — and we are excited to take this step on Continue reading
What's the latest with network automation? Where is the industry getting things right, and where is there more work to be done? How is public cloud influencing network automation? Scott Lowe welcomes Ethan Banks to the Full Stack Journey podcast for an update on the state of automation in networking.
The post Full Stack Journey 056: Network Automation Progress And Problems appeared first on Packet Pushers.
Recent weeks have witnessed massive ransomware and ransom DDoS (Distributed Denial of Service) attack campaigns that interrupted aspects of critical infrastructure around the world, including one of the largest petroleum pipeline system operators, and one of the world’s biggest meat processing companies. Earlier this quarter, more than 200 organizations across Belgium, including the government and parliament websites and other services, were also DDoS’d.
And when most of the United States were celebrating Independence Day on July 4, hundreds of US companies were hit by a ransomware attack demanding 70 million USD in Bitcoin. Attackers known to be affiliated with REvil, a Russian ransomware group, exploited multiple previously unknown vulnerabilities in IT management software. The targets included schools, small public-sector bodies, travel and leisure organizations, and credit unions, to name a few. While the threat of ransomware and ransom DDoS is not new (read our posts on ransomware and ransom DDoS from 2021 Q1), the latest attacks on Internet properties ranging from wineries, professional sports teams, ferry services and hospitals has brought them from just being background noise to front page headlines affecting our day-to-day lives. In fact, recent attacks have propelled ransomware and DDoS to the top of US Continue reading
I have written a couple of books about Network Virtualization Overlay over Layer 3 (NVO3). My first book was about Datacenter network virtualization based on BGP L2VPN EVPN. After that, I wrote a book about Campus networks based on LISP. In my latest book, I introduced the Cisco SD-WAN solution running OMP in Control-Plane. I wanted to write one more book where I combine these three different NVO3 solutions. I haven’t used pictures in the “About This Book” section in my previous books but now I decided to do that because one picture tells more than 1000 words. The figure below combines these three NVO3 solutions and illustrates what is needed to have IP connectivity between EP1 in the LISP domain and EP2 in the BGP EVPN domain. After reading this book you should be able to understand the processes of how IP reachability information about local hosts are advertised from the LISP domain over the SD-WAN to BGP EVPN domain and another way around. I wanted to keep this complex solution as simple as possible. That is why I didn’t include any redundancy.
Continue reading
MPLS/VPLS MTU math can be complicated and is always a struggle to unravel.
To make it a little easier and put it into a WISP context, I designed this cheat sheet on 8.5 x 11 (to print for those that actually trust printers) and used common WISP equipment like MikroTik routers, Ubnt and Cambium radios with real world MTU values.
The MTU values are displayed in layers to make it easier to see where each value fits.
PDF is here
These values are meant to be a starting point by representing the minimum values required for MPLS/VPLS with a single 802.1q VLAN tag.
In general, after going through hundreds of WISP migrations, I’ve found it to be easier to implement the minimum values required when working on a production WISP to identify the effective lowest MTU in the network.
Once the network equipment has been modified and has been running in a stable way on the minimum values, then higher values can be considered and implemented (now that the effective lowest MTU on the network is documented)
On today's sponsored Tech Bytes episode, we talk with AppNeta about instrumenting application performance to support on-prem and remote employees in today's hybrid work environment. Our AppNeta guests are Sean Armstrong, VP of Products; and Alec Pinkham Director of Product Marketing.
The post Tech Bytes: Instrumenting For Hybrid Work With AppNeta (Sponsored) appeared first on Packet Pushers.
There is never enough. Whatever you name in the world of networking, there is simply not enough. There are not enough ports. There is not enough speed. There is not enough bandwidth. Many times, the problem of “not enough” manifests itself as “too much”—there is too much buffering and there are too many packets being dropped. Not so long ago, the Internet community decided there were not enough IP addresses and decided to expand the address space from 32 bits in IPv4 to 128 bits in IPv6. The IPv6 address space is almost unimaginably huge—2 to the 128th power is about 340 trillion, trillion, trillion addresses. That is enough to provide addresses to stacks of 10 billion computers blanketing the entire Earth. Even a single subnet of this space is enough to provide addresses for a full data center where hundreds of virtual machines are being created every minute; each /64 (the default allocation size for an IPv6 address) contains 4 billion IPv4 address spaces.
But… what if the current IPv6 address space simply is not enough? Engineers working in the IETF have created two different solutions over the years for just this eventuality. In 1994 RFC1606 provided a Continue reading