This content is password protected. To view it please enter your password below:

Password:

The post Protected: SRv6 (Segment Routing IPv6) – A simpler and more scalable network appeared first on L2X Tech.

Observability is a commonly used buzzword in the IT industry these days. Many companies use this term to sell their products and solutions to their customers. Though this idea could be a great selling point to many IT companies who are looking to modernize their infrastructure, it would be a challenge for these companies if they are unfamiliar with the true meaning of observability and how it will benefit their businesses moving forward.   

So, what is observability? How did we get here from just the simple “monitoring”? 

Observability is a distributed system’s capability to have its internal state be defined, derived, and understood based on an external source of data. This means that an observable system, such as a complex service provider network, is one that can have its status defined and understood by operators, senior management, and even customers at any given time based on the output data provided by external tools.

The more observable a network is, the quicker and more accurate one can arrive at the root cause of an existing issue.  

With monitoring, the operators gather and rely on a set of data from multiple tools and provide reactive resolution. But with observability, the tools are just components that play a part in deriving the state of a system. The key here is the operators and how they can combine the output data and proactively provide the current state of a system. 

For a complex, distributed system to be observable, these three pillars are key: logs, metrics, and traces. These three pillars are as important as the other and we cannot consider observability without one of all three. 

3 Observability Pillars

1. LOGS

Logs are timestamped records of events that happened within the network.  

Logs tell you discreetly what happened and when it happened. They provide detailed information about an event and are often presented in plaintext.  

Logs are easy to generate, and most infrastructure components can provide logs that can be gathered and stored on a server or over the cloud. They are also straightforward in terms of the information it provides. The challenge for logs as a standalone set of data is that it does not provide you the high-level visibility of the network and that due to the amount of information that is contained in each log, indexing can be quite difficult. 

2. METRICS

Metrics are the representations of various numerical data gathered from multiple components within the network.  

With metrics, operational health, and performance data can be gathered from multiple sources and could be used as key performance indicators (KPI) of a network’s behavior. These data can be presented graphically to help in the mathematical and predictive analysis of the network’s behavior. Trends can be seen just from the metrics and alerts can be set whenever certain data exceeds or goes lower than a set threshold. Furthermore, dashboards can be customized for metrics in a way that one can view the overall stats within the network, and then dive deeper into a particular data. 

Below is a sample dashboard from Accedian wherein several metrics are presented. With this, one can see the overall network health but can also navigate between other dashboards in each section to see more details of the network. For operators, this would help them in faster issue resolution. 

3. TRACES

Traces can present the complete end-to-end path of a flow as it traverses throughout the network. With traces, an operator can pinpoint where an issue is happening.  

In a complex, distributed system like that of a service provider, the ability to pinpoint where each traffic is coming from is critical to obtain valuable insight into a network. Having visibility of the entire paths of a flow is not just useful in debugging or troubleshooting, but it can also help prepare for capacity planning. 

How Can Businesses Transition To An Observable Network?

Now that we have defined what are the three pillars, how then do we make the transition of a system to becoming an observable system? Do we have to make huge changes in the infrastructure and tools? 

• First, assess what you have in your network and infrastructure. Provide an assessment of the applications and services that run within the network. What are the services and applications that run? How much is the amount of usage and traffic for each application and service? Also, consider the devices and types of traffic, and protocols that the network uses. Finally, consider the customer experience. Beyond what is happening in the backend, it’s the end customer who can provide valuable insight as to how a network is performing.

• Second, select the tools to retain and tools to add to cover the observability pillars. 

Many companies these days have multiple tools, some are open-source and others are paid with premium prices. However, not all these tools are being used or provide value. Some are just redundant and others are dormant and not even be accessed by the operations team.  

Data from tools can and should also be correlated.  

It’s difficult to provide insight if the data provided by different tools is data that is standalone and does not provide correlation with other tools.  

When selecting the tools to be used in the observability roadmap, make sure that all these tools cover the three pillars. It can be as simple as just three tools. Overall, limit the number of tools to only the important and valuable ones to avoid tool sprawl.

• The third is to organize a committee.  

A business cannot take the road toward observability singlehandedly. This is why organizing a committee is critical. This committee must consist of multiple personnel that come from various teams who represent and take the lead for each of their respective teams in the company’s road to observability.  

