Se puede ver que el camino está creado examinando la tabla de rutas de cada equipo.
- En los emisores (ingress) la tabla a consultar es inet.3, que es la que asocia el prefijo de destino (la loopback del nodo remoto) con la etiqueta a usar en la encapsulación.
- En los receiver no se puede ver el camino ya que al usar PHP el paquete ya les llega desencapsulado.
- En los P sólo se hace una conmutación de etiquetas y la tabla que almacena esta información es mpls.0
A continuación se muestran las dos tablas para todos los equipos R2-R4-R6-R5-R3
root@R2> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.3/32 *[MPLS/6/1] 03:48:39, metric 0
> to 10.30.10.2 via em1.4, Push 1000011
root@R2> show route table mpls.0
mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:48:59, metric 1
Receive
1 *[MPLS/0] 03:48:59, metric 1
Receive
2 *[MPLS/0] 03:48:59, metric 1
Receive
root@R4> show route table inet.3
root@R4> show route table mpls.0
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:37:05, metric 1
Receive
1 *[MPLS/0] 03:37:05, metric 1
Receive
2 *[MPLS/0] 03:37:05, metric 1
Receive
1000003 *[MPLS/6] 01:27:14, metric 1
> to 10.30.10.1 via em1.4, Pop
1000003(S=0) *[MPLS/6] 01:27:14, metric 1
> to 10.30.10.1 via em1.4, Pop
1000011 *[MPLS/6] 01:27:14, metric 1
> to 10.80.10.2 via em3.8, Swap 1000012
root@R6> show route table inet.3
root@R6> show route table mpls.0
mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:29:58, metric 1
Receive
1 *[MPLS/0] 03:29:58, metric 1
Receive
2 *[MPLS/0] 03:29:58, metric 1
Receive
1000002 *[MPLS/6] 01:16:11, metric 1
> to 10.80.10.1 via em1.8, Swap 1000003
1000012 *[MPLS/6] 01:16:11, metric 1
> to 10.70.10.1 via em0.7, Swap 1000013
root@R5> show route table inet.3
root@R5> show route table mpls.0
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:35:04, metric 1
Receive
1 *[MPLS/0] 03:35:04, metric 1
Receive
2 *[MPLS/0] 03:35:04, metric 1
Receive
1000001 *[MPLS/6] 01:13:18, metric 1
> to 10.70.10.2 via em0.7, Swap 1000002
1000013 *[MPLS/6] 01:13:18, metric 1
> to 10.60.10.1 via em1.6, Pop
1000013(S=0) *[MPLS/6] 01:13:18, metric 1
> to 10.60.10.1 via em1.6, Pop
root@RE3> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.2/32 *[MPLS/6/1] 01:44:37, metric 0
> to 10.60.10.2 via em3.6, Push 1000001
root@RE3> show route table mpls.0
mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:45:43, metric 1
Receive
1 *[MPLS/0] 03:45:43, metric 1
Receive
2 *[MPLS/0] 03:45:43, metric 1
Receive
El problema es que la tabla de rutas inet.3 no se usa normalmente para el routing y si examinamos la ruta al extremo opuesto se prefiere la obtenida por OSPF que está en la tabla inet.0:
root@R2> show route 10.0.0.3
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.3/32 *[OSPF/10] 01:27:43, metric 4
> to 10.30.10.2 via em1.4
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.3/32 *[MPLS/6/1] 04:07:17, metric 0
> to 10.30.10.2 via em1.4, Push 1000011
No hay comentarios:
Publicar un comentario