A few years ago, I took an SE role covering Higher Education accounts. I quickly realized one of the deficits Cisco has in the CCNA program as it pertains to networks with a certain set of requirements. While the program is jam-packed with great information, there are a few concepts that an administrator may have to deal with that catch them by surprise. Three related topics that aren’t covered in CCNA Routing and Switching are shown below.
This article is meant to serve as a starting point for those who may be very strong with routing and switching but lack the exposure to VRFs, Layer 3 Segmentation, and MPLS. It is a good starting point for new employees that might face this challenge and it will certainly help them gain perspective on these topics.
It's no secret that Cloudflare operates at a huge scale. Cloudflare provides security and performance to over 9 million websites all around the world, from small businesses and WordPress blogs to Fortune 500 companies. That means one in every 10 web requests goes through our network.
However, hidden behind the scenes, we offer support in using our platform to all our customers - whether they're on our free plan or on our Enterprise offering. This blog post dives into some of the technology that helps make this possible and how we're using it to drive encryption and build a better web.
Recently web browser vendors have been working on extending encryption on the internet. Traditionally they would use positive indicators to mark encrypted traffic as secure; when traffic was served securely over HTTPS, a green padlock would indicate in your browser that this was the case. In moving to standardise encryption online, Google Chrome have been leading the charge in marking insecure page loads as "Not Secure". Today, this UI change has been pushed out to all Google Chrome users globally for all websites: any website loaded over HTTP will be marked as insecure.
That's not all though; Continue reading
This is the final article in the MPLS Intro Series and will quickly mention the need for route reflectors. This need is driven by the iBGP requirement for a full mesh of peers. This means that a network with only 4 PE nodes would have 6 iBGP peering sessions. This is calculated as n(n-1)/2 where n is the number of PE nodes required for a given topology.
As the scale grows, the need for a centralized peering point becomes obvious. For example, a network with 10 PE nodes would have 45 iBGP sessions to meet the full mesh requirement. Route reflectors overcome this rule by becoming a central point that can advertise routes between iBGP “route reflector clients”. The diagram below actually has more peering sessions than the one above (without RR). However, as a network continues to grow, the full mesh becomes quite challenging.
This is the extent of what I really wanted to cover in this introductory level article and this article concludes the MPLS Intro Series. If you want to learn more about VPNv4 and route reflectors, you can check out this video below.
LabMinutes# SP0015 – Cisco MPLS VPN with BGP Route Reflector (Part 1)
Disclaimer: Continue reading
Adding Feger is the latest in a number of hires by F5 as it shifts its business model to prepare for 5G, IoT, and the cloud.
Verizon will have four 5G markets launched in 2018. AT&T says it will have a dozen.
The SNAPS-Kubernetes platform helps to deliver virtual network functions that use fewer resources, are more fault-tolerant, and can scale quickly to meet demand.
OSCON 2018 did a great job of highlighting women and people of color in their programming.
Using a VPN is painful. Logging-in interrupts your workflow. You have to remember a separate set of credentials, which your administrator has to manage. The VPN slows you down when you're away from the office. Beyond just inconvenience, a VPN can pose a real security risk. A single infected device or malicious user can compromise your network once inside the perimeter.
In response, large enterprises have deployed expensive zero trust solutions. The name sounds counterintuitive - don’t we want to add trust to our network security? Zero trust refers to the default state of these tools. They trust no one; each request has to prove that itself. This architecture, most notably demonstrated at Google with Beyondcorp, has allowed teams to start to migrate to a more secure method of access control.
However, users of zero trust tools still suffer from the same latency problems they endured with old-school VPNs. Even worse, the price tag puts these tools out of reach for most teams.
Here at Cloudflare, we shared those same frustrations with VPNs. After evaluating our options, we realized we could build a better zero trust solution by leveraging some of the unique capabilities we have here at Cloudflare:
Gigamon will combine its network traffic visibility capabilities with Icebrg’s security platform and allow SOC teams to deploy new security technologies as “security applications” on top of it.
The following is a guest post by Troy Hunt, awarded Security expert, blogger, and Pluralsight author. He’s also the creator of the popular Have I been pwned?, the free aggregation service that helps the owners of over 5 billion accounts impacted by data breaches.
I still clearly remember my first foray onto the internet as a university student back in the mid 90's. It was a simpler online time back then, of course; we weren't doing our personal banking or our tax returns or handling our medical records so the whole premise of encrypting the transport layer wasn't exactly a high priority. In time, those services came along and so did the need to have some assurances about the confidentiality of the material we were sending around over other people's networks and computers. SSL as it was at the time was costly, but hey, banks and the like could absorb that given the nature of their businesses. However, at the time, there were all sorts of problems with the premise of serving traffic securely ranging from the cost of certs to the effort involved in obtaining and configuring them through to the performance hit on the Continue reading
Time for another Cumulus content roundup! We’ve been really busy this summer, so there’s a little bit of everything in this post: videos, industry news articles, new podcast episodes and even an entire book! So if you’ve got room on your summer reading list, be sure to add EVPN in the Data Center. Or, if you’ve got too much to do and can’t find time to sit down and read, grab a pair of headphones and listen to the latest episode of Kernel of Truth while you work. The choice is yours!
Kernel of Truth episode 03 — Linux: the kernel, the community & beyond: You can’t name an open networking podcast “Kernel of Truth,” and NOT have an episode dedicated to the Linux kernel! Listen to our discussion about the Linux community and why Linux belongs in the data center.
EVPN in the Data Center: This eBook cuts through the fog and explains how you can deploy this technology seamlessly in your data center. You’ll discover why EVPN can be simpler to use in data centers than in service provider networks.
Vault Systems customer video: As a cloud provider for the Australian government, Continue reading
In our last article, we configured and tested a basic VPNv4 configuration. In this article, we will do a hop by hop analysis of each device and look at a packet capture for a couple of the steps in the label switched path. We are using the exact same topology and router names. For the example, I have shut down the connection between P4 and PE2 so no load balancing will occur and we have a deterministic path to analyze.
For the analysis, we will examine the path from CE_Site_1 to 20.2.2.2 at CE_Site_2. For each device, we want to determine the egress interface, the next hop and any MPLS labels that should be present.
CE_Site_1#show ip cef 20.2.2.2 0.0.0.0/0 nexthop 10.1.1.1 GigabitEthernet2
CE_Site_1 is using the default route with a next-hop of 10.1.1.1
//based on physical topology, we know this will arrive on Gi4 of PE1 PE1#show vrf brief Name Default RD Protocols Interfaces BLUE 110:210 ipv4 Gi5 Mgmt-intf Continue reading
In the previous article, we took a look at building a simple label switched path (LSP) through an MPLS network. This article takes the configuration a step further and leverages multiple labels to connect and isolate VRFs over an MPLS core. This is known as MPLS VPNv4. My goal is to introduce a method to bring together VRF segmentation concepts and provide a framework for a scalable deployment.
Before we get started, I am going to rename the routers once again based on their target function. An LER in a VPNv4 configuration is known as a PE node. An LSR router is known as a P node. I am also introducing CE (customer edge) nodes into the topology.
In this example, we will allow CE_Site_1 to communicate with CE_Site_2. Likewise, we want CE_Site_3 to communicate with CE_Site_4.
The APAC & Middle East Chapters joined hands to organize their combined Regional Chapters Meeting from 11 to 12 May in Kathmandu, Nepal. 23 Fellows representing 18 regional Chapters and Women SIG were nominated by their respective Chapters/SIGs to participate in this meeting. Half of the meeting focused on collaboratively developing action plans that are aligned with the Internet Society’s 2018 campaigns, while the other half was to discuss and address regional and governance-related issues.
At the end of the workshop, 18 concrete plans were ready for implementation:
During the regional breakout sessions, Fellows from the APAC region voted for and discussed three major regional issues: 1) Cybersecurity, 2) Transition [of the Internet] to the younger generation, 3) Digital Literacy. They engaged in an open discussion and highlighted some of the specific issues under these topics, what is needed in the context of their region, and shared their plans to address them.
The regional Continue reading
“We believe we are the first to come to the market with 400 Gig,” says Juniper’s CTO.
In the previous article, we created an interesting situation with an iBGP configuration. In that example, we made Edge2 aware of a route via BGP that the intermediary hops would not see. In this article, we will fix this problem using MPLS and label switching. Before getting started, I feel compelled to rename these routers based on their target role in an MPLS our network.
As we left it in our previous configuration, the router on the right sees a route to 1.0.1.1 via BGP but it cannot reach that destination. It is worth mentioning that I disabled BGP sync (following the last example I shared in the previous article).
LER2#show ip route | inc 1.0.1.1 B 1.0.1.1 Continue reading