It is important to have insights from various groups, from the higher-level architecture team to the low-level engineering and operations team to even the change management team. These people should have a clear understanding of the concept and importance of observability as they will serve as the primary driving force.

• Lastly, integrate the tools with each other and with the entire network.  

So, the network has been assessed, the tools have been selected and the committee has been organized. This is where everything that came in the first three steps will be brought together.  

The tools selected will be installed and integrated, first with a lab environment for POC and then for the entire network. This is where the importance of the correlatability of the output data from each tool comes in. As each tool will also be integrated with the other, it is also very critical that the output data can be correlated with each of the tools themselves.  

When and where automation is possible, apply and implement it to make the entire observability stack work seamlessly. The committee will be involved and oversee the entire integration process and will also be the one to relay the knowledge of observability to their teams, not just for better understanding, but to also train and have that mindset of obtaining insight from an observable network.  

Moving from just passive monitoring to having an observable network with actionable insights may not be as easy as it sounds, especially if there is a lack of skilled personnel internally. But there is also the possibility of a third-party consultancy comprising experienced professionals in this field. This will surely give the entire company a big boost, from operations to executives up to the end users. Customer experience will be transformed for the better as the operations team will spend less time in troubleshooting and diagnosing the issue. Engineering and architecture teams will be able to proactively prevent future problems within the network. And the senior executive team will have a better, high-level understanding of the network performance. All these goods can come just because the entire network is observable. 

The post Observability: What is it and how do we get there? appeared first on L2X Tech.

The best way to get a handle on the complex and ever-changing world of network traffic patterns is through an in-depth understanding of how it all fits together.

This event will give you that level of knowledge, as well as provide insights into new ways we can use Segment Routing (SR) within our networks for greater efficiency while also improving customer experience with automation.

This event is brought to you by L2X Australia with Willy Meier, L2X’s very own solution architect with more than 15 years of experience in Service Provider Eco-system developing solutions to help SPs to simplify and automate network operations.

DATE OF MASTERCLASS

• 5th of May, Thursday, from 9AM – 12:30 PM

MASTERCLASS FEE: FREE

If you would like to join this masterclass on advanced Segment Routing topics SRTE and Flex-algo, please register by clicking the button below.    

SPECIFIC TOPICS TO BE DISCUSSED

• Segment Routing Recap
• SRTE Policies
• On-demand Nexthop
• Flex-algo Overview
• Lab and Demo
• Q&A

MORE ABOUT THE SPEAKER: WILLY MEIER

Willy Meier has more than 15 years’ of experience providing SPs with solutions to automate their network operations, simplify policies across geographies, optimise data centre use cases for ROI & sustainability as well as enhance security posture through automation of threat defence strategies at scale.

This masterclass only accepts a limited number of attendees so if you are keen to attend, please REGISTER today to ensure your slot.

If you have any questions, please reach out to jlagayan@l2x.tech for assistance.

We will see you on the 5th!

The post FREE L2X Masterclass: SR Advanced Topics SRTE and Flex-algo appeared first on L2X Tech.

This event is brought to you by L2X Australia with Luis Cesar Conesa, a highly skilled trainer and consultant who have on average more than 20 years of experience across multiple facets of technology.

DATE OF MASTERCLASS

• 24th of February, Thursday, from 9AM – 12:45 PM

FEE:

• $207 only

If you would like to join this masterclass and learn from Luis’s expert experience for only $207, please register by clicking the button below.  It’s only $207 for a knowledge worth tons in value.  

SPECIFIC TOPICS TO BE DISCUSSED

• Intro to Segment Routing
• Implementing + Configuring SR
• TI-LFA
• Migration to SR
• SR Policies
• Demo with show commands and implementation
• Q&A to close

MORE ABOUT THE SPEAKER: LUIS CESAR CONESA

Luis Cesar Conesa has more than 25 years of experience as an expert in the telecommunications networks industry.

A Senior Telecommunications Engineer, he completed his Specialist Master’s Degree in Communication Systems, as well as Doctorate courses, at the Polytechnic University of Valencia (Spain) and has been a certified Cisco instructor for 20 years. Likewise, he has extensive experience in Professional Services and Network Consulting, participating in projects of different technologies in more than 30 countries, lately in SDN, Automation and 5G.

SHORT EXECUTIVE KEYNOTE FROM ACCEDIAN CTO: CHIA TAN

