Tuesday, December 5, 2023

BGP: IPv6 Only example between OpenBGPD and FRR

FRR:

show run

frr# sh run 

Building configuration...


Current configuration:

!

frr version 8.1

frr defaults traditional

hostname frr

log syslog informational

service integrated-vtysh-config

!

interface l0

 ipv6 address 2001:db8::1/128

exit

!

router bgp 65001

 bgp router-id 1.1.1.1

 no bgp ebgp-requires-policy

 neighbor 2001:db8:12::2 remote-as 65002

 !

 address-family ipv6 unicast

  redistribute connected

  neighbor 2001:db8:12::2 activate

  neighbor 2001:db8:12::2 soft-reconfiguration inbound

 exit-address-family

exit

!



OpenBGPD

Archivo: /etc/bgpd.conf

# macros

ASN="65002"

fib-update yes

log updates


# global configuration

AS $ASN

router-id 2.2.2.2


network 2001:db8::2/128

network inet6 connected


neighbor 2001:db8:12::1 {

    descr "epa"

    remote-as 65001

    announce IPv6 unicast

}


deny from any

deny to any

allow from 2001:db8:12::1

allow to 2001:db8:12::1


#

(please note the blank space between the last line and the second to last line)

Monday, December 4, 2023

How to create an IPv6 route to null/blackhole in Linux

 Case:

    How to create an IPv6 route to null/blackhole in Linux

Command:

   ip -6 route add blackhole fd00:12:34::0/48




I hope it is useful

Sunday, October 29, 2023

How to temporarily disable IPv4 on an interface within Linux

Case:

   We want to disable IPv4 on an interface


Solution:

   sudo ip -4 addr flush dev enp0s1


Explanation:

   The above command removes all IPv4 addresses for interface enp0s1. Important, remember that this disabling is only temporary.

Friday, October 13, 2023

How to uninstall brew in MAC

How to uninstall brew in MAC

  Option 1: 

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"

 Option 2: 
NONINTERACTIVE=1 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"


Tomado de: https://github.com/homebrew/install#uninstall-homebrew


NGINX Reverse Proxy for an IPv6-Only Server Farm

Introduction

This work presents a very simple way to offer dual-stack web access to an IPv6-only server farm using NGINX. The continued growth of the Internet and the gradual adoption of the IPv6 protocol means that it is essential to ensure connectivity and accessibility for clients using both IPv4 and IPv6. We will explain how to configure NGINX to support dual-stack web access, we will address how to configure NGINX as a reverse proxy that listens on both IPv4 and IPv6 addresses, as well as how to correctly route incoming requests to backend servers with only IPv6 addresses. By the way, among many other benefits, what we will discuss in the following article is an important step towards the preservation of IPv4 addresses.



What is a Reverse Proxy?

In [1], Cloudflare defines a Reverse Proxy Server as follows: “A reverse proxy is a server that sits in front of web servers and forwards client (e.g. web browser) requests to those web servers. Reverse proxies are typically implemented to help increase security, performance, and reliability. In order to better understand how a reverse proxy works and the benefits it can provide, let’s first define what a proxy server is.”


What is a Proxy Server

In [1], Cloudflare also provides the following definition for a proxy server: “A forward proxy, often called a proxy, proxy server, or web proxy, is a server that sits in front of a group of client machines. When those computers make requests to sites and services on the Internet, the proxy server intercepts those requests and then communicates with web servers on behalf of those clients, like a middleman.”



What are the benefits of a Reverse Proxy?

  • • A reverse proxy can offer IPv4 or transparent IPv6 to clients serviced from an IPv6- only server farm (which is what we will focus on). • Scalability: The use of a reverse proxy allows adding or removing backend servers as needed without affecting end users. This makes it easier for applications to scale out, allowing them to handle a larger number of concurrent users and requests. • Static content caching: NGINX can cache static content such as images, CSS files, and JavaScript, thus reducing the load on backend servers and increasing content delivery speed. This decreases page load times and the required bandwidth. • Security: NGINX acts as a point of entry to the application, providing an additional layer of security. It can perform functions such as request filtering, DDoS attack prevention, SQL injection protection, and client authentication. NGINX can also enable the use of SSL/TLS encryption for communication between clients and the backend server. • Advanced routing: A reverse proxy allows performing advanced routing based on various criteria, such as domain name, URL, or HTTP headers. This is useful when we need to direct traffic to different backend servers based on the specific attributes of the requests. • Consolidation of services: NGINX can act as a single point of entry for various backend services. This simplifies the infrastructure by consolidating multiple services on a single server, thus simplifying management and maintenance. • Enhanced performance: NGINX is lightweight and resource efficient by design. Its streamlined architecture and ability to handle large numbers of concurrent connections make it a popular choice for improving web app performance. • Load balancing: A reverse proxy such as NGINX can distribute incoming traffic across several backend servers. This helps balance the load and guarantees that no server is overloaded, which improves an application's performance and responsiveness.



