La tabla inet.3 sólo se utiliza en una situación: cuando es el next-hop de una ruta BGP. Por tanto para que sea de utilidad hay que:
- Establecer un full mesh iBGP entre todos los routers PE y P.
- Usar las direcciones de loopback como origen de la sesión, destino (la loopback del vecino) y con next-hop self.
- Anunciar el enlace con el CE (en este caso. Normalmente sería una red interna del cliente redistribuida. Mas sobre esto más adelante).
Una vez hecho esto, todo el tráfico que llegue a un PE con destino la red anunciada por el otro PE se enrutará a través de MPLS.
Estrictamente hablando no es necesario configurar BGP en los P, con que exista en los PE es suficiente ya que son los únicos que necesitan saber llegar al otro extremo, los P se limitan a intercambiar etiquetas, pero puede ser útil que también participen por dos razones:
- Si también son o pueden ser en un futuro, PEs. En este caso, incluso si es en un futuro, merece la pena tener configurado el iBGP –recordemos que tiene que ser un full mesh entre todos los equipos para ahorrarnos configuraciones posteriores.
- Para facilitar la depuración.
Este segundo caso no afecta a los clientes o usuarios pero si a los ingenieros de soporte. Observemos el traceroute desde un CE a una IP del CE del otro extremo en dos situaciones distintas. En la primera los P también tienen configurado iBGP:
root@R1> traceroute 10.10.10.1 routing-instance hostB
traceroute to 10.10.10.1 (10.10.10.1), 30 hops max, 40 byte packets
1 10.20.10.2 (10.20.10.2) 0.822 ms 0.729 ms 0.491 ms
2 10.60.10.2 (10.60.10.2) 1.110 ms 1.023 ms 0.886 ms
MPLS Label=1000001 CoS=0 TTL=1 S=1
3 10.70.10.2 (10.70.10.2) 1.363 ms 1.445 ms 1.273 ms
MPLS Label=1000002 CoS=0 TTL=1 S=1
4 10.80.10.1 (10.80.10.1) 2.524 ms 2.102 ms 2.064 ms
MPLS Label=1000003 CoS=0 TTL=1 S=1
5 10.30.10.1 (10.30.10.1) 2.286 ms 3.548 ms 2.486 ms
6 10.10.10.1 (10.10.10.1) 3.076 ms 3.417 ms 2.475 ms
Puede verse cada uno de los saltos, como en un traceroute normal, y en el caso de los nodos que reciben el paquete MPLS (R5, R6, R4), la etiqueta MPLS con la que lo recibe.
La segunda situación es cuando los P no tienen iBGP configurado, sólo los PE:
root@R1> traceroute 10.10.10.1 routing-instance hostB
traceroute to 10.10.10.1 (10.10.10.1), 30 hops max, 40 byte packets
1 10.20.10.2 (10.20.10.2) 0.862 ms 0.771 ms 0.551 ms
2 * * *
3 * * *
4 * * *
5 10.30.10.1 (10.30.10.1) 3.471 ms 2.451 ms 2.331 ms
6 10.10.10.1 (10.10.10.1) 2.625 ms 2.895 ms 2.741 ms
Se puede ver que sólo se muestran los saltos de PE y CE. Los C aparecen como inalcanzables.
En realidad el paquete llega a ellos encapsulado en MPLS y se encamina bien a su destino, el problema es que para poder enviar la información devuelta al traceroute (en realidad lo que hace el programa es enviar un paquete al destino correcto pero con el TTL reducido para que cada nodo intermedio devuelva un mensaje de error y así poder obtener su IP) los nodos P extraen el paquete IP de dentro del MPLS e intentan devolver el mensaje de error al origen.
Observemos que sucede con las rutas a los CE si no tenemos iBGP configurado en los nodos P:
root@R5> show route 10.10.10.0
root@R5>
En cambio si tenemos configurado iBGP:
root@R5> show route 10.10.10.0
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/24 *[BGP/170] 00:00:21, localpref 100, from 10.0.0.2
AS path: I
> to 10.70.10.2 via em0.7
Un detalle importante es que el camino desde los P al CE no va por MPLS (a menos que el P sea también PE). Por tanto la respuesta con el mensaje de error para traceroute irá en IP.
Configuración
Las configuraciones BGP son las siguientes
R2
interfaces {
lo0 {
unit 0 {
family inet {
address 10.0.0.2/32;
}
}
}
}
routing-options {
router-id 10.0.0.2;
autonomous-system 65000;
}
protocols {
bgp {
family inet {
unicast;
}
group core {
type internal;
local-address 10.0.0.2;
export [ next-hop-self exporta-enlace ];
neighbor 10.0.0.3;
neighbor 10.0.0.4;
neighbor 10.0.0.5;
neighbor 10.0.0.6;
}
}
}
policy-options {
prefix-list enlace {
10.10.10.0/24;
}
policy-statement exporta-enlace {
from {
protocol direct;
prefix-list enlace;
}
then accept;
}
policy-statement next-hop-self {
then {
next-hop self;
}
}
}
Se puede ver que en routing-options se configura el router-id como la dirección de loopback y el número del AS, que tiene que ser el mismo para todos los PE y P.
En policy-options se configura una policy next-hop-self que como su nombre indica fuerza al router a enviar todas las rutas colocándose a el mismo como next hop.
Además en el caso de estos PE se crea una policy exporta-enlace que envía por iBGP la red del enlace con el CE. En una situación real suele ser una red redistribuida de forma dinámica por el cliente.
La configuración en los P es muy similar pero no se exporta ningún prefijo. En el otro PE la configuración es muy similar a este.
R4
interfaces {
lo0 {
unit 0 {
family inet {
address 10.0.0.4/32;
}
}
}
}
routing-options {
router-id 10.0.0.4;
autonomous-system 65000;
}
protocols {
bgp {
family inet {
unicast;
}
group core {
type internal;
local-address 10.0.0.4;
export next-hop-self;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.5;
neighbor 10.0.0.6;
}
}
}
policy-options {
policy-statement next-hop-self {
then {
next-hop self;
}
}
}
R6
interfaces {
lo0 {
unit 0 {
family inet {
address 10.0.0.6/32;
}
}
}
}
routing-options {
router-id 10.0.0.6;
autonomous-system 65000;
}
protocols {
bgp {
family inet {
unicast;
}
group core {
type internal;
local-address 10.0.0.6;
export next-hop-self;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
neighbor 10.0.0.5;
}
}
policy-options {
policy-statement next-hop-self {
then {
next-hop self;
}
}
}
R5
interfaces {
lo0 {
unit 0 {
family inet {
address 10.0.0.5/32;
}
}
}
}
routing-options {
router-id 10.0.0.5;
autonomous-system 65000;
}
protocols {
bgp {
family inet {
unicast;
}
group core {
type internal;
local-address 10.0.0.5;
export next-hop-self;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
neighbor 10.0.0.6;
}
}
}
policy-options {
policy-statement next-hop-self {
then {
next-hop self;
}
}
}
R3
interfaces {
lo0 {
unit 0 {
family inet {
address 10.0.0.3/32;
}
}
}
}
routing-options {
router-id 10.0.0.3;
autonomous-system 65000;
}
protocols {
bgp {
family inet {
unicast;
}
group core {
type internal;
local-address 10.0.0.3;
export [ next-hop-self exporta-enlace ];
neighbor 10.0.0.4;
neighbor 10.0.0.5;
neighbor 10.0.0.6;
neighbor 10.0.0.2;
}
}
}
}
policy-options {
prefix-list enlace {
10.20.10.0/24;
}
policy-statement exporta-enlace {
from {
protocol direct;
prefix-list enlace;
}
then accept;
}
policy-statement next-hop-self {
then {
next-hop self;
}
}
}
