A new video series publishing weekly. We will take a story that is suitable for video and cover it. Here is the first “Incident” for Network Break TV published on the Packet Pushers Youtube Channel. You should totally subscribe right now The music and intro screens are making me cringe a little. I’ll keep working […]
The post Network Break TV – The Video appeared first on EtherealMind.
This is an excerpt from the Network Break podcast – check the whole show at https://packetpushers.net/series/network-break-podcast-post/ Mirai Botnet Weaponises F5 Appliances. –TrendMicro is reporting that a known vulnerability in F5 Big-IP load balancers is being used by the Mirai botnet. The vulnerability, which has score of 10 on the Common Vulnerability Scoring System, […]
The post Network Break TV – Incident 001 – F5 Devices Being Compromised appeared first on Packet Pushers.
MPLS Applications, what are the MPLS Applications?. MPLS Applications mean MPLS Services. So what can we do with MPLS basically.
Although the very first purpose of MPLS was fast switching, by the time services/applications with MPLS evolved and there are just so many reasons to use MPLS.
Below are some of the most common use case , or in other words, Applications with MPLS.
Important MPLS applications/services for the network designers are listed below.
MPLS infrastructure can have all of the above MPLS application/ services at the same time. Most of them are architecture, so MPLS Labeling protocols itself (such as LDP, RSVP) are not enough for providing above applications/services.
Usually MPLS protocols, are used commonly with BGP, IGP and other protocols.
I just wanted to mention what people mean when they talk about MPLS applications, thus I am keeping post short but before I finish the post, let me recommend you a book, called . ‘ MPLS Enabled Applications‘.
If you are dealing with network design, above book is must to read.
The post MPLS Applications/Services appeared first on orhanergun.net.
Integrated Services QoS – Hard QoS is first QoS approach, but currently we are not using. At the end of this post, you will know what is Integrated QoS, what was the idea with it and why it is not used today.
Quality of service (QoS) is the overall performance of a telephony or computer network, particularly the performance seen by the users of the network.
Two QoS approaches have been defined by standard organizations.
These are:
Intserv QoS demands that every flow requests a bandwidth from the network and that the network would reserve the required bandwidth for the user during a conversation.
Think of this as on-demand circuit switching, each flow of each user would be remembered by the network. This clearly would create a resource problem (CPU, memory , bandwidth) on the network, and thus it was never widely adopted.
Not only allocation bandwidth for each and every flow on each network device in the path, but also keep tracking these flows and tearing down when the flow is terminated is very resource intensive and people thought this will not be scalable and we haven’t seen deployment for it.
Protocol for Integrated Services was RSVP – Resource Reservation Protocol. Although we don’t see usage of RSVP for Integrated Services, it is used in MPLS , by allocation Label for the destinations.
Integrated Services is known as Hard QoS because flows are assigned bandwidth, with the SoftQoS or commonly known as Diffserv – Differentiated Quality of Service, flows are not assigned a bandwidth, instead we have application classes which gets bandwidth allocation. Thus, considered as much more scalable.
Diffserv doesn’t require reservation; instead flows are aggregated and placed into classes. Each and every node can be controlled by the network operator to treat differently for the aggregated flows.
Diffserv is a more scalable approach compared to Intserv and today if you are using QoS, you are dealing with Diffserv – Differentiated Services QoS or another name, SoftQoS!
The post Integrated Services QoS – Hard QoS appeared first on orhanergun.net.
CGN is also known as LSN (Large Scale NAT). And in my opinion, it should be called LSN since there is nothing for CGN to be a carrier grade. It is just a NAT.
With CGN, Service Providers do NAT44 on the CPE from private address to another private address (Well known /10 prefix which is allocated by IANA) and another NAT44 on the Service Provider network. That’s why you can hear CGN, LSN, Double NAT or NAT444. All of them refer to the same thing.
CGN and so many IPv6 topics are covered in great detail in my IPv6 Zero to Hero Course.
But with CGN you are not enabling IPv6.
CGN is a way to solve the IPv4 depletion problem in a very problematic way. Companies are also using trade-market to purchase IPv4 public addresses. Average cost per IPv4 address is around 8-10$ currently. This might increase by the time. And it would be wise to expect to see much bigger DFZ space by the time because of de-aggregation.
With CGN, IPv4 private addresses are shared among many customers and those shared addresses are NATed at the CGN node twice.
The post Understanding CGN – Carrier Grade NAT appeared first on orhanergun.net.
VPN – Virtual Private Network is most common overlay mechanism in Networking. We have many of them, GRE, mGRE, IPSEC, DMVPN, GETVPN, LISP, FlexVPNs, MPLS VPNs and so on. But what are the important and fundamentals thing about VPNs?.In this post I will explain some of them.
Virtual Private Network is the logical entity, which is created over a physical infrastructure. It can be setup over another private network such as MPLS or public network such as Internet.
All VPN technologies add extra byte to the packet or frame, which increases the overall MTU so the network links should be accommodated to handle bigger MTU values.
VPN technologies work based on encapsulation and decapsulation.
For example GRE, mGRE and DMVPN encapsulate IP packets into another IP packet, VPLS and EVPN encapsulates Layer 2 frame into an MPLS packets.
You can run routing protocols over some VPN technologies but not all VPN technologies allow you to run routing protocols.
In order to support routing over tunnel, tunnel endpoints should be aware from each other.
For example MPLS Traffic Engineer tunnels don’t support routing protocols to run over, since the LSPs are unidirectional which mean Head-end and Tail-end routers are not associated. This will be explained in detail in MPLS chapter.
About VPNs, if you are looking for much more detail knowledge, from design and hands-on perspective, please refer to my VPN Training.
The post Some must to know information about VPNs appeared first on orhanergun.net.
OPEX and CAPEX are two important network design considerations. From the high level we should understand these two design requirements.
OpEx refers to operational expenses such as support, maintenance, labor, bandwidth and utilities. Creating a complex network design may show off your technical knowledge but it can also cause unnecessary complexity making it harder to build, maintain, operate and manage the network.
A well- designed network reduces OpEx through improved network uptime (which in turn can avoid or reduce penalties related to outages), higher user productivity, ease of operations, and energy savings. Consider creating the simplest solution that meets the business requirements.
CapEx refers to the upfront costs such as purchasing equipment, inventory, acquiring intellectual property or real estate. A well-thought design provides longer deployment lifespan, investment protection, network consolidation and virtualization, producing non-measurable benefits such as business agility and business transformation and innovation, thus reducing risk and lowering costs in the long run.
Last metric in the COST constraint is TCO (Total cost of ownership).
TCO is a better metric than pure CapEx to evaluate network cost, as it considers CapEx plus OpEx. Make your network designs cost-effective in the long run and do more with less by optimizing both CapEx and OpEx.
There are certainly other network design attributes such as Flexibility, security, modularity and hierarchical design.
On the website, there are many other design requirements explained. If you find this post useful, please share your comment in the comment section.
The post OPEX and CAPEX in Network Design appeared first on orhanergun.net.
When it comes to Routing Security, BGP Origin and Path Validation should be understood very well.
It is the problem of all, not just large Service Providers. Enterprises, Service Providers, Mobile Operators, basically whoever are interacting with Global Routing.
IRR, RPKI, BGPSEC, Origin Validation and Path Validation are the fundamentals of BGP Routing Security. We have many other posts for the subject on the website but in this post I want to share with you new approach for BGP Path Validation. It is called as AS-Cones.
At the moment, it is still IETF draft but soon it is expected to be Standard RFC.
I discussed it with the inventor of the mechanisms, Melchior Aelmans along with many other routing security topic and decided to share with you!
In the below video, Orhan Ergun, Melchior Aelmans and Jeff Tantsura, discussing new approaches in BGP Security – Path Validation.
They explain ASPA – Autonomous System Provider Authorization , and another approach AS-Cone and they compare those two.
Not only BGP Security Path Validation, but they identify the current known problems of the Global Routing Table/DFZ, such as Hijacks, different types of hijacks, route leaks and they discuss some prevention techniques such as BigNetwork Filter, Peer Lock, IRR , RPKI , Origin Validation and many other things, during 2 hours, intense discussion.
If you are interested in routing , routing security, this is one of the must to watch video.
The post BGP Path Validation New Mechanism – AS Cones appeared first on orhanergun.net.
Flat/Single Level vs. Multi Level IS-IS Design Comparison. Flat routing means, without hierarchy, entire topology information of the network is known by each and every device in the network.
IS-IS has two levels. Thus, for IS-IS, Multi Level means Two Level IS-IS. Level 1 and Level 2.
When we have two levels, Level 1 routers don’t know the topology of Level 2 and vice versa. By hiding topology information of different level routers, scalability is achieved. Reason we achieve more scalable network is when there is a failure or new information added or metric changes in one Level, another level doesn’t run SPF algorithm.
But what are the design consideration when we have Flat or Multi Level IS-IS networks. Is Multi Level IS-IS design, which mean, Hierarchical IS-IS design always good? Answer is no. Although Multi Level provides Scalability, it comes with extra complexity and end to end routing convergence time increase.
So, I prepared below comparison charts to discuss different design aspects when it comes to IS-IS Single vs. Multi Level design.
If you like this comparison chart, you can see more of them in my CCIE Enterprise Training.
The post Flat/Single Level vs. Multi Level IS-IS Design Comparison appeared first on orhanergun.net.
When it comes to fast convergence, first thing that we need to understand what is convergence?
Convergence is the time between failure and the recovery. Link, circuits, routers, switches all eventually fails. As a network designers, our job is to understand the topology and whenever there is qrequirement, add backup link or node. Of course, not every network, or not every place in the network requires redundancy though. But let’s assume, we want redundancy, thus we add backup link or node and we want to recover from the failure as quickly as possible, by hoping before Application timeout.
But what is the time for us to say , this network is converging fast. Unfortunately, there is no numerical value for it. So, you cannot say, 30 seconds , or 10 seconds , or 1 second is fast convergence. Your application convergence requirement might be much below 1 second.
Thus, I generally call ‘ Fast Convergence’ is the convergence time faster than default convergence value. Let’s say, OSPF on Broadcast media is converging in 50 seconds, so any attempt to make OSPF convergence faster than 50 seconds default convergence value is OSPF Fast Convergence on Broadcast media.
There are in general 4 steps for making the convergence faster, so 4 steps for Fast Convergence.
1. Failure detection
Layer 1 Failure detection mechanisms:
BFD (Bidirectional Forwarding Detection)
For the failure detection, best practice is always use Physical down detection mechanism first. Even BFD cannot detect the failure faster than physical failure detection mechanism.
Because BFD messages is pull based detection mechanism which is
sent and receive periodically, but physical layer detection mechanism is
event driven and always faster than BFD and Protocol hellos.
If physical layer detection mechanisms cannot be used (Maybe because there is a transport element in the path), then instead of tuning protocol hello timers aggressively, BFD should be used. Common example to this is if there are two routers and connected through an Ethernet switch, best method is to use BFD.
Compare to protocol hello timers, BFD is much ligher in size, thus consumes less resource and bandwidth.
2. Failure propagation
Propagation of failure throughout the network.
Here LSP throttling timers come into play. You can tune LSA
throttling for faster information propagation. It can be used to slow down the information processing as well. Also LSP pacing timers can be tuned for sending update much faster.
3. New information process
Processing of newly arrived LSP to find the next best path. SPF
throttling timers can be tuned for faster information process for fast convergence.
4. Update new route into RIB/FIB
For fast convergence, these steps may need to be tuned. Although
the RIB/FIB update is hardware dependent, the network operator can configure all other steps. One thing always needs to be kept in mind; Fast convergence and fast reroute can affect network stability.
In both OSPF and IS-IS Exponential backoff mechanism is used to protect the routing domain from the rapid flapping events. It slows down the convergence by penalizing the unstable prefixes. Very similar mechanism to IP and BGP dampening.
The post Four necessary steps in routing fast convergence appeared first on orhanergun.net.
MTL – Multi Technology Lab consist of many technologies in a large topology. When network design is considered, there is no single protocol, many protocols interact with each other. In my CCIE Enterprise Infrastructure Training, I have many MTL (Multi Technology Lab), and students are able to watch the videos, and with the config files, they are able to perform each task in the Lab themselves.
From OSPF, EIGRP to BGP, QoS to Multicast, Layer 2 Technologies to Security, SD-WAN and many other technologies are all in the same lab. Traditionaly these kind of Labs were called as Mock Labs but better term is Multi Technology Lab. If you see on the social media next time one of this labs with OE logo, you know that it is MTL! Let me see your comment 
You can check the schedule of next CCIE Enterprise Course by clicking here!
The post What is MTL in CCIE Enterprise Infrastructure Training? appeared first on orhanergun.net.
OSPF is the most common network engineer interview topics without any doubt. Almost all network engineers faced with some OSPF questions in their interview. Thus I thought it is important to cover common questions and the answer with the blog post.
From OSPF LSAs to OSPF Areas, by having Multi Area Hierarchical OSPF for stability, OSPF security and OSPF Fast Convergence, I prepared many questions and explaining them in detail in the below video.
There are many questions in the video and if you liked the video, subscribe to Orhan Ergun YouTube Channel and share your thoughts in the comment section.
Note: OSPF Interview Questions in this video from basics to advanced level and studying this 65 minutes video will enhance your OSPF knowledge definitely!
The post OSPF Routing Protocol Network Engineer Interview Questions! appeared first on orhanergun.net.
In the networks, we don’t have only single protocol. There are always many protocols and their interaction/synchronization is important. Otherwise, blackholes, routing or switching loops can occur or at least suboptimal routing/forwarding can be a problem.
I explain this topic in Self Paced CCIE Enterprise Training in great detail.
In the networks, all protocols interact with each other. Whenever you add, replace or change the protocol, as a network designer you should consider the overall impact. Throughout the book many interactions will be shown and the best practices will be shown to find an optimal design.
First interaction is between layer 2 protocols and the gateway protocols. Spanning tree and the HSRP interaction is explained in the below example.
One important factor to take into account when tuning HRSP is its preemptive behavior.
Preemption causes the primary HSRP peer to re-assume the primary role when it comes back online after a failure or maintenance event.
Preemption is the desired behavior because the STP/RSTP root should be the same device as the HSRP primary for a given subnet or VLAN. If HSRP and STP/RSTP are not synchronized, the interconnection between the distribution switches can become a transit link, and traffic takes a multi- hop L2 path to its default gateway.
In the topology above, Spanning Tree root, First Hop Redundancy (HSRP, VRRP) functionality is on the same device. If there is a network services devices such as Firewall, active firewall context should be also
on the same device.
Imagine, left distribution switch (STP Root, FHRP Active) device fails in the above topology. Right distribution device become STP root and the FHRP active.
When the failed left distribution device comes back, since by default STP is preemptive, left distribution device become STP root again.
But if HSRP is used in the above topology as First Hop Redundancy Protocol, since HSRP preemption is not enabled by default, right distribution device stays as HSRP active. By the way, preemption, by default is enabled with VRRP!
When the Spanning tree root and the HSRP active functionality is on the different devices for the same Vlan, traffic has to pass through the Inter distribution link. Which mean, when the access switches send the packet, networktraffic goes through first, left distribution switch and then right distribution switch on the above topology, because the right distribution switch is the default gateway.
HSRP preemption needs to be aware of switch boot time and connectivity to the rest of the network. It is possible for HSRP neighbor relationships to form and preemption to occur before the primary switch has L3 connectivity to the core. If this happens, traffic can be dropped until full connectivity is established.
The recommended best practice is to measure the system boot time, and set the HSRP preempt delay statement to a greater than this value.
The post Be careful when you use STP and HSRP together! appeared first on orhanergun.net.
Vlan, VTP and Trunking are most fundamentals yet important topics in Layer 2 Networking.
I explain this topic from design, theory and hands-on perspective in my CCIE Enterprise Infrastructure Training.
Before using Vlan, VTP or enabling Trunk in the network, below best practices should be kept in mind.
Of course best practices may not be applicable to every network, so whichever is suitable for your network, on your networking devices, and necessary, then consider them.
broadcast propagation.
There are other Layer 2 networking topics and the best practices post on the website. I recommend you to have a look at them as well. If you want to see more Best Practice post, share your comment in the comment section below.
The post VLAN, VTP, and The Trunking Best Practices appeared first on orhanergun.net.
In Packet Exchange S2E3, I build out our script a bit more, introducing the Python print statement, string concatenation, list element references, and looping through lists using the for statement. I also explain how to reference specific dictionary items nested inside of a list. The result is a nice little report that demonstrates we have […]
The post Packet Exchange S2E3 – Automation, Python Nested Lists & Dicts, Referencing Structured Data (Video) appeared first on Packet Pushers.
Given how crazy everything is right now, it’s important to try and stay sane. And that’s harder than it sounds to be honest. Our mental health is being degraded by the day. Work stress, personal stress, and family stress are all contributing to a huge amount of problems for all of us. I can freely admit that I’m there myself. My mental state has been challenged as of late with a lot of things and I’m hoping that I’m going to pull myself out of this funk soon with the help of my wife @MrsNetwrkngnerd and some other things to make me happier.
One of the things that I wanted to share with you all today was one of the things I’ve been trying to be mindful about over the course of the last few months. It’s about appreciation. We show appreciation all the time for people. It’s nothing new, really. But I want you to think about the last time you said “thank you” to someone. Was it a simple exchange for a service? Was it just a reflex to some action? Kind of like saying “you’re welcome” afterwards? I’d be willing to bet that most of the people reading this blog post say those words more out of habit than anything else.
I decided I was going to change that. Instead of just mouthing an empty “thank you” for something, I decided to turn it into a statement of appreciation. As a father, I often tell my kids that they need to include statements in their apologies. Not just “I’m sorry” but “I’m sorry for hitting my brother”. Intent matters. In this case, the intent and appreciation is the opposite feeling.
So, instead of “thank you” I’ll say “Thank you for bringing me that cup.” Or maybe “Thank you for helping change that tire.” Calling out the explicit action that caused your thanks shows people that you’re being mindful of what they do. It means you’re paying attention and showing real gratitude instead of just being reflexive.
This can apply to technology as well. Instead of just a quick “Thanks” when someone completes a job, try making it specific. “Thanks for getting that routing loop figured out.” Or how about “Thanks for putting in the extra effort to get those phones deployed by the end of the day.” Do you see how each of these more specific statements are mindful of actions?
When you show people you appreciate them as much as what they do for you, you change the conversation. Appreciation is one of the most power gifts we can give other people. Validation and praise aren’t just meaningless platitudes. Show people you care may be the best connection they’ve had all day. Or all week. And all it takes is a little extra effort on your part. Take my word for it and try it yourself. For the next week, go the extra mile and explain why you’re thankful for people. You’d be surprised how far you’ll get.
LISP – Locator and Identity Separation Protocol is the main piece of Cisco SD-Access Solution. LISP is a control plane of SD-Access and many network engineers want to understand, and they need to understand LISP in more detail. I discussed with the inventor of LISP, Dino Farinacci!
LISP is the Control Plane protocol of Cisco SDA which is Campus Network Design and Deployment solution. It helps for automating Campus network with the help of DNA-Controller and in the framework, there are 3 planes. Control Plane , Data Plane and Management Plane.
Control Plane is LISP, which comes with different architectural nodes such as MR/MS (Map Resolver/Map Server), ITR )(Ingress Tunnel Router), ETR (Egress Tunnel Router) and PXTR (Proxy Ingress and Egress Tunnel Router).
There are many discussions on Linkedin and Twitter on why EVPN was not chosen as Control Plane for SD- Access. Let’s skip this discussion for now but let’s understand that, SDA uses different terminologies and although they do the same functions, they are not exactly LISP terminologies.
For better understanding. let me share what are the corresponding terminologies of SDA
Control Node : MR/MS
Edge Nodes: ITR and ETR
Border Node : PXTR (Proxy ITR and ETR)
In the discussion with Dino Farinacci, we discussed many basics and some advanced topics with LISP and Jeff Tantsura was my co-host in the video.
Below are some of the discussion points:
1. What are most common use cases of LISP? Which one do you see in real deployments?
2. What does LISP Control Plane and LISP Data Plane means?
3. Can you talk about LISP role in Cisco’s SD-Access?
4. Is there vendor interoperability? Can I use LISP with Cisco and other vendors in the same network? Or is it just some software implementation?
5. Can LISP replace BGP? Many people talked about this use case in the past, what do you think about it?
https://www.youtube.com/watch?v=al3ykkkltbY&t=1558s
The post Cisco SD-Access Control Plane Protocol LISP appeared first on orhanergun.net.
I discussed RPL – Routing over Low Power Lossy Networks, which is common IOT Routing Protocol with the inventor of the Protocol in detail.
If you are a network engineer, you shouldn’t only focus on traditional, general purpose routing protocols such as OSPF , IS-IS and BGP. I am usually calling them general purpose, because, you can use them on WAN, LAN and DC environment. In fact we started to see all of them in the Datacenter Networks. There is even guidance of using EBGP in Massively Scale Datacenter in RFC 7938.
But, if environment is constraint/limited to some attributes, then traditional routing protocols are not sufficient. For example, if you need to avoid battery powered links in the network, complex Traffic Engineering methods (RSVP-TE, SR-TE) need to be used together with traditional routing protocols.
RPL is one of those routing protocols which work very well on constrained environment.
If you are interested in routing protocols, BELOW video is must to watch!
Some of the discussion points in this video:
1. What is RPL, why we need it,?
2. DAG and DODAG formation?
3. RPL is a distance vector protocol., it considers the energy control as an attribute, Cisco’s EIGRP protocol is distance vector as well, why we don’t use EIGRP instead of RPL? Just because EIGRP is Cisco preparatory?
4. BGP is used for almost every service (L2, L3, Unicast , Multicast, VPNs. Security and so on) Could BGP is used in the environments where RPL is used?
5. What are the other protocols in the network we have to use to have RPL? (Is 6lowpan mandatory for RPL)?
6. What are the use cases for it in real world applications? Smart Grid , Connected vehicles ?
7. Which vendors have an implementation for it?
8. What are the competitor/alternative protocol for it?
9. Are there so many networks in the world using it?
10.Can it be used at any other place than IOT networks?
The post Most common IOT Routing Protocol RPL- Orhan Ergun and Pascal Thubert inventor of the protocol appeared first on orhanergun.net.
Service Provider Network design and deployment is one of the most mysterious parts of Networking. Usually we don’t see real life SP network design and deployment discussions.
Fast Convergence and Network Stability is required in the Service Provider Networks. Specifically it is more important in the Core/Backbone Networks, compared to other places such as Aggregation or Access Networks.
I discussed these topics with Mohamed Radwan, along with many other important considerations in the Service Provider Networks. At the end of the post, you will see the recording of our discussion. If you find this video useful, let me know in the comment section!
Below are some of the discussion topics during the session:
1. BFD and Layer 1 Failure Detection Mechanisms
2. Prefix Prioritization
3. IGP – BGP Sync
4.IGP – LDP Synch
5. LDP Session Protection
6. LSP Throttling Timers
7. Link, Node, SRLG Failure Cases and Convergence Steps
8. Next Hop Tracking and BGP Scanner
9. IBGP Minimum Route Advertisement Interval
10. EBGP Fast External Fallover
The post Fast Convergence and Network Stability Considerations in Service Provider Network appeared first on orhanergun.net.
Internet Exchange Point Design and Deployment in Real Life, this is one of the most confidential topics in networking.
Although there are 500 IXP on Internet, people definitely needs guidance, or at least want to know what others are doing. I wanted to help people who are looking for real life design and deployment practices, thus recorded a video with one of the Internet Exchange Points, Grenada IX – GREX and sharing the video in this post.
In the below video I am discussing real life IXP – Internet Exchange Point design and deployment with the peering coordinator of Grenada IX- GREX, Brent Mc Intosh.
We discussed below topics;
1. What is Peering, what is the job of Peering Coordinator
2. Private, Public Peering, Bilateral , Multilateral Peering
3. Business Model of Grenada Internet Exchange Point – What is Commercial IXP, What is Non-Profit IXP?
4. Different Peering Policies
5. Participants , 4 ISP , Couple Largest CDNS, some Enterprise etc. in Grenada IX
6.. Who pays for the transit connectivity of CDN when they join to IXP 6. Infrastructure connectivities , both Layer 2 and Layer 3 Fabric
7. How Cache-fill is provided in Grenada IX – GREX
8. How Akamai joined to GREX
9. Which CDN – Content Provider is the hardest one to bring into IXP?
10. Some best practices for IXP design and deployment
The post Real Life IXP – Internet Exchange Point Design and Deployment.- Grenada IX – GREX appeared first on orhanergun.net.
Autonomous System Provider Authorization – ASPA is a new approach for the Path Validation in BGP Information Security.
Only Path Validation Standard in IETF is BGP SEC which is specified in RFC 8205.
In this post, I won’t explain BGPSEC, but basically it works based on encrypting the entire path and useful only if there is full adoption among the Autonomous Systems in Global Internet (Default Free Zone). Main problem though, since entire path is encrypted, resource requirements on the Routers quite significant with BGPSEC. There are two new approaches for Path Validation and both are in Draft state in IETF at the moment.
These are AS-Cones and ASPA which is the purpose of this post.
I discussed ASPA (Autonomous System Provider Authorization) with the Author of the Draft, Alexander Azimov on how Internet can be made more secure with ASPA which is a new proposal.
Securing Internet is Hard Challenge,Preventing Route Leaks, Hijacks, Malicious Activities are not trivial.Current approaches such as BGPSEC or SoBGP doesn’t work. In this video, also, Origin Validation, Path Validation, SoBGP, BGPSEC, RPKI, ROA, RIR, LIR, Hijacks, Exact Prefix Hijacks, Sub Prefix Hijacks,Route Leaks and many other BGP Security features, techniques and protocols have been discussed.
It is over 2 hours but I think you will learn a lot about Inter-domain routing security. Sharing the video below!
The post Autonomous System Provider Authorization BGP Security appeared first on orhanergun.net.
Avery Pennarun continued his if only IPv6 would be less academic saga with a must-read IPv4, IPv6, and a sudden change in attitude article in which he (among other things) correctly identified IPv6 as a typical example of second-system effect:
If we were feeling snarky, we could perhaps describe IPv6 as “the String Theory of networking”: a decades-long boondoggle that attracts True Believers, gets you flamed intensely if you question the doctrine, and which is notable mainly for how much progress it has held back.
In the end, his conclusion matches what I said a decade ago: if only the designers of the original Internet wouldn’t be too stubborn to admit a networking stack needs a session layer. For more details, watch The Importance of Network Layers part of Networks Really Work webinar
Cisco Viptela SD-WAN Training. I recently added Self Paced Cisco Viptela SD-WAN training under Training on the website. You can purchase it and start studying the course right away.
This course covers all SD-WAN concepts from basic to advance level.
Not only many hours theory and design, but there are more than 12 hours Lab/Configuration in this course to demonstrate, different features in SD-WAN.
Students of this course are placed in a study group, so when they have any problem, we support them in the group. This is key for learning and I follow the same methodology in all my trainings.
It covers at the moment, Cisco Viptela SD-WAN but when the new content is available for the other vendors SD-WAN solution, students will be able to access the new content for free as well.
Starting from installing certificates on the SD-WAN Controller (VBond, VSmart, VManage), all the way cloud integration, Direct Internet Access, Dynamic Path Selection, Application Based Traffic Engineering, QoS, Forward Error Correction, Deduplication, Zero Touch Provisioning and many other topics are covered from theory and design aspects and demonstrated in a Lab environment.
Last but not least, guest designers will discuss their real life SD-WAN design and deployment with Orhan Ergun and students will be able to access any newly added discussions, labs or materials in this course for free!
You can purchase this course as a part of CCIE Enterprise Infrastructure Training as well.
As usual, Orhan Ergun offers you the best course!
· Deploying DNS/NTP/Certificate Authority Services on Windows Server
· Onboarding Controllers
· Getting Edge devices serial file from cisco (using Smart Account)
· Onboarding Edge devices (Viptela and IOS-XE devices)
· Working with feature/device templates
· Configuring NAT features on Edge devices (Overloading NAT, Port-Forwarding, Static 1:1)
· TLOC Extension configuration
Working with Centralized Control Policies:
· VPN Membership
· Hub-and-Spoke Topology
· Route Prioritization
Working with Centralized Data Policies:
· Service Insertion (Service Chaining)
· Blocking Applications
· AAR (Application Aware Routing)
· Traffic Engineering
· QoS (Policer)
· QoS (Classification/Marking) of applications
Working with Localized Control Policies:
· BGP Route-Policy Configuration
Working with Localized Data Policies:
· Defining Queues
· QoS (Classification using ACLs)
· QoS (Scheduling)
Please contact with sales@orhanergun.net for group discounts, corporate trainings and any other non-technical topics.
The post Cisco Viptela SD-WAN Training appeared first on orhanergun.net.
100+ hours CCIE Enterprise Infrastructure Training/Bootcamp. Can it happen? Yes, in fact my CCIE Enterprise Instructor Led course is over 100 hours, design , theory and lab content.
In the CCIE Enterprise training I go through not only traditional technologies such as OSPF, EIGRP , BGP , MPLS, Multicast, QoS, IPv6 etc. but also there are so many SD-WAN , SD-Access and Network Programmability and Automation content.
Probably you have seen some topologies on social media (I use LinkedIn mostly), those topologies consists of many tasks and we cover all of them in the training.
In this training, all the content of CCIE Instructor Led training is covered but as a recorded video format. Participant of Self Paced CCIE Enterprise Training gets not only videos but also Config files/Labs , workbooks, design comparison charts (don’t forget there is 3 hours design module in CCIE Enterprise exam), session materials and so on. Self Paced training students are placed in a study group together with the Instructor Led CCIE Enterprise training/bootcamp students.
In this training, I am talking live with the students. Webex or In-person based live training. Instructor Led CCIE Enterprise students get Self Paced version of the course for free. Also, all the advantages of the Self Paced training comes for free with it.
My CCIE Enterprise Bootcamp students get always additional discount when they want to join ay of my trainings. Even if training is already discounted. I call this ‘ Investment Protection‘
You can have questions, you should ask always questions, send them please to sales@orhanergun.net
Do your research very well, ask people on the Internet before you join any training, not only CCIE or CCDE but any training. Already 100s of people are in my CCIE Enterprise Study Group and you can just ask anyone on Internet about it!
Below are some of the topics in this training:
| 1.1 | Layer 2 Protocols | |||||||
| 1.2 | VLAN Technologies | |||||||
| 1.3 | EtherChannel | |||||||
| 1.4 | Spanning-Tree Protocol | |||||||
| 1.5 | Switch Administration | |||||||
| 2.0 | Layer 3 Protocols | |||||||
| 2.1 | IPv6 | |||||||
| 2.1a | IPv6 Basics | |||||||
| 2.1b | IPv6 Addressing | |||||||
| 2.1c | IPv6 Address Assingment | |||||||
| 2.1d | IPv6 Tunneling | |||||||
| 2.1e | IPv6 Packet Types | |||||||
| 2.2 | EIGRP / EIGRPv6 | |||||||
| 2.2a | Adjacency | |||||||
| 2.2b | Best Path Selection | |||||||
| 2.2c | EIGRP Load Balancing | |||||||
| 2.2d | EIGRP Optimization & Features | |||||||
| 2.3 | OSPF / OSPFv3 | |||||||
| 2.3a | Adjacency | |||||||
| 2.3b | Network Types & Area Types | |||||||
| 2.3c | Path Preference | |||||||
| 2.3d | OSPF Opmization & Features | |||||||
| 2.3e | OSPF Operations | |||||||
| 2.4 | BGP | |||||||
| 2.4a | iBGP & eBGP Relationship | |||||||
| 2.4b | BGP Path Selection | |||||||
| 2.4c | BGP Path Attributes | |||||||
| 2.4d | BGP Communities | |||||||
| 2.4e | BGP Optmizations | |||||||
| 2.4f | BGP Features | |||||||
| 2.5 | Layer 3 Features | |||||||
| 2.5a | VRF | |||||||
| 2.5b | VRF-LITE | |||||||
| 2.5c | Policy Based Routing | |||||||
| 2.5d | Biderectional Forwarding Detection | |||||||
| 3.0 | Multicast | |||||||
| 3.1 | Layer 2 Multicast | |||||||
| 3.1a | IGMPv2 and IGMPv3 | |||||||
| 3.1b | IGMP Snooping, PIM Snooping | |||||||
| 3.1c | IGMP Querier | |||||||
| 3.1d | MLD | |||||||
| 3.2 | Layer 3 Multicast | |||||||
| 3.2a | Sparse Mode | |||||||
| 3.2b | RP Configurations | |||||||
| 3.2c | Bidirectional PIM | |||||||
| 3.2d | SSM | |||||||
| 3.2e | PIMv6 Anycast RP | |||||||
| 3.2f | MSDP | |||||||
| Module 2 – Transport Technologies and Solutions | ||||||||
| 1.0 | MPLS | |||||||
| 1.1 | MPLS Basics | |||||||
| 1.2 | MPLS Operations | |||||||
| 1.3 | MPLS L3 VPN | |||||||
| 1.3a | PE-CE Routing | |||||||
| 1.3b | MP-BGP | |||||||
| 1.3c | VPNv4 / VPNv6 | |||||||
| 1.3d | VRF Route Leaking | |||||||
| 2.0 | VPN | |||||||
| 2.1 | GRE VPN | |||||||
| 2.2 | Introduction to IPSEC Protocol | |||||||
| 2.3 | GRE Over IPSEC VPN | |||||||
| 2.4 | MGRE Over IPSEC VPN | |||||||
| 2.5 | DMVPN | |||||||
| 2.5a | NHRP | |||||||
| 2.5b | DMVPN Phase 1 | |||||||
| 2.5c | DMVPN Phase 2 (EIGRP & OSPF) | |||||||
| 2.5d | DMVPN Phase 3 (EIGRP & OSPF) | |||||||
| 2.5e | DMVPN Phase 3 with Dual Hub | |||||||
| 2.5f | Troubleshooting DMVPN | |||||||
| 2.6 | IKEv2 VPN | |||||||
| 2.6a | Introduction to IKEv2 | |||||||
| 2.6b | IKEv2 Configuration with Pre-Shared Key | |||||||
| 2.7 | Flex VPN | |||||||
| 2.7a | introduction to Flex VPN | |||||||
| 2.7b | Flex VPN Configuration | |||||||
| 2.7c | MPLS Over Flex VPN | |||||||
| Module 3 – Infrastructure Security and Services | ||||||||
| 1.0 | Device Security on Cisco IOS | |||||||
| 1.1 | AAA | |||||||
| 1.2 | Control Plane Policing | |||||||
| 1.3 | Switch Security | |||||||
| 1.4 | Router Security | |||||||
| 1.5 | IPv6 Security | |||||||
| 1.6 | IEEE 802.1x Port Based Authentication | |||||||
| 2.0 | Quality of Service | |||||||
| 2.1 | Layer 3 QoS using MQC | |||||||
| 2.1a | CoS and DSCP Mapping | |||||||
| 2.1b | Classification | |||||||
| 2.1c | Marking | |||||||
| 2.1d | NBAR | |||||||
| 2.1e | Policing & Shaping | |||||||
| 2.1f | Congestion Management and Avoidance | |||||||
| 3.0 | Network Services | |||||||
| 3.1 | First Hop Redundancy Protocol | |||||||
| 3.1a | HSRP | |||||||
| 3.1b | GLBP | |||||||
| 3.1c | VRRP | |||||||
| 3.1d | IPv6 Redundancy | |||||||
| 3.2 | NTP | |||||||
| 3.3 | DHCP on Cisco IOS | |||||||
| 3.3a | DHCP Options | |||||||
| 3.3b | SLAAC/DHCPv6 | |||||||
| 3.3c | Stateful, Stateless DHCPv6 | |||||||
| 3.4 | IPv4 Network Address Translation | |||||||
| 3.4a | Static NAT/PAT | |||||||
| 3.4b | Dynamic NAT | |||||||
| 3.4c | Policy Based NAT | |||||||
| 3.4d | VRF-Aware NAT | |||||||
| 4.0 | Network Services / Operations | |||||||
| 4.1 | IP SLA | |||||||
| 4.2 | Netflow | |||||||
| 4.3 | Traffic Capture | |||||||
| 4.4 | IOS-XE Troubleshooting | |||||||
| Module 4 – Infrastructure Automation and Programmability | ||||||||
| 1.0 | Network Data Encoding Formats, Automation and Scripting | |||||||
| 1.1 | JSON | |||||||
| 1.2 | XML | |||||||
| 1.3 | EEM Applets | |||||||
| 1.4 | Guest Shell | |||||||
| 2.0 | Network Programmability | |||||||
| 2.1 | Interation with vManage API | |||||||
| 2.2 | Interation with Cisco DNA Center API | |||||||
| 2.1 | Interation with Cisco IOS XE API | |||||||
| 2.1 | Deploy and Verify model-driven telemetry | |||||||
| Module 5 – Software Defined Infrastructure | ||||||||
| 1.0 | Cisco SD-Access | |||||||
| 1.1 | Design a Cisco SD-Access | |||||||
| 1.1a | Introduction to Campus Network Fabric | |||||||
| 1.1b | Underlay and Overlay Network | |||||||
| 1.1c | Fabric Domains | |||||||
| 1.2 | Cisco SD-Access Deployment | |||||||
| 1.2a | Cisco DNA Center device discovery | |||||||
| 1.2b | Cisco DNA Center device management | |||||||
| 1.2c | Host Onboarding (Wired endpoint only) | |||||||
| 1.2d | Fabric Border Handoff | |||||||
| 1.3 | Segmentation | |||||||
| 1.3a | Macro-level Segmentation using VNs | |||||||
| 1.3b | Introduction to Cisco ISE for SD-Access | |||||||
| 1.3c | Cisco DNA Center and ISE Integration | |||||||
| 1.3d | Micro-level Segmentation using Cisco ISE | |||||||
| 1.4 | Assurance | |||||||
| 1.4a | Network and Client Health 360 | |||||||
| 1.4b | Monitoring and Troubleshooting | |||||||
| 2.0 | Cisco SD-WAN | |||||||
| 2.1 | Design a Cisco SD-WAN | |||||||
| 2.1a | Introduction to Cisco SD-WAN Solutions | |||||||
| 2.2b | Control Plane | |||||||
| 2.2c | Management Plane | |||||||
| 2.2d | Orchestration Plane | |||||||
| 2.2e | Data Plane | |||||||
| 2.2 | WAN Edge Deployment | |||||||
| 2.2a | Onbording New Edge Router | |||||||
| 2.2b | Orchestration with zero-touch provisioning | |||||||
| 2.2c | Plug-and-Play | |||||||
| 2.2d | OMP | |||||||
| 2.2e | TLOC | |||||||
| 2.3 | Configuration Templates | |||||||
| 2.4 | Localized Policies | |||||||
| 2.5 | Centralized Policies | |||||||
| Labs
|
||||||||
| Lab-1: | Switch Administration | |||||||
| Lab-2: | Spanning-Tree Protocol | |||||||
| Lab-3: | EtherChannel | |||||||
| Lab-4: | IPv6 Addressing | |||||||
| Lab-5: | IPv6 Tunneling | |||||||
| Lab-6: | Named EIGRP Configuration | |||||||
| Lab-7: | EIGRP Load Balancing | |||||||
| Lab-8: | EIGRP Optmization and Summarization | |||||||
| Lab-9: | EIGRPv6 Configuration | |||||||
| Lab-10: | OSPF Configuration Lab | |||||||
| Lab-11: | OSPF Area Types Lab | |||||||
| Lab-12: | OSPF Optmization, Features and Summarization | |||||||
| Lab-13: | OSPFv3 Configuration | |||||||
| Lab-14: | iBGP and eBGP Peering | |||||||
| Lab-15: | Weight and Local Prefrence Attribute | |||||||
| Lab16: | AS-Path and Origin Code Attribute | |||||||
| Lab-17: | MED Attribute | |||||||
| Lab-18: | BGP Route Filtering, Conditional Advertisement | |||||||
| Lab-19: | Standard and Extended Community | |||||||
| Lab-20: | Local-AS, Allowas-in, remove-private-as | |||||||
| Lab-21: | BGP Prefix Aggregation | |||||||
| Lab-22: | VRF, VRF-Lite Configuration | |||||||
| Lab-23: | BFD and Policy Based Routing | |||||||
| Lab-24: | IGMP Snooping & PIM Snooping Configuration | |||||||
| Lab-25: | MLD Configuration | |||||||
| Lab-26: | RP Confiugration (Static, Auto-RP & BSR) | |||||||
| Lab-27: | MSDP Configuration | |||||||
| Lab-27: | SSM Configuration | |||||||
| Lab-28 | PIMv6 Anycast RP | |||||||
| Lab-30: | MPLS L3 VPN Configuration | |||||||
| Lab-31: | MPLS L3 VPN with BGP RR and Allowas-in/Asoveride | |||||||
| Lab-32: | MPLS L3 VPN using VPNv6 Address Family | |||||||
| Lab-33: | MPLS L3 VPN with Extranet (VRF Route Leaking) | |||||||
| Lab-34: | GRE VPN | |||||||
| Lab-35: | GRE Over IPSEC | |||||||
| Lab-36 | MGRE Over IPSEC | |||||||
| Lab-37 | DMVPN Phase I | |||||||
| Lab-38: | DMVPN Phase II and Phase III (EIGRP) | |||||||
| Lab-39: | DMVPN Phase II and Phase III (OSPF) | |||||||
| Lab-40: | DMVPN Phase III with Dual Hub | |||||||
| Lab-41: | IKEv2 VPN with Pre-Shared Key | |||||||
| Lab-42: | Flex VPN Configuration | |||||||
| Lab-43: | MPLS Over Flex VPN | |||||||
| Lab-45: | Switch Security/Router Security/Control Plane Policing | |||||||
| Lab-46: | IPv6 ACL | |||||||
| Lab-47: | 802.1X Authentication using local database | |||||||
| Lab-48: | QoS Configuration on Cisco Router – Marking/Classifying | |||||||
| Lab-49 | NBAR | |||||||
| Lab-50 | Policing & Shaping | |||||||
| Lab-51: | HSRP | |||||||
| Lab-52 | VRRP | |||||||
| Lab-53: | GLBP | |||||||
| Lab-54: | IPv6 Redundancy | |||||||
| Lab-55: | Stateful/Stateless DHCPv6 | |||||||
| Lab-56: | Static NAT/PAT, Dynamic NAT | |||||||
| Lab-57: | Dynamic NAT, Policy Based NAT | |||||||
| Lab-58: | VRF Aware NAT | |||||||
| Lab-59: | IP SLA, Netflow, Traffic Capture | |||||||
| Lab-61: | SDA LAN Automation with PnP | |||||||
| Lab-62: | SDA Configuration Template | |||||||
| Lab-63: | SDA Identity Policy with ISE | |||||||
| Lab-64: | SDA Application Policy (Easy QoS) | |||||||
| Lab-65: | SDA Device Admin | |||||||
| Lab-66: | SDA Monitoring and Troubleshooting | |||||||
| Lab-67 | SD-WAN Secure Control Plane Bring Up | |||||||
| Lab-68 | SD-WAN Data Plane Bring Up | |||||||
| Lab-69: | SD-WAN Overlay Management Protocol (OMP) | |||||||
| Lab-70: | SD-WAN vManage Template | |||||||
| Lab-71: | SD-WAN vSmart Policies | |||||||
| Lab-72: | SD-WAN vAnalaytic | |||||||
| Lab-73: | Troubleshooting SD-WAN | |||||||
The post 100+ Hours CCIE Enterprise Infrastructure Training/Bootcamp appeared first on orhanergun.net.
BGP Convergence and ASn allocation design in Large Scale Networks covered in this post and the video at the end of the post.
This content is explained in great detail in my BGP Zero to Hero course as well as CCIE Enterprise Training.
BGP is always known as slowly converged protocol. In fact this is wrong knowledge. If you just mention about BGP Control plane convergence, can be true but we always ignore BGP Data Plane Convergence which is commonly known as BGP PIC (Prefix Independent Convergence)
In this post, I will explain the BGP Path Hunting process which slows down the convergence process. Path Hunting is not only BGP but in general distance vector protocols convergence problem.
Effect of Path Hunting gets very problematic in densely meshed topologies such as CLOS or Fat Tree.
Many Leaf and Spine switches might be in the network and when EBGP is used (As it is recommended in RFC 7938) Path Hunting should be avoided by allocation the Autonomous System number to the networking devices wisely.
Otherwise, for the prefix which is not anymore advertised to network due to failure for example, BGP speaking routers try any path which was previously learned.
I thought the best way to understand the problem space and solutions, sharing video with the Lab configuration would be best, thus I recommend you to watch below video and if you find it useful, share your comments in the comment section below.
In this video, I am explaining BGP Convergence in CLOS/Fat Tree topologies, demonstrating BGP Path Hunting problem, different BGP ASn (Autonomous System Number) allocation schemas for large scale networks with the configuration in a lab.
Also I am explaining the suggested Autonomous System allocation schema from RFC 7938 and share the different alternative ASn designs as well. If you are interested in BGP, Bellman-Ford Loop avoidance and convergence characteristics, or overall increasing routing knowledge, this video is for you!
The post BGP Convergence and ASn allocation design in Large Scale Networks appeared first on orhanergun.net.
Bill Koss reflects on state of networking
The post Closing One Door and Opening Another | SIWDT appeared first on EtherealMind.
A while ago someone pointed me to an interesting talk explaining why 99th percentile represents a pretty good approximation of user-experienced latency on a typical web page (way longer version: Understanding Latency and Application Responsiveness, also How I Learned to Stop Worrying and Love Misery)
If you prefer reading instead of watching videos, there’s also everything you know about latency is wrong.
Office Hours for mid-August.
The post Virtual Open Office Hours – Mid-August 2020 appeared first on EtherealMind.
On a previous post, I made an introduction about NVMe, NVMe-oF and RDMA for network engineers. In this post, I’m going to talk about RDMA over Converged Ethernet (RoCE) and more specifically how to implement and configure the QoS part of RoCEv2 on the Cisco Nexus 9300 series. What is RoCE? RDMA over Converged Ethernet (RoCE – pronounced “Rocky”) is a network protocol that allows Remote Direct Memory Access (RDMA) over an Ethernet network. It does this by an encapsulation of an InfiniBand transport packet over Ethernet. There are two…
The post RDMA over Converged Ethernet (RoCE) on Cisco Nexus 9300 appeared first on AboutNetworks.net.
In the past, the evolution of network-based storage was not really a problem for network engineers: the network was fast and the spinning hard drives were slow. Natural network upgrades to 10Gb, 40Gb, and 100Gb Ethernet were more than sufficient to meet the networking needs of storage systems. But now, with the introduction of ultra-fast solid-state disks (SSDs) and Non-Volatile Memory Express (NVMe), this is no longer true! Storage teams now have the ability to potentially saturate the network with incredibly fast devices. Network-based storage (SANs) using NVMe technology –…
The post NVMe, NVMe over Fabrics and RDMA for network engineers appeared first on AboutNetworks.net.
Smart use of available resources.
The post Mirai Botnet Exploit Weaponized to Attack IoT Devices via F5 Appliances appeared first on EtherealMind.
I wanted to write a “SRv6 makes no little sense” blog post for a long while, but there were always more relevant topics to focus on. Fortunately I won’t have to write it anytime soon; Ethan Banks did a fantastic job with SR(x)6 - Snake Oil Or Salvation?. Make sure you read it before attending the next “SRx6 will save the world” vendor presentation.
Derek Campbell @DevOpsDerek explains what makes DevOps work in an organization. *Trust & communication.* IT engineers are super good at both of those things, so yay. Right. Uh-huh. Anyway, go to DayTwoCloud.io and listen to episode 44 if you want to hear the rest of this chat with Derek. You can subscribe to the Packet […]
The post DevOps Is Built On Trust & Communication – Day Two Cloud Highlight appeared first on Packet Pushers.
Derek Campbell @DevOpsDerek joins the https://daytwocloud.io podcast in Episode 44 to discuss the timetable in which old school sysadmins are no longer relevant. That is, where you have to skill up or struggle to keep up. You can subscribe to the Packet Pushers’ YouTube channel for more videos as they are published. It’s a diverse […]
The post When Do Old School Admins Become Irrelevant? – Day Two Cloud Highlights (Video) appeared first on Packet Pushers.
It seems to me that point of SRv6 from a vendor perspective is to move metal and create a new platform ecosystem. Cisco and Juniper (and all of them) always need new income streams, and so they want to see SRv6 adopted. Here’s my logic.
The post SR(x)6 – Snake Oil Or Salvation? appeared first on Packet Pushers.
I’ve been in the middle of Mobility Field Day 5 this week with a great group of friends and presenters. There’s a lot to unpack. I wanted to share some quick thoughts around wireless technologies and where we’re headed with it.
There are some exciting discussions to be had in the wireless community. I’m always thrilled to be a part of Mobility Field Day and enjoy hearing all the great tech discussed. Stay tuned to the Tech Field Day Youtube Channel for all the great content and more discussions!
In Packet Exchange season 2/episode 2, we introduce structured data. Why? Because blobs are useless. Well…almost useless. What *is* structured data, anyway? Structured like a golden parachute for overpaid executives? Like the house of cards that is your fragile self-esteem? No, neither of those things! We’ll investigate using Python, where structure reveals itself as lists […]
The post Packet Exchange S2E2: Automation, News, Structured Data (Video) appeared first on Packet Pushers.
Derek Campbell @DevOpsDerek gives his opinion on home-based labs vs. cloud labs. Go to https://daytwocloud.io and listen to episode 44 for the rest of this conversation and more of Derek’s brogue. You can subscribe to the Packet Pushers’ YouTube channel for more videos as they are published. It’s a diverse a mix of content from […]
The post Do Home Labs Still Matter? Are Cloud Labs Good Enough? Day Two Cloud (Video) appeared first on Packet Pushers.
Robert Graham wrote a great article explaining why CEOs don’t care much about cybersecurity or any other non-core infrastructure (including networking, unless you happen to be working for a service provider). It’s a must-read if you want to understand the **** you have to deal with in enterprise environments.
Juniper continues to integrate Mists's AI and ML capabilities into Juniper's portfolio. This time it's the WAN, with a new service that captures streaming telemetry from SRX gateways into the Mist cloud. Juniper says Mist can spot anomalies, speed troubleshooting, and automatically remediate issues. In addition, Mist says its Marvis digital assistant can now deliver results from queries made using natural language.
The post Juniper ‘Mist-ifies’ The WAN With New Assurance Service appeared first on Packet Pushers.
I'm beginning to feel concerned for the future of an open Internet.
The post I’m Concerned for the Future of Open Internet appeared first on EtherealMind.
Aaron's Worthless Words
About Networks
BGPmon.net Blog
Brian Raaen
Bridging the gap between CCIE RS and SP
CCIE Journey
CCIE in 3 Months - Is it Possible?
Chewtoy's Technical Musings
Cioara's Cisco Blog
Ethan Banks on Technology
Evil Routers
FirstDigest
Honest Networker
IPEngineer.net
In Search of Tech
Inevitable (Himawan's blog)
Jason Edelman's Blog
Keeping It Classless
Layer 1 Transport
Loopback Mountain
Masood Ahmad Shah
Moving Packets
My CCIE Training Guide
My Etherealmind
Network Design and Architecture
Networker's Online
Networking Now (Juniper Blog)
Packet Pushers
PacketLife.net Blog
Peter's CCIE Musings and Rants
Potaroo blog
Router Jockey
Routing Freak
ShortestPathFirst
The Data Center Overlords
The Network Therapy Blog
The Networking Nerd
Vijay Gill's Blog
XKCD Comics
ipSpace.net Blog (Ivan Pepelnjak)
Last updated:
August 11, 2020 03:00 PM
All times are UTC.
Powered by:
Contact Me