Topology


What is our Goal Today?

The edge server (Reverse Proxy Server) will be able to receive IPv4 and IPv6 HTTP requests, and depending on the website a user wishes to visit (domain), will forward the request to the right server. This is what will happen in our example: 

The client visits: The request is sent to: 

server-a.com → 2001:db8:123::1 

server-b.com → 2001:db8:123::2 

server-c.com → 2001:db8:123::3 

server-a.com → 2001:db8:123::101 

server-b.com → 2001:db8:123::102 

server-c.com → 2001:db8:123::103



Requirements

  • • Linux with NGINX on the Reverse Proxy Server • Super user access • Web server on each of the servers in the farm • IPv4 and IPv6 Internet connectivity • Internal IPv6 connectivity


Let's get started


Let's get started 

1) Install NGINX in all servers #apt update #apt install nginx 

2) Create the websites in the NGINX reverse proxy 

File /etc/nginx/sites-available/server-a.com 

server { listen 80; listen [::]:80; 

  server_name server-a.com; 

  location / { 

  proxy_pass http://[2001:db8:123::101]; } 


File /etc/nginx/sites-available/server-b.com


server { listen 80; listen [::]:80; server_name server-b.com; location / { proxy_pass http://[2001:db8:123::102]; } }



Archivo  /etc/nginx/sites-available/server-b.com

server {

listen 80;

listen [::]:80;


    server_name server-b.com;

    location / {

        proxy_pass http://[2001:db8:123::102];

    }


}



File /etc/nginx/sites-available/server-c.com 
server { 
  listen 80; listen [::]:80; 
  server_name server-c.com; 
  location / { 
  proxy_pass http://[2001:db8:123::103]; 
  }
}

3) Create symbolic links to enable the sites configured above:


root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sitesavailable/server-a.com /etc/nginx/sites-enabled/server-a.com 


root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sitesavailable/server-b.com /etc/nginx/sites-enabled/server-b.com 


root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sitesavailable/server-c.com /etc/nginx/sites-enabled/server-c.com



4) Remember to restart NGINX

$sudo systemctl restart nginx



About the logs

Logs are extremely important for any company or ISP that wishes to review incoming connections. 

By default, NGINX will use its own IP address for outgoing connections, which results in the loss of the address of the client that originated the HTTP request. But don't worry. NGINX has the solution: proxy_set_header. This requires configuring both the end server and the Reverse Proxy server. 

1) On the Reverse Proxy Server, we must configure the website assets. 
# Example of nginx reverse proxy that allows logging the client's 
# original address and port number 

location /examples { 
   proxy_pass http://[2001:db8:123::103]; 
   proxy_buffering off; 
   proxy_set_header X-Real-IP $remote_addr; 
   proxy_set_header X-Forwarded-Host $host; 
   proxy_set_header X-Forwarded-Port $server_port; 
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
 } 

2) On the end server, add the following in the http section of the /etc/nginx/nginx.conf file:

set_real_ip_from 2001:db8:123::100; #replace the IP address with that of the proxy 
real_ip_header X-Forwarded-For; 
real_ip_recursive on; 

Example: 
http { 
   … 
   set_real_ip_from 2001:db8:123::100; 
   real_ip_header X-Forwarded-For; real_ip_recursive on; 
   … 
  } 

With these settings, the receiving server will trust the X-Forwarded-For header set to 2001:db8:123::100 and will log the client's source IP to /var/log/nginx/access.log.



Summary

The proposed design allows managing a 100% IPv6-only web server farm with access to both the IPv4 and the IPv6 worlds in a very simple, scalable, and efficient manner. This results in various benefits, including having to manage only one TCP/IP stack, simplicity, security, and even saving IPv4 addresses.


