So Cisco had some big announcements today. Cisco Digital Network Architecture (DNA). Ohhh, sounds fancy. Let me put on something a little more formal before I get too involved in the post. So what are all these awesome acronyms, you may be wondering? Well basically we start with DNA, which is the overall ecosystem that […]
The post Cisco Enterprise NFV, DNA, IWAN and a bunch of other acronyms appeared first on Packet Pushers.
IT departments are going crazy with all the disparate cloud apps.
This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
Hybrid cloud implementations are becoming standard for companies building next-generation cloud applications, but their adoption raises questions about how to run and manage database operations that support both environments.
While hybrid cloud allows IT to expand infrastructure resources only when required (i.e. ‘bursting’), improves disaster prevention, and makes it possible to offload some hardware and operational responsibility and associated costs to others, database issues to consider include:
To read this article in full or to leave a comment, please click here
This week two different folks have asked me about when and where I would split up a flooding domain (IS-IS) or area (OSPF); I figured a question asked twice in one week is worth a blog post, so here we are…
Before I start on the technical reasons, I’m going to say something that might surprise long time readers: there is rarely any technical reason to split a single flooding domain into multiple flooding domains. That said, I’ll go through the technical reasons anyway.
There are really three things to think about when considering how a flooding domain is performing:
Let’s look at the third issue first, the database size. This is theoretically an issue, but it’s really only an issue if you have a lot of nodes and routes. I can’t ever recall bumping up against this problem, but what if I did? I’d start by taking the transit links out of the database entirely—for instance, by configuring all the interfaces that face actual host devices as passive interfaces (which you should be doing anyway!), and configuring IS-IS to advertise just the passive interfaces. You can pull similar tricks in OSPF. Continue reading
Software package takes NFV beyond service provider networks.
Leaba's founders could be the main attraction.
The post Worth Reading: Beyond ‘Neutrality’ appeared first on 'net work.
Normally, I would be writing this a few weeks ago, but sometimes the world just takes the luxury of time away from you. In this case, I couldn’t be happier though as I’m about to part of something that I believe is going to be really really amazing. This event is really a testimony to Brent Salisbury and John Willis’s commitment to community and their relentless pursuit of trying to evolve the whole industry, bringing along as many of the friends they’ve made along the way as possible.
Given the speaker list, I don’t believe there’s been any event in recent ( or long term!) memory that has such an amazing list of speakers. The most amazing part is that this event was really put together in the last month!!!!
If you’re in the bay area, you should definitely be there. If you’re not in the area, you should buy a plane ticket as you might not ever get a chance like this again.
From the website
previously known as DevOps4Networks is an event started in 2014 by John Willis and Brent Salisbury to begin a discussion on what Devops Continue reading
Introduction
Sometimes a customer needs a L3 VPN between two locations where the same SP is not present. This can be on a national or international basis. It would be possible to buy an Internet circuit and run an overlay such as DMVPN but what if the customer wants to buy a MPLS VPN circuit?
The customer could buy a VPN from SP1 in location1 and a VPN from SP2 in location2. The two SPs would then have to exchange traffic somehow to make the customer circuit end to end. The concept is shown in the following topology.
The customer connects to the PE of each of the SPs. The SPs need to interconnect at some common point, either through a public peering place such as an IX or with an private interconnect at a common location. The routers that connect to each other are called autonomous system border routers (ASBR). There are three main options and a fourth option which combines two of the others.
Inter-AS Option A
Option A is the most simple of the options to interconnect the ASBRs. Each customer VRF requires either a physical interface or more likely a subinterface. Option A has Continue reading