BGP (I)

Quick summary about the Border Gateway Protocol (BGP). Today’s most relevant protocol for Overlay in Data Center as well as becoming more popular for underlay too. And the Internet’s protocol, so important in WAN communications.

Two flavours, iBGP and eBGP, this last being used in both the Internet and in the DC, and iBGP only within the same organization as it uses the same Autonomous System. Public AS typically belong to ISP’s or other large organizations (range from 1 to 64511). Private AS (numbers range from 64512 to 65535) can be used inside the organizations.

Due to its inter-domain features and its scalability, BGP is used in the Internet to inter-connect domains, something that IGPs cannot.

Inside the same organizations, there are also considerations to take into account to choose BGP instead of IGP, if compared to OSPF, we can mention the following as an example:

-OSPF follows a hierarchical structure, while BGP would be usually adopting a mesh structure.

– OSPF requires a more intensive use of memory and CPU resources, this is a problem as we scale up. It is exchanging packages frequently and it has the whole picture of the area components, plus other area’s routing information.

-OSPF focuses on determining the fastest route whereas BGP installs the best path.

OSPF is a good fit in enterprise/campus networks as well as in some Data Centers as the underlay protocol, and BGP it is used where scalability could be an issue and due to its powerful prefix manipulation and flexibility.

BGP runs on top of TCP as its transport protocol and operates on port 179.

BGP uses four different message types: OPEN, UPDATE, KEEPALIVE and NOTIFICATION.

The BGP header is as follows:

where the Marker contains an authentication value that the message receiver can predict.

the Length indicates the total length of the message in bytes.

Type indicates what kind of message is it from the four types.

and Data, which contains upper-layer information in this optional field.

BGP has two phases for session establishment between two speakers:

1. TCP connection establishment phase
2. BGP session establishment phase

BGP uses a finite state machine (FSM) to keep track of the session, during the first phase, TCP establishment, the FSM goes through the following states:

Idle
Connect
Active

once the TCP messages are exchanged and TCP connection is established to deliver BGP packages, the next FSM states are:

Opensent
Openconfirm
Established

In the first two states BGP attributes are exchange between the speakers. and the established state means that the peer is in a stable state and can accept routing updates.

in the Opensent state, the BGP speaker has sent an OPEN message to its peer and is waiting for the Peer to send its own OPEN message. Once this occurs, the state transitions to Openconfirm state where the speakers compare their attributes in the peer’s OPEN message to that of its own. If it is acceptable the speaker respondes with a Keepalive packet and the state changes to Established, after this, UPDATE messages are sent to exchange routing information.

In the OPEN message there are six main attributes:

version of the BGP supported by the router
The router’s Autonomous System Number
The router’s hold timer
The router’s BGP identifier
The optional parameters the router supports

Single-hop vs Multihop

Single-hop sessions are created when two speakers are located in a single physical or logical router hop away. This allows you to peer with the neighbor within the same subnet only. If it needs to peer with an IP located on another interface, such as the loopback, then we need a mechanism to avoid this limitation (as the TTL is set to 1 by default in ebgp) such as the ebgp multihop option, which would be changed to 2 (change the TTL to 2) for example if the loopback is located in the neighbor’s router.

Why would I use as the peer IP the loopback instead of the direct connected interface? Redundancy purposes, your session remains connected if there’s other path between the routers, and we avoid having duplicated information in case we had two sessions established between routers, which is a waste of resources and our configuration gets more complex.

neighbor x.x.x.x update-source [interface] is an important command in this cases, as if we establish the peering against the loopback, the packets will be sent from the outgoing interface which is the ethernet connecting to the router, and it will be discarded as the peering is established against the loopback. therefore using this command will solve this situation. This is relevant during the TCP session establishment only though, meaning that as both speakers act as client and server in the TCP session, if we configure it the command only in one of the speakers rather than in both, it will work as well, as one of the sessions will be accepted and the other dropped as it would expect a different source.

reference:
https://packetpushers.net/demystifying-bgp-session-establishments/
http://resources.intenseschool.com/bgp-message-types/

Network Automation and its levels

I started my post by going through a description of the network automation meaning, and I realised that Internet is plenty of posts with the exact same information. You can do a search at Google and will find many different sources, therefore I thought that it is pointless to go through all that again. Instead, I will just highlight what I think we, as network engineers, should take into account before automating anything at work and what my opinion is about whether we would need to code or not.

As network engineers I believe that the more you learn about coding these days the better chances you will have to get a good job. Yes, there are plenty of companies out there that are not implementing any sort of automation, which is great for those falling behind, but as time passes company trends to change and it will be more valuable someone who can automate tasks rather than someone doing all manual. Having said this, I also think that not everyone need scripting/coding skills, many automation tools are easy enough so you don’t need to have deep coding skills.

If you are willing to explore network automation, here are some points that I believe are important to take into account:

1 – first point and one of the most important ones from my point of view, be business oriented. We have networks because of businesses, and their services are what matter the most, what it gives revenue. Infrastructure is there to support it, as business and applications evolve so do the technology to help them: more powerful switches, routers, firewalls, bigger data centers, intelligence WAN, etc. if a switch is down “it doesn’t” matter as long as our service is well protected by implementing the required mechanisms.

2- See what tasks you repeat more often, focus on them to implement your first automation pieces. Perhaps you want to avoid building a script for a 1 line command that you do every 2 months, but if you implement firewalls rules, create VLANs, routing changes etc, you may consider it.

3 – Keep it simple. The bigger your code is and the more tools you use the more complicated the troubleshooting will be, and this is precisely what we were trying to avoid. Keep away from having a thousand different tools and/or data sources.

In regards to the level of automation, I haven’t found an agreed description of them, depending on the source you will find one level or another. As an overview and as of April 2020, we can describe the following levels:

  • Level 0: No Automation at all. Manual configuration.
  • Level 1: Scripted. Scripts are made by individuals for individuals. Trigger based.
  • Level 2: Tooled. The automation task is made available to others. Rule based.
  • Level 3: Orchestrated. Orchestration organizes and leverages a library of scripts to complete more complex workflows.
  • Level 4: Auto-triggered. Asynchronous Autonomous operation via Virtual workforce. Automation as a Code.
  • Level 5: Assisted. Virtual assistant. Remote control Interact with the Virtual workforce via GUI or CLI. Synchronous.
  • Level 6: Intelligent Automation (Contextual). Machine Learning /System behavior and stats. // Artificial Intelligence (Self-Aware). Learn and adapt in order to act as a human.

Depending on the automation type and vendor the above clasification can vary. For example, in Intent-Based Networking (IBN) solutions, we could talk about 3 different levels: Level 0, which implies a basic automation; level 1, where we define our single source of truth; level 2, with real-time and change validation, and level 3, where the network is self-operated.

I will go in depth through some of these levels to see what tools are today in the market and what could we use in our network.

source https://www.onug.net/blog/autonomous-networks-not-network-automation/