References


    • [1] https://www.cloudflare.com/es-es/learning/cdn/glossary/reverse-proxy/ • https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-areverse-proxy-on-ubuntu-22-04 
    • GitHub. LACNIC Blog Post Help Files for the entire project: https://github.com/LACNIC/BlogPostHelpFiles/tree/main/2023_Ofreciendo_conectivid ad_Dual_Stack_a_servidores_Web_en_una_granja_de_servidores_100_IPv6_Only

    Thursday, July 6, 2023

    Google returns: 403. That's an error. Your client does not have permission to get URL / from this server. That's all we know.

     Introduction:

       You want to do a google search and the page returns: "403. That’s an error.

       Your client does not have permission to get URL / from this server. That's all we know."







    In my case I was using an IPv6 tunnel with Hurricane Electric, specifically the /64 that they deliver in the tunnels.


    Solution?

        Ask Hurricane Electric at the portal for a /48 routed. That's it! Then I removed the old /64 prefix from the router's SLAAC, leaving only a /64 belonging to the /48.


    Good luck!

    Thursday, May 25, 2023

    Strange ssh behavior on MAC - Copy/Paste Issues

     Situation:

       Strange behavior of SSH on MAC, problems with copy/paste in terminal during ssh. Does the clipboard work in other applications?


    Solution:

       At least in "vi" the solution is very simple. Edit the file: ~/.vimrc and paste the following content:


    if !has("gui_running")

       set mouse=

    endif


    Luck!

    Thursday, March 16, 2023

    A Look at LACNIC’s IPv6-Only Members

    Introduction

    This paper seeks to analyze the announcement and status of the prefixes held by organizations known as IPv6-only LACNIC members. These are organizations that have received IPv6 prefixes, that may or may not have received an autonomous system (ASN), and that have not been assigned an IPv4 prefix by LACNIC. The results of this analysis will help us improve our understanding of the uses and needs of our members across the region.


    Information sources used in this analysis

    The source of information used in this analysis was LACNIC whois, with data obtained throughout the month of January 2023. This information only includes those members who have been assigned IPv6 but not IPv4 resources by LACNIC. They may or may not have been assigned an autonomous system number.


    Data processing

    Python3 on a Jupyter notebook. We used the public APIs of LACNIC and RIPE NCC.


    LACNIC WHOIS


    RIPE NCC API


    APNIC IPv6 Penetration by ASN


    LACNIC’s delegated-extended File:


    Findings

    We found 483 organizations that are considered IPv6-only LACNIC members, which we divided into:


                IPv6-only members with ASN: 343 members


                IPv6-only members without ASN: 140 members




    Results for the 483 IPv6-only members (with and without ASN):


    An analysis of the 483 members allowed us to obtain the following information:


    – 261 announce the entire or a portion of the prefix


    – 208 announce the entire prefix they received from LACNIC


    – 53 announce a portion of the prefix they received from LACNIC


    – 222 do not announce the prefix




    Results for the 343 IPv6-only members with at least one ASN:


    A total of 343 of the 483 IPv6-only members have at least one ASN (71%).


    Out of the 343 members that have an ASN:


                            163 announce the prefix (47.52%)


    120 announce the entire IPv6 prefix (73.61%)


    43 announce a portion of the IPv6 prefix (26.38%)


    180 do not announce the IPv6 prefix (52.48%)





    Results for the 140 IPv6-only members without an ASN:


    A total of 140 of the 483 IPv6-only members do not have an ASN (29%).


    Out of these 140 IPv6-only members with no ASN:


    98 announce the prefix (70%)


    82 announce the entire prefix (83.67%)


    16 announce a portion of the prefix (16.32%)


    42 do not announce the prefix (30%)





    What can we conclude from the charts above?

    The first thing that stands out is that IPv6-only members without an ASN have 23% more announcements than LACNIC members who do have an ASN. In other words, these members have asked another organization to announce their prefix.

    In both cases, the number of unannounced prefixes is very high, and it might be interesting to find out whether there is a reason for this. 

    It is particularly striking that the percentage of partial announcements is almost identical (11% of members with an ASN and 12% of members without an ASN).

    Trying to identify whether the ASNs have IPv6 traffic

    Knowing that there are 343 ASNs with assigned IPv6 prefixes and considering that these are also IPv6-only members, one can presume that they must have “medium high” IPv6 traffic.  Therefore, we analyzed each autonomous system to determine its IPv6 traffic on 23 January 2023.


    How do we find out if an ASN has IPv6 traffic?

    As many of you know, APNIC has been measuring IPv6 traffic for each ASN for many years. You can learn more about these studies here: https://stats.labs.apnic.net/ipv6


    Based on the above, we wanted to find out if the known ASNs of IPv6-only LACNIC members actually had IPv6 traffic (beyond announcing their prefix). 


    Unfortunately, we were unable to obtain information for 274 (79.88%) of the 343 autonomous systems that were analyzed. However, it is important to note that this does not necessarily mean that they have not deployed IPv6, but that the traffic generated is very low and does not appear in the measurements by APNIC. A total of 32 ASNs were reported with 0% IPv6 traffic and 1 ASN with 88% IPv6 traffic.


    Are our IPv6-only members actually IPv6-only?

    Finally, we wanted to find out if our members (IPv6-only with an ASN) are truly as IPv6-only as their name implies.


    For this particular case, we relied on the RIPE NCC API to obtain the information presented below.


    Out of the 343 IPv6-only members with at least one ASN:


    – A total of 540 prefixes were being announced (including v4 and v6)


                            IPv4 announcements: 220


                            IPv6 announcements: 320


                            In IPv4 announcements, the average prefix length is: 23.56


                            In IPv6 announcements, the average prefix length is: 38.09


    – 66 members “became” DualStack, i.e., the ASN announces both IPv4 and IPv6


    – 90 members announce IPv6 only


    – 27 members announce IPv4 only


    – 160 do not announce any prefix


    And to which RIR do the IPv4 prefixes announced by IPv6-only LACNIC members belong?


    LACNIC ARIN RIPE NCC AFRINIC APNIC

    28 166 17 9 0






    Sankey Diagram – A Look at LACNIC’s IPv6-Only Members




    Conclusions

    Results suggest that, while a significant number of LACNIC members consider themselves to be IPv6-only, we observed that more than 50% of these members have not started announcing their IPv6 prefix. At the same time, we noticed that many of those who have deployed IPv6 continue to use IPv4. This means that, although in recent years IPv6 adoption has grown in the region, there is still a long way to go to achieve widespread IPv6 deployment. In any case, it is important to continue to monitor the adoption of the new protocol.


    Finally, being an IPv6-only LACNIC member also allows an organization to participate in the Internet ecosystem.

    Wednesday, February 22, 2023

    The Game of Dominoes and TCP/IP

    As many of us do, I have more than one passion: family, work, sports, a category in which I include the beautiful game of dominoes. I reached my best level in this game about 25 years ago, when I participated in several tournaments (a few of which I won) and the icing on the cake was that I took the sixth place in a national tournament. I should also mention that I come from a family with a certain tradition of domino fans, including two uncles, my father, and my brother.

    Playing dominoes is one of the most beautiful things that family and close and not so close friends can share. But how is the game of dominoes similar to the TCP/IP protocol? Some of you must probably be thinking “Alejandro has gone crazy.” Perhaps I haven’t gone crazy but likely already was.

    But I digress… I will show you that TCP/IP and dominoes do have a lot in common.

    IBM [1] defines the TCP/IP protocols as follows:

    “Protocols are sets of rules for message formats and procedures that allow machines and application programs to exchange information. These rules must be followed by each machine involved in the communication in order for the receiving host to be able to understand the message.”

    Sounds interesting… but you probably still don’t see what this has to do with dominoes and think it’s crazy. Do not despair, we’ll get there in a moment!

    This is what ChatGPT has to say about the game of dominoes:

    “The game of dominoes is a board game in which players place tiles with numbers on both ends on a board. The object of the game is to place all the tiles before the other players.In the game of dominoes, communication between players is based on strategy and planning. Players must communicate which tiles they have and which tiles they can play, and they must work together to find the best way to place the tiles on the board. Players must also pay attention to the other players’ moves and adapt their strategy accordingly. In short, communication during a game of dominoes is essential to a team’s success and to winning the game.”

    Now, let’s think at the macro level. At this point, we can see that both involve elements that must be sent/played, and which must maintain an order to achieve successful communication. Likewise, both require strategy and planning to achieve the objective: one connects tiles, the other connects devices. Am I starting to convince you?

    Now let’s talk about communication and partnership dominoes, a game where players are paired into teams. This is at the heart of the topic that I want to get to.

    Regardless of the style of dominoes (Cuban, Latino, Mexican, Chilean, etc.), partnership dominoes is a communication game and is not different from a data network. A player needs to communicate with his partner (A → B, B → A) to specify which tiles he has or doesn’t have.

    But how do partners communicate if one of the rules is that you are not allowed to talk? Therein lies the greatness of any good player: just like TCP/IP —and any other communication protocol— there are certain rules that must be followed.

    After three decades of experience in both worlds, I will share with you what I believe are the main moves in the partnership dominoes ecosystem and their counterpart in TCP/IP:

    The pose

    In a game of dominoes, the “pose” —the first tile to be placed on the board— is identical to a TCP SYN Packet, more specifically, a TCP Fast Open SYN with payload. This is a beautiful comparison, as in partnership dominoes the pose *always* transmits information, usually related to the suit (number) one most desires. TCP Fast Open —a thing of beauty from the world of TCP— is defined in RFC 7413 and its main objective is to be able to send information in the first packet with which all TCP communication begins (SYN).

    The pauses (double ACK)

    Payload is considered unnecessary in some networks, yet it may be worth the trouble. A player’s “pause” explicitly reveals that the player has more than one tile of the suit (number) they have played. With this, the player is efficiently communicating information to their partner, who should be aware of these pauses, much like those servers and networks where devices are configured to send more than one ACK in TCP (acknowledgment).

    Passing (packet dropped)

    In TCP, when a packet is dropped, the “Congestion Avoidance” phase begins. There, the TCP window decreases by 50% and so does transmission speed. Nothing more similar to passing in a game of dominoes. Of course, here a player goes into a panic, especially when they have a lot to transmit.

    The version

    In the world of IP, we are used to IPv4 and IPv6; in dominoes, the only difference is that versions range from 0 (blank) to 6. (Yes, I know, double-9 domino sets have the numbers 0 to 9, every rule has its exception ;-) 

    False thinking

    TCP Half-Open. Remember? This is when a three-way handshake (SYN, SYN+ACK, ACK) cannot be completed (but careful! this is the modern concept and, to be honest, it does not follow RFC 793). It is also commonly used to launch DoS attacks.

    Load size (total length)

    As we draw our tiles, how many points do we add?

    Source and destination address

    Here we are specifically in the Layer-3 world. This is a very interesting case where, just as in a communication network, one host communicates with another. The same thing happens in dominoes: while some “packets” are aimed at your partner, some may be aimed at our opponents, as needed (for example, if we are trying to find a specific suit).

    Thinking about each move

    Bufferbloat is a very particular situation, yet it occurs quite frequently. Basically, these are situations where hosts (mainly middleware, routers, firewalls, or switches) add delay (excess buffering) when switching packets. This creates unnecessary latency and jitters. If you manage a network, please be sure to check if you are suffering from bufferbloat.

    Block the game/hand

    In dominoes, this is the moment when it is no longer possible to make a play. In TCP/IP, it means that the network is down, so packets cannot be sent.

    Consequences of good and poor communication

    Just as in any network protocol, in partnership dominoes both proper and poor communication have their consequences. In a game of dominoes, if communication is good, it will most likely lead to victory. If communication is deficient, the team will lose the game. In TCP/IP, if communication is good, the connection will be properly established and the data will be delivered. If the communication is poor, the data will be corrupted and/or the connection will not be established.

    Head and tail

    In dominoes, a “head and tail” (capicĂșa) is when your last tile has two different numbers. What can this be compared to? Well, it can be compared to TCP Multipath (MPTCP), defined in RFC 8684, which allows operating connections through different paths. This is why MPTCP provides redundancy and efficiency in terms of bandwidth consumption.

    Have I not convinced you yet? OK, I have one more chance to see if I can do it.

    The table below shows a layer-to-layer comparison of TCP/IP and dominoes.

    TCP/IP model (+ user layer)Domino model
    UserPlayer
    ApplicationSet up the play
    TransportSelect the tile
    NetworkPick up the tiles
    LinkTiles
    PhysicalPlace the tile on the table

    In the TCP/IP model, a packet is built from the upper to the lower layers (it is then injected into the network, etc.), it is received by the destination host, and processed “in reverse”, from the physical to the application layer. The exact same thing happens in the domino model: the player sets up their move, selects their tile, picks it up, and then injects it into the game.

    Conclusion

    Comparing the game of partnership dominoes and the TCP/IP communication protocol may seem strange at first. However, a closer look reveals the similarities. In dominoes, there are two players who act as senders and receivers of information, as they each have their own set of tiles and must communicate with each other to decide which tile to play each turn. In the same way, in TCP/IP there are devices that act as senders and receivers of information.

    These contrasts illustrate how similarities can often exist between seemingly dissimilar systems, and that understanding these similarities can help us understand complex concepts and see things from a different perspective.

    Monday, January 23, 2023

    Python: reading a text file - character

    Situation:

       Reading a text file in python3 (csv or txt) there is a character that can be appreciated using "more" in terminal but in python3 the situation is more complicated.


    Example:

      $ more epa.csv

    <U+FEFF>the text


    Problem:

       Python3 reads the file well, it doesn't throw an error, but that invisible "character" remains in the variables, the texts, etc. and can cause some inconvenience.


    Solution:

       The solution is to read the file and specify the encoding, something as simple as:


    FILENAME="epa.csv"

    with open(FILENAME, encoding='utf-8-sig') as file:

         for line in file:

             print(line)




    Explanation (taken from: https://stackoverflow.com/questions/17912307/u-ufeff-in-python-string):


    The Unicode character U+FEFF is the byte order mark, or BOM, and is used to tell the difference between big- and little-endian UTF-16 encoding.


    Good luck,