00:00 Intro y musiquita
00:40 Bienvenida
01:12 Qué es ingeniería de tráfico
01:58 Porqué ingeniería de tráfico
02:45 Cuando hacer ingeniería de tráfico
05:03 Repaso selección de rutas en BGP
05:29 Ingeniería de tráfico saliente
05:54 Atributo Weight
06:33 Atributo LOCAL_PREF
07:36 Atributo AS_PATH
08:31 Rutas específicas
09:24 ECMP
10:28 UCMP
11:22 Ruta más antigua
11:42 Conclusiones tráfico saliente
12:16 Ingeniería de tráfico entrante
12:57 Atributo AS_PATH
16:33 Atributo AS_PATH en singlehomed
17:15 Atributo MED
17:47 Rutas específicas
19:56 Ingeniería de tráfico entrante con comunidades
20:21 Qué es comunidades en BGP
21:23 Comunidades bien conocidas o well-known
21:58 Comunidad NO_EXPORT
22:35 Comunidad NO_ADVERTISE
23:18 Comunidad BLACKHOLE
24:41 Comunidades no estándares
25:02 Ejemplo AS3356 – Recibidas – Tráfico saliente
25:46 Ejemplo AS3356 – Enviadas – Tráfico entrante
28:05 Outro y musiquita
Características de iBGP y diferencia con eBGP
Funcionamiento de iBGP y su relación con los sistemas autónomos internos
Comparación entre iBGP y eBGP en términos de vecindad, políticas y escalabilidad
00:00 Intro y musiquita
02:25 Repaso breve de eBGP
03:28 RFC1105 implementación original de BGP
05:22 Relaciones entre peers iBGP
06:06 Peering directo y full mesh
06:54 Route reflector
08:12 Confederaciones BGP
09:07 Diferencias principales entre iBGP vs eBGP
10:37 Atributos BGP a considerar en iBGP
12:45 Mecanismo de elección de rutas en iBGP
14:15 Distancia administrativa en iBGP vs eBGP
16:23 NEXT_HOP en iBGP
17:34 LOCAL_PREF y ECMP en iBGP
18:44 Escalabilidad, limitaciones, split horizon, sincronización de rutas
20:28 ¡Laboratorio!
Introducción a BGP
Características técnicas de BGP
Conceptos fundamentales en BGP
00:00 Intro y musiquita que les gusta
01:42 Bienvenida
Introducción a BGP
02:42 ¿Qué es BGP?
03:55 La famosa anécdota de la servilleta
Características técnicas de BGP
05:00 Características técnicas
07:55 Versiones de BGP
10:22 Componentes de una arquitectura BGP
Conceptos fundamentales en BGP
13:18 Conceptos de Sistema Autónomo – AS
15:08 Ejemplos de AS conocidos
15:08 Operación BGP en routers e intercambio de rutas
Soporte para familias en BGP
17:28 AFI / SAFI – Address Familiy Identifier / Subsequent Address Identifier
19:12 AFI más comunes
Principales AFI y SAFI en BGP
20:55 AFI/SAFI IPv4 Unicast e IPv6 Unicast
21:59 AFI/SAFI MPLS VPNv4
23:14 AFI/SAFI MPLS L2VPN
24:12 AFI/SAFI EVPN
Mecanismo de elección de rutas en BGP
25:12 Elección de rutas en BGP
25:32 Atributos de rutas en BGP
Mecanismo de elección de rutas en BGP
28:43 Algoritmo de elección en rutas en BGP – o de la naranja
Laboratorio
31:18 ¡Laboratorio!
41:54 Problemas técnicos :D, pasá de largo al siguiente capítulo
49:55 Laboratorio parte 2
On a previous post we saw an example of a network access topology running anycast default gateways.
The idea is to save IPv4 addresses, without other methods than standard routing protocols. Just plain BGP that can be implemented on most vendors, either via hardaware appliances or virtualized network devices.
For the following examples, I’ll simulate a public /24 prefix using the 198.51.100.0/24 which is reserved by IANA as TEST-NET-2 for documentation.
Lab Network
This lab network comprises 2 AGG/BNG routers, a single core router (which will perform additional aggregation), and a single edge router. All devices are MikroTik RouterOS 6.48.6 CHR instances.
The “edge” router is peering with the “core” through their loopbacks, and just advertising a default to it (or cores, on a future stage), and accepting the entire 198.51.100.0/24.
The “core” is peering with the “edge” of course, and also with two BNGs named as agg-bng-xx. This core is advertising its default to them, and accepting all prefixes within 198.51.100.254/24, with a prefix length up to /29.
If you come from a IOS land, this syntax would be something like this.
ip prefix-list BNG
permit 5 198.51.100.254/24 ge 24 le 29
Finally, the BNGs are peering with the core, accepting a default, and allowing any advertisements from 198.51.100.254/24 from /24 to /29.
Both routers have 198.51.100.254/24 as the anycast default gateway.
If you wonder hor this works, this lab network is similar to the one on the previous post which you can check here.
BNG PPPoE and DHCP
We will start by setting up PPPoE services on our BNGs.
At this point we will work it with local secrets and keeping all the AAA process in the same router, with RADIUS as a future option.
Be aware that RouterOS by default will try its best to adjust the TCP MSS to match the PPPoE interface MTU.
Also, this being PPPoE, we have no restrictions on using the first address on the network as the PPP connection will not care about it being a network address. However, this will have the obvious restrictions and behavior if we run DHCP.
We will also skip the .254 address on the address pool as this is assigned to the ether2 interface on both routers as our anycast default gateway.
Finally, we will add some test subscribers. A dumb switch will act as the last-mile technology which could be xPON, wireless, DSL, you name it. All the subs are running RouterOS 6.48.6, and this is just to have something capable to talk PPPoE. There is also a VPCS 0.8.2 which comes by default with GNS3.
GNS3 Topology
Address me, father
Starting with sub03 VPCS, we will ask DHCP to the BNG.
Welcome to Virtual PC Simulator, version 0.8.2
Dedicated to Daling.
Build time: Aug 23 2021 11:15:00
Copyright (c) 2007-2015, Paul Meng ([email protected])
All rights reserved.
VPCS is free software, distributed under the terms of the "BSD" licence.
Source code and license can be found at vpcs.sf.net.
For more information, please visit wiki.freecode.com.cn.
Press '?' to get help.
Executing the startup file
sub03> ip dhcp
DORA IP 198.51.100.252/24 GW 198.51.100.254
sub03> ping 198.51.100.254
84 bytes from 198.51.100.254 icmp_seq=1 ttl=64 time=1.278 ms
84 bytes from 198.51.100.254 icmp_seq=2 ttl=64 time=1.234 ms
84 bytes from 198.51.100.254 icmp_seq=3 ttl=64 time=0.946 ms
^C
If you pay attention, we did get the .252 address, instead of the .253.
sub4 had probably requested this one before, as RouterOS by default comes with a DHCP client on ether1. Is this the case?
[admin@RouterOS] > /ip ad pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 D 198.51.100.253/24 198.51.100.0 ether1
Indeed, both are running DHCP. And just for reference, this is how it looks from the BNG.
[admin@agg-bng-02] /ip dhcp-server> lease pr
Flags: X - disabled, R - radius, D - dynamic, B - blocked
# ADDRESS MAC-ADDRESS HOST-NAME SERVER RATE-LIMIT STATUS LAST-SEEN
0 D 198.51.100.253 0C:04:49:87:00:00 RouterOS dhcp1 bound 2m34s
1 D 198.51.100.252 00:50:79:66:68:01 sub03 dhcp1 bound 3m52s
Same is happening with sub01 and sub02, however we’ll remove the DHCP client and add a PPPoE client.
[admin@RouterOS] /interface pppoe-client> add interface=ether1 user=sub1 password=sub1 add-default-route=yes
[admin@RouterOS] /interface pppoe-client> pr
Flags: X - disabled, I - invalid, R - running
0 X name="pppoe-out2" max-mtu=auto max-mru=auto mrru=disabled interface=ether1 user="sub1" password="sub1" profile=default keepalive-timeout=10 service-name="" ac-name="" add-default-route=yes default-route-distance=1
dial-on-demand=no use-peer-dns=no allow=pap,chap,mschap1,mschap2
[admin@RouterOS] /interface pppoe-client> ena 0
[admin@RouterOS] /interface pppoe-client> pr
Flags: X - disabled, I - invalid, R - running
0 R name="pppoe-out2" max-mtu=auto max-mru=auto mrru=disabled interface=ether1 user="sub1" password="sub1" profile=default keepalive-timeout=10 service-name="" ac-name="" add-default-route=yes default-route-distance=1
dial-on-demand=no use-peer-dns=no allow=pap,chap,mschap1,mschap2
[admin@RouterOS] /interface pppoe-client> /ip ad pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 D 198.51.100.125/32 198.51.100.254 pppoe-out2
[admin@RouterOS] /interface pppoe-client>
This config looks as follows on sub02.
[admin@RouterOS] >
[admin@RouterOS] > /ip dhcp-client
[admin@RouterOS] /ip dhcp-client> remove [find]
[admin@RouterOS] /ip dhcp-client> /
[admin@RouterOS] > /interface pppoe-client
[admin@RouterOS] /interface pppoe-client> add add-default-route=yes disabled=no interface=ether1 name=pppoe-out2 password=sub1 user=sub1
[admin@RouterOS] /interface pppoe-client> pr
Flags: X - disabled, I - invalid, R - running
0 R name="pppoe-out2" max-mtu=auto max-mru=auto mrru=disabled interface=ether1 user="sub1" password="sub1" profile=default keepalive-timeout=10 service-name="" ac-name="" add-default-route=yes default-route-distance=1
dial-on-demand=no use-peer-dns=no allow=pap,chap,mschap1,mschap2
[admin@RouterOS] /interface pppoe-client> /ip ad pr
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 D 198.51.100.124/32 198.51.100.254 pppoe-out2
[admin@RouterOS] /interface pppoe-client> /ip ro pr
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 pppoe-out2 1
1 ADC 198.51.100.254/32 198.51.100.124 pppoe-out2 0
[admin@RouterOS] /interface pppoe-client>
Alright, we can ping the gateway from both. Can we get beyond it?
sub03> trace 1.1.1.1
trace to 1.1.1.1, 8 hops max, press Ctrl+C to stop
1 198.51.100.254 2.362 ms 1.396 ms 0.958 ms
2 * * *
3 * * *
^C 4
The BNGs is aware of this subscriber, however, we are not advertising anything to the core- yet.
We like connected things
If you recall, on the AGGs, there was a precise out filter on the peering to the core.
Well, the idea is to let the core know about some parts of the subnet, covered by this filter. And the easiest way is to have BGP to
Know there are some hosts running DHCP, probably via static routes pointing to the local interface.
PPPoE subs will already have a dynamic and connected route on the routing table.
Have BGP redistribute connected and statics, in case there are no PPPoE subscribers and we only have DHCP subscribers.
Aggretate all PPPoE interfaces into a supernet, because we are allowing up to /29 This supernet will be a /25, because we created our internet pool from 198.51.100.1-198.51.100.127. Same concept applies for agg02, with the consideration that the aggregate will be 198.51.100.128/25
The include-igp setting will match all IGP routes, like connected routes and iBGP routes.
You can see that the core is aware of a part of the /24 exists on this BNG.
[admin@core-01] > /ip ro pr
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 0.0.0.0/0 10.0.1.1 200
1 ADC 10.0.0.0/30 10.0.0.2 ether1 0
2 ADo 10.0.1.1/32 10.0.0.1 110
3 ADC 10.1.1.1/32 10.1.1.1 lo0 0
4 ADo 10.10.1.1/32 10.255.255.2 110
5 ADo 10.10.1.2/32 10.255.255.6 110
6 ADC 10.255.255.0/30 10.255.255.1 ether2 0
7 ADC 10.255.255.4/30 10.255.255.5 ether3 0
8 ADb 198.51.100.0/24 10.10.1.1 200
9 ADb 198.51.100.0/25 10.10.1.1 200
However, with this setup, we are still advertising the entire /24 to the core. Let’s adjust the filters on both routers to advertise only anything longer than 24.
And now, from sub4 for example, let’s run a traceroute to it.
[admin@RouterOS] /tool> traceroute 1.1.1.1
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 198.51.100.254 0% 2 1.6ms 2.6 1.6 3.6 1
2 10.255.255.5 0% 2 3.2ms 3.8 3.2 4.3 0.6
3 1.1.1.1 0% 2 4.6ms 4.7 4.6 4.8 0.1
There is a special consideration here if you still haven’t noticed it.
How does agg1 knows about what’s happening on agg2. For example, if from agg1 we try to reach hosts on the 198.51.100.128/25 network, the immediate next hop is agg1 itself, because we have a DAC route pointing to 198.51.100.0/24
[admin@agg-bng-01] > /ip ro pr
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 0.0.0.0/0 10.0.1.1 200
1 ADo 10.0.0.0/30 10.255.255.1 110
2 ADo 10.0.1.1/32 10.255.255.1 110
3 ADo 10.1.1.1/32 10.255.255.1 110
4 ADC 10.10.1.1/32 10.10.1.1 lo0 0
5 ADo 10.10.1.2/32 10.255.255.1 110
6 ADC 10.255.255.0/30 10.255.255.2 ether1 0
7 ADo 10.255.255.4/30 10.255.255.1 110
8 ADC 198.51.100.0/24 198.51.100.254 ether2 0
9 ADbU 198.51.100.0/25 20
10 ADC 198.51.100.126/32 198.51.100.254 <pppoe-sub1-1> 0
11 ADC 198.51.100.127/32 198.51.100.254 <pppoe-sub1> 0
However, we already have all rhe routing info we need on the core.
The fix is simple and involves of course, filtering, but we’ll cover that on the next post.
