This is the way to install the telnet command in Alpine Linux (very popular in the container world such as docker)

This is the way to install the telnet command in Alpine Linux (very popular in the container world such as docker)

#apk update

#apk add busybox-extras

The real solution to run ContainerLAB on MAC m1 or m2 apple silicon

Step 1: Install Canonical Multipass your MAC 

$brew install multipass

Step 2: Install the VM called docker

$multipass launch docker --name mydocker

Step 3: Connect to the new VM

$multipass shell mydocker

Step 4: Inside the VM install ContainerLab

$sudo su

#bash -c "$(curl -sL https://get.containerlab.dev)"

Let's try this simple back2back topology of two Linux computers with FRR

-- 2-frr-back2back.yml --

name: ipv6-ws

topology:

   kinds:

     linux:

       image: ghcr.io/hellt/network-multitool

   do not give:

   ROUTERS ###

     A1:

       kind: linux

       image: quay.io/frrouting/frr:8.4.1

       exec:

         - "sysctl -w net.ipv6.conf.all.forwarding=1"

         - "ip address add dev eth1 2001:db8:ffab::1/64"

     A2:

       kind: linux

       image: quay.io/frrouting/frr:8.4.1

       exec:

         - "ip address add dev eth1 2001:db8:ffab::2/64"

         - "sysctl -w net.ipv6.conf.all.forwarding=1"

   links:

     - endpoints: ["R1:eth1", "R2:eth1"]

--- yml --

Step 5: Let's build the topology with clab:

clab dep -t 2-frr-back2back.yml

Step 6: finally we are going to connect to one of the VMs inside ContainerLAB

docker exec -i -t clab-ipv6-ws-R2 bash

A Much-Needed BGP RFC: AS Path Prepending

Introduction

The Border Gateway Protocol (BGP) plays a critical role in building and maintaining Internet routing tables, so much so that it is considered the “glue” that holds the Internet together. In this context, a long-standing and very popular technique known as ‘AS Path Prepending’ has been devised as a key strategy for influencing route selection and optimizing an AS’s inbound and outbound traffic.

In this document, we will navigate through the IETF draft titled “AS Path Prepending” [1], which includes several ideas and concepts that are of great value to the community.

About draft-ietf-grow-as-path-prepending

This draft has been under discussion within the Global Routing Operation (GROW) Working Group since 2020 and is currently on version 10. The document has seven co-authors: M. McBride, D. Madory, J. Tantsura, R. Raszuk, H. Li., J. Heitz, and G. Mishra. It predominantly received support on the discussion list (including my own). You can read the draft here.

What is AS Path Prepending?

AS Path Prepending is a technique that involves repetitively adding one’s autonomous system identifier (ASN) to the list of ASs in a BGP route path (AS_PATH). Its goal is to influence route selection by making certain paths less attractive to inbound/outbound traffic. In other words, it consists of adding our autonomous system to the AS_PATH and therefore artificially “lengthening the path” to a prefix on the Internet.

In the figure above, without prepends, Router A prefers to go to C via B. However, when three prepends are added on B, router A decides to reach C via D.

Why is AS Path Prepending used and what is it used for?

AS Path prepending is used for multiple reasons. The main reason is undoubtedly traffic engineering, which in turn is used to influence an AS’s inbound and outbound traffic. It is very likely that the AS wishes to achieve one of the following goals:

• to distribute traffic among two or more upstream providers, or
• to have an upstream backup provider.
• Whatever the case, the goal is traffic engineering.

To prepend or not to prepend, that is the question

Prepending is a bit like NAT in that it is often a necessary evil. As we will explain, its excessive and sometimes unnecessary use can become a vulnerability with significant implications for network stability.

What’s wrong with using AS Path Prepending?

We all know that AS Path Prepending is a very common technique to influence BGP decisions. However, its excessive, incorrect, and sometimes unnecessary use can have negative consequences. For example:

• Creation of suboptimal traffic flows. In other words, we may achieve our goal of distributing traffic in the immediate links; however, beyond our immediate upstream, traffic is not optimized to reach our autonomous system and vice versa.
• Prefix de-aggregation. When implementing traffic engineering, it is very common to de-aggregate prefixes, which affects the Internet ecosystem.
• In the event of a route-leak, under normal circumstances, the as-path of our advertisements would be shorter than that of the leaked route. However, if we artificially lengthen the path by prepending, the as-path of the leaked routes may be shorter than those we are legitimately announcing for our legitimate prefix, which would have lower preference, leading to potential route hijacking, attacks, and a long etcetera.
• Memory consumption. As expected, these AS Path Prepends are learned by BGP Speakers, thus increasing their memory usage. To this I would add that prepending introduces a small additional CPU usage penalty for each prefix.

Given that AS Path Prepend is no longer recommended, what alternatives are available?

There are many techniques for performing traffic engineering in BGP. I will mention some that appear in the draft:

• Leveraging BGP communities. In addition to the well-known BGP communities, I recommend talking to your BGP peers to optimize traffic. There are numerous BGP communities implemented by providers, which might certainly benefit your setup.
• Announcing more specific routes to your main upstreams.
• Manipulating the AS Origin Code. Remember that this attribute is also found in the BGP route selection algorithms.
• Using Multi Exit Discriminator (MED), a non-transitive attribute that can be used with excellent results for manipulating inbound traffic when we have several links to the same provider
• Using Local-Preference, another non-transitive attribute, perfect for influencing the traffic that leaves our autonomous system

This is all well and good, but I still need to use AS Path Prepending. Any suggestions?

The draft mentions the best current practices when using AS Pat Prepending, which I will summarize below:

1. Only use AS Path Prepending if it is absolutely necessary.
2. Due to some traffic manipulation techniques, when using AS Path Prepending, we may not see significant changes in the traffic distribution, which is why it is important to talk to our peers to see if they will honor the prepends.
3. Use local-preference on our network.
4. Don’t prepend ASNs that you don’t own.
5. Don’t prepend if you are connected to a single ISP using a single link, i.e., single homed (this one is not included in the draft).
6. If we prepend a prefix, it might not be necessary to use that prepend for all our peers.
7. There is no need to use more than five prepends. The reason for this is that more than 90% of path are five ASs or fewer in length.

Final Considerations

The use of AS Path Prepending is a valuable strategy but should be used only when necessary and with caution, following best practices. Excessive use of prepends may cause unforeseen events that may affect our autonomous system from a traffic and a security perspective.

We invite you to read the full draft (available here and to join the discussion on the LACNOG mailing list.

We also encourage you to comment on this post to let us know if you are prepending your ASN, as well as why and what you are using this for.

References:

[1] https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/

Two very short jokes, one TCP and other UDP

TCP:

 ” You wanna hear a TCP joke ?
 You wanna hear a TCP joke ?
 You wanna hear a TCP joke ?
 You wanna hear a TCP joke ?

 [...]”

UDP:

I’d tell you a UDP joke, but you might not get it. 

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)

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

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.