Chia Tan, the Chief Technologist & Director of Solutions Engineering at Accedian (APAC Region) and former CTO at Cisco Systems looking after service providers also all over APAC, will share a short executive keynote with his vision regarding the future of transport networks and trends for service providers.

This masterclass only accepts a limited number of attendees so if you are keen to attend, please REGISTER today to ensure your slot.

If you have any questions, please reach out to jlagayan@l2x.tech for assistance.

We will see you on the 24th!

The post L2X Masterclass: Segment Routing Essentials appeared first on L2X Tech.

In the first blog of this series, we covered the Segment Routing Problem definition, Drivers, use cases,  and the benefits it brings to the table. (for more details refer to this article). This post we will explain Segment Routing Building Blocks, without further ado let’s start with SR SID.

Lab Setup

The Network Setup that we will use in this series is shown below:

• It includes Cisco and Juniper virtual routers.
• Below devices forms an MPLS network with (3 Core + 4 Provider Edge routers).
• Segment Routing is used and preferred over LDP.

One of the key properties of SR is that MPLS labels are distributed via the Interior Gateway Protocol (IGP), ISIS or OSPF, rather than a dedicated label distribution protocol. Another benefit is the concept of Source Routing that implies encoding the path a packet traverse by means of a stack of headers applied to the packet when launching it into the network. These headers/labels what we call SID “Segment ID” in the SR world.

Node Segments

Allow us to ask you this question;  What is the range of label blocks reserved for SR in Cisco IOS-XR, and Juniper JunOS ?

• IOS-XR –> 16000 till 23900
• JunOS –> By default no reserved block

Node SID is a special type of Prefix-SID. Each node in the network has a node segment associated with its loopback address. (however, it can have multiple prefix segments).

Any other node in the network can send packets to it along the shortest IGP path by using that node segment.

The routers in the network use the following two parameters in order for each node in the network to build the Node segment for each node in the network

1. Node index: Each router must have a unique node index. This is also known as a Node-SID
2. Label Stack: This is defined in terms of a start-label and a label-range. The label range must be wide enough to accommodate all of the routers in the domain (including anticipated future growth). This label range is known as the segment routing global block (SRGB).

Below is the basic configuration to enable SR on IOS-XR devices and specify the Node-SID using the index

router isis 100

net 49.0000.0000.0001.00

address-family ipv4 unicast

metric-style wide

segment-routing mpls

!

interface Loopback0

passive

address-family ipv4 unicast

prefix-sid index 1

!

!

Below is the basic configuration to enable SR on JunOS devices and specify the Node-SID using the index

isis {

source-packet-routing {

node-segment ipv4-index 402;

}

level 2 wide-metrics-only;

level 1 disable;

}

With the above configuration, we can observe the Node-SID advertised in the ISIS database as shown below

LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime/Rcvd  ATT/P/OL

XR-P01.00-00        * 0x00000009   0xfab6        697  /*            0/0/0

Area Address:   49

NLPID:          0xcc

IP Address:     10.100.1.1

Metric: 0          IP-Extended 10.100.1.1/32

Prefix-SID Index: 1, Algorithm:0, R:0 N:1 P:0 E:0 V:0 L:0

Prefix Attribute Flags: X:0 R:0 N:1

Hostname:       XR-P01

Router Cap:     10.100.1.1, D:0, S:0

Segment Routing: I:1 V:0, SRGB Base: 16000 Range: 8000

In IOS-XR by default, the OS reserves a label block from 16000 with a range of 8000 to be allocated for SR global block for Node segments.

For Juniper devices, we can see the Node-SID and the SRGB block as shown below

LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime/Rcvd  ATT/P/OL

MX-P02.00-00          0x00000026   0xc871        899  /1198         0/0/0

Area Address:   49

Hostname:       MX-P02

Router Cap:     10.100.1.2, D:0, S:0

Segment Routing: I:1 V:1, SRGB Base: 12560 Range: 4096

SR Algorithm:

Algorithm: 0

Prefix-SID Index: 402, Algorithm:0, R:0 N:1 P:0 E:0 V:0 L:0

In Juniper by default, there is no default label block allocated for SR and the system computes a block for SR in case an SRGB block is not statically configured.

With the above basic configuration, each router calculates the label to reach a specific node using the following formula:

Node Segment to reach PeerX = SRGB advertised by downstream peer + Node-index advertised for PeerX

Node Segment Calculated for PeerX = SRGB for local router + Node-index advertised for PeerX

So we can see that the following is the MPLS forwarding table for XR-P01 to reach MX-PE01

RP/0/RP0/CPU0:XR-P01#sh mpls  forwarding

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

16004  Pop         SR Pfx (idx 4)     Gi0/0/0/2    172.20.1.6      2156

16402  Pop         SR Pfx (idx 402)   Gi0/0/0/0    172.20.1.1      3224

16403  Pop         SR Pfx (idx 403)   Gi0/0/0/1    172.20.1.3      731

16406  12966       SR Pfx (idx 406)   Gi0/0/0/0    172.20.1.1      198

4774        SR Pfx (idx 406)   Gi0/0/0/1    172.20.1.3      733

The below diagram outlines the calculation

We can see that the label assigned for each node across the network is not consistent and it is very similar to LDP. Thus the recommended approach is to unify the SRGB on all devices in order to have a consistent calculation for the Node Segment across the network

Below is the configuration required on IOS-XR devices

segment-routing

global-block 400000 400999

Below is the configuration required on JunOS devices

isis {

source-packet-routing {

srgb start-label 400000 index-range 1000;

node-segment ipv4-index 403;

}

}

We can verify that the Node-Segment assigned to all the devices is consistent as shown below from XR-P01 output

RP/0/RP0/CPU0:XR-P01#sh mpls  forwarding

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

400402 Pop         SR Pfx (idx 402)   Gi0/0/0/0    172.20.1.1      474

400403 Pop         SR Pfx (idx 403)   Gi0/0/0/1    172.20.1.3      474

400406 400406      SR Pfx (idx 406)   Gi0/0/0/0    172.20.1.1      0

400406      SR Pfx (idx 406)   Gi0/0/0/1    172.20.1.3      297

400407 400407      SR Pfx (idx 407)   Gi0/0/0/0    172.20.1.1      217

400407      SR Pfx (idx 407)   Gi0/0/0/1    172.20.1.3      0

The below is the output from Juniper MX-PE03 node that outlines the Node-SID

MX-PE03# run show route table inet.3

inet.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

10.100.1.1/32      *[L-ISIS/14] 00:03:43, metric 2000

to 172.20.1.15 via ge-0/0/0.0, Push 400001

> to 172.20.1.17 via ge-0/0/1.0, Push 400001

10.100.1.2/32      *[L-ISIS/14] 02:13:37, metric 1000

> to 172.20.1.15 via ge-0/0/0.0

10.100.1.3/32      *[L-ISIS/14] 00:52:20, metric 1000

> to 172.20.1.17 via ge-0/0/1.0

10.100.1.4/32      *[L-ISIS/14] 00:27:56, metric 2000

> to 172.20.1.17 via ge-0/0/1.0, Push 400004

10.100.1.7/32      *[L-ISIS/14] 00:11:38, metric 2000

to 172.20.1.15 via ge-0/0/0.0, Push 400407

> to 172.20.1.17 via ge-0/0/1.0, Push 400407

The below diagram outlines the Node-SID in the network

Let’s conclude this article by listing the advantages of Using Node Segments Instead of LDP:

1. You have already seen the first advantage – the fact that when configuring the same SRGB on each router, the label required to reach a given router is the same throughout the network, rather than changing hop-by-hop as in the LDP case.
2. the second advantage is having fewer protocols to configure and monitor. LDP can be removed from the network.
3. The path can be treated as direction instead of hop-by-hop, when you point to 40406 all routers in the middle will freely independently decide how to reach it.

The post Segment Routing Building Blocks part 1 appeared first on L2X Tech.

Can you list the different ways we can use to route traffic from point A to point B in the network?

Some of the following methods may come to your mind first: hop-by-hop routing (with its flavours such as BGP hot-potato routing, and cold potato routing, and Strict routing using IP packet header long time ago with a very limited handful of hops, not widely used of supported by routers vendors).

The below figure shows hop-by-hop routing and how each router in the path makes his own decisions based on his view of the network, and the best way to reach the destination. which sometimes doesn’t match with the desirable path from the source/application perspective.

A more advanced ways include using Traffic Engineering, Tunneling, and Path Computation Engine, which lead to better control routing, and steering traffic as per the defined constraints. These are some examples of how can use to route traffic from point A to point B the list continues to grow. (I would cover new techniques such as IBN “Intent-based routing”, and Network Slicing in future posts)

So why do we need another way, why people start thinking about Segment Routing?

In this series of article, we will take you in Journey to discover Segment routing, in this first post I will cover Problem definition, Drivers, use cases, Segment Routing overview, and the Benefits of using it.

So let’s kick in

Problem definition

Let’s start with problem definition, which was addressed in IETF SPRING workgroup (part of a network workgroup). SPRING stands for Source Packet RoutING.

Do we still use something like route by rumor (used in RIP)? Or,  are we getting more clever and consider all the aspects about our path; taking Traffic as analogy what is the road speed limit, how many lanes, does the road has an emergency lane, number of light signals, accidents history/record, and road quality.

All of which can be translated into Network terms such as link bandwidth, congestions, delay, link. Attributes, access technology, and, link reliability.

What about letting the source decide the best path for him, but does he knows this best path, how can he decide, does he need feedback from the network

What are the problems with hop-by-hop routing: is the only problem that it is old? Not really. But it is like distributed programming, totally independent, no reference point or source of truth each device chooses the path from his point of view.

Another important point is the huge expansion in Network Bandwidth, which Doubles Every 18 Months, while the number of  Device Doubles Every 24 Months (source Cisco segment routing Tech Talk).

Last but not least the limitations on current network/routing methods:

• Doesn’t support multiple ways to construct forwarding path other than the shortest path
• Complexity caused by managing and operating multiple protocols (such as OSPF/ISIS as IGP, BGP, MPLS LDP, RSVP, …and so on) and how they interact with each other.

• Scalability issue with increase in network state, especially with RSVP-TE.
• Demolishing Revenue/Cost ratio.

 Drivers

After understating the problem statement for Segment Routing, this leads to the drivers behind this new methodology:

An idea to get the best of the two worlds: source routing + distributed routing

Choose the best path based on the user’s requirements + minimize the number of states in the network;

Another driver is allowing applications to choose their path, so SR can be an enabler for SDN, and 5G CUPS in the mobile world.

Take into consideration that term “Source” is not limited to packet originator, it can be any device handles the packet & path decision (e.g. carrier ingress PE)

Last but not least, it is an approach to simplify and reduce the number of control protocols involved in routing the data across the network.

Use Cases

Many use cases can benefit from Segment Routing, to mention a few:

1. network virtualization and support multi-topology routing within the network so each application can choose the path that matches its requirements, voice traffic main requirement is less delay, other data application cares more about bandwidth and bigger pipes.
2. This also leads to the partitioning of network resources per VPN, or customer.
3. Node, link, and path protection such as fast re-route, meeting the same SLA as MPLS-TE (less than 50 msec) in coordination with TI-LFA (Topology Independent – Loop-Free Alternative).
4. Network programmability.
5. Simplification and reduction of network signaling components.
6. Load balancing and traffic engineering.

Segment Routing overview

Before diving through SR, allow me to give an example from aviation, and cargo system in the airport.

If you are traveling from the USA to Germany via two-stops transit in Mexico and Spain. The airport in the USA as a source define the exact path which your bags must take. This assures that your baggage will follow you on the same path.

Source airport got benefits that the “Tag” used are globally significant and recognized in all airports worldwide, this process doesn’t require to keep state about each bag through the path (for routing purpose). All we need in each hop to check the “Top Tag” and route the bag based on it. As per below diagram.

Same happens in Segment Routing, each router has a Global Segment for itself in addition to other segments for links, and other instructions (to discuss in later posts). This global range is defined as SR Global Block (SRGB).

Another similarity to baggage example is: routers in the path doesn’t keep a state per flow, nor per application. This makes Segment routing the right balance between distributed intelligence, centralized optimization, and application-based policy creation

Segment Routing utilizes the existing routing protocol (e.g. OSPF, and ISIS with some extensions to support  SR)

as the control plane, and uses MPLS or IPv6 as data plane (details in an upcoming post of this series).

This eliminates the need for LDP, also RSVP-TE can be replaced with “TI-LFA” which is part of IGP protocol.

Consider segments similar to MPLS Labels with different treatment and global scope in case of Prefix-SID (SID = Segment ID), where the source encodes the path in the packet header as an ordered list of segments.

Benefits of using Segment Routing

As we discussed in the previous section, I believe you already realized many benefits associated with segment routing. To mention a few of these benefits:

• The right balance between source routing and existing routing protocols distribution decisions.
• Ease of management via eliminating some control protocols such as LDP, and RSVP-TE.
• Enablement for Network Programmability and SDN.
• Supports Network Service Chaining
• Supports Fast-reroute, load-sharing, and protection.

What’s Next

This concludes this post, in the next post we will cover Segment Routing Building Blocks, SR and OSPF, SR and ISIS, and SR and BGP.

Read the Segment Routing Building Blocks here >>

The post Segment Routing Overview & Drivers appeared first on L2X Tech.

What is a load balancer? Where does it come from? What is it used for? When we hear this phrase, “load balancer”, many ideas can come to mind. We can imagine the load balancing of a ship so that it does not tip over, or we can balance the load in a truck trailer so that it is well stabilized when traveling on the road. But in the digital world, what does it mean? –Caio Soares

Before going into this explanation, we first have to understand some simple concepts to abstract.

Server, what is a server? Let’s start there! Do you know your home computer? Or maybe from your work? I’m not talking about a laptop or tablet. I’m talking about the desktop computer, the one with a monitor, mouse, and keyboard, remember? Is there one near you? Well, the server is very similar to this guy, some differences between them are that while you use your computer to have fun or work, you do it and then turn it off, correct? The server does not. The server is connected 24 hours a day, 7 days a week, 365 days a year. Then you wonder, connected to what? Everything on the internet is inside a server. Are you seeing the news on the Daily Telegraph website? You are connected to a server. Are you chatting with someone on WhatsApp? You are connected to a server. Are you on Facebook? Google? Instagram? Anything else that depends on the internet? You can be sure that you are connected to a server. It is on the server that everything happens, that the information is processed and presented to you, the user. That’s why a server never shuts down, it has to always be online, always ready to serve you whenever you need it.

And do you know how much it costs? There may be servers ranging from a few hundred dollars to a few hundred thousand dollars. Manufacturers? F5, Cisco, HP, IBM, Dell, and others. 

Okay, with that in mind, let’s get to our goal of this article, but before that, I have to explain one last concept, cluster! 

A cluster is nothing less than a set of servers that have the same information. Let’s assume that we have ten servers running next to each other and someone records a photo on one of these ten servers. The moment the photo is saved, that photo is automatically transferred to the other servers and that’s it! This is the basic concept of a cluster. A cluster goes much further than that, but we will stop here.

Okay, now we’re ready. Load balancer! What do we use it for? Let’s imagine the Facebook servers, how many should there be? 100? 200? 1000? 2000? Anyway, we do not have this exact number, but we are sure that there must be thousands of servers that keep Facebook on air 24 hours a day, and of course, all in clusters.

Now imagine the number of people who access Facebook per minute. We know that today there are around 2.6 billion active accounts worldwide. People posting and enjoying information, photos, videos all the time. That’s where our load balancer comes in, but first, let’s imagine that the balancer doesn’t exist. Imagine that there are 10,000 people accessing Facebook simultaneously, without the load balancer. There is a risk that these 10,000 people will connect to only one server since there is no device that distributes to all servers that are clustered, so this is the role of the load balancer. It receives all the connections from people who access Facebook and distributes them among servers that are clustered. This is the basic function of the load balancer.

Among the load balancers that exist on the market, we can mention the F5 Big IP, Netscaler, Citrix among others.

Of all these, we can highlight the F5 Big IP, manufactured by F5 Networks. This system has been on the market for almost 20 years and stands out from other manufacturers. Why? Reliability! In addition to other features that this system brings, which goes far beyond load balancing, its hardware has a high processing capacity allowing it to receive a large number of simultaneous connections, and also stands out for its redundancy features for its not suddenly stop. Companies in the banking, insurance, credit card, public services, news, airlines, and many other companies use Big IP for their most important services such as ATMs, internet banking, websites, user services, and others. Add telecommunications?

With Big IP operating on the computing infrastructure, the company that owns it will have greater reliability on its network. This is because this system will distribute demand among your servers resulting in better use of your network. It also provides better information distribution among your resources and greater security of your data, since the servers will not be connected directly to the internet.

Big IP is among its competitors the best option for confident load balancing, performance, and security.

The post What is a load balancer? appeared first on L2X Tech.