Basic IPsec Virtual Tunnel Interface - VTI

Le but est de monter un tunnel IPSec entre deux routeurs en utilisant des VTI.
La clé partagée est: 1234.

hostname R1
!
crypto isakmp policy 1
 encr aes 256
 authentication pre-share
 group 2
crypto isakmp key 1234 address 10.2.2.1
crypto isakmp keepalive 10
!
!
crypto ipsec transform-set TS-1 esp-aes 256
!
crypto ipsec profile VTI
 set transform-set TS-1
!
interface Tunnel0
 description *** Vers Tunnel 1 premium ***
 ip unnumbered Loopback0
 ip mtu 1380
 ip tcp adjust-mss 1340
 tunnel source Loopback0
 tunnel destination 10.2.2.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
interface Loopback10
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 speed auto
!
router eigrp 10
 redistribute connected
 network 10.1.1.1 0.0.0.0
 no auto-summary
!
ip route 10.2.2.1 255.255.255.255 192.168.1.2
!

La configuration est identique sur R2.

R1#show crypto ipsec sa


interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 10.1.1.1


protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 10.2.2.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 16017, #pkts encrypt: 16017, #pkts digest: 16017
#pkts decaps: 15918, #pkts decrypt: 15918, #pkts verify: 15918
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0


local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.2.2.1
path mtu 1514, ip mtu 1514, ip mtu idb Loopback0
current outbound spi: 0xCF2A12E(217227566)


inbound esp sas:
spi: 0x8C8AD70B(2357909259)
transform: esp-256-aes ,
in use settings ={Tunnel, }
conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4596558/1206)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE


inbound ah sas:


inbound pcp sas:


outbound esp sas:
spi: 0xCF2A12E(217227566)
transform: esp-256-aes ,
in use settings ={Tunnel, }
conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4596542/1204)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE


outbound ah sas:


outbound pcp sas:
R1#

Traffic Engineering and logging

mpls traffic-eng logging lsp

To log certain traffic engineering label switched path (LSP) events, use the mpls traffic-eng logging lsp command in global configuration mode.

• path-errors = Logs RSVP path errors for traffic engineering LSPs.
• reservation-errors = Logs RSVP reservation errors for traffic engineering LSPs.
• preemption = Logs events related to the preemption of traffic engineering LSPs.
  
• setups = Logs events related to the establishment of traffic engineering LSPs.
  
• teardowns = Logs events related to the removal of traffic engineering LSPs.
  

IPv6 - 6PE

1. Introduction

Le lab suivant présente rapidement le fonctionnement de 6PE.
En prérequis, un coeur de réseau IPv4 MPLS constitue le backbone de l'opérateur.
Sur les équipements P (P1 dans le schéma ci-dessous), IPv6 n'est pas activé (ipv6 unicast-routing).
2. Configuration du coeur MPLS IPv4
6PE1:

!
hostname 6PE1
!
interface Loopback0
ip address 10.0.0.2 255.255.255.255
no clns route-cache
!
interface Serial1/1
description ## R2-R3 ##
ip address 192.168.23.2 255.255.255.0
ip router isis
mpls ip
serial restart-delay 0
!
router isis
net 49.0000.0000.0002.00
passive-interface Loopback0
!

6PE2:

!
hostname 6PE2
!
interface Loopback0
ip address 10.0.0.4 255.255.255.255
no clns route-cache
!
interface Serial1/3
description ## R4-R3 ##
ip address 192.168.34.4 255.255.255.0
ip router isis
mpls ip
serial restart-delay 0
!
router isis
net 49.0000.0000.0004.00
passive-interface Loopback0
!

P1:

!
hostname P1
!
interface Loopback0
ip address 10.0.0.3 255.255.255.255
no clns route-cache
!
interface Serial1/1
description ## R2-R3 ##
ip address 192.168.23.3 255.255.255.0
ip router isis
mpls ip
serial restart-delay 0
!
interface Serial1/2
description ## R3-R4 ##
ip address 192.168.34.3 255.255.255.0
ip router isis
mpls ip
serial restart-delay 0
!
router isis
net 49.0000.0000.0002.00
passive-interface Loopback0
!

3. Connexion des CE IPv6 aux 6PE:

6PE1:

!
ipv6 unicast-routing
ipv6 cef
!
interface Serial1/0
no ip address
ipv6 address 3FFE:B00:FFFF::2/48
no fair-queue
serial restart-delay 0
no clns route-cache
!

CE1:

!
ipv6 unicast-routing
ipv6 cef
!
interface Serial1/0
no ip address
ipv6 address 3FFE:B00:FFFF::1/48
no fair-queue
serial restart-delay 0
no clns route-cache
!
ipv6 route ::/0 Serial1/0 3FFE:B00:FFFF::2
!

6PE2:

!
ipv6 unicast-routing
ipv6 cef
!
interface Serial1/3
no ip address
ipv6 address 3FFE:B00:DDDD::2/48
no fair-queue
serial restart-delay 0
no clns route-cache
!

CE2:

!
ipv6 unicast-routing
ipv6 cef
!
interface Serial1/3
no ip address
ipv6 address 3FFE:B00:DDDD::1/48
no fair-queue
serial restart-delay 0
no clns route-cache
!
ipv6 route ::/0 Serial1/0 3FFE:B00:DDDD::2
!

4. Configuration des 6PE pour l'échange des préfixes

Le cœur n'est pas configuré pour IPv6, on se sert des labels.
Une session MP-iBGP est configurée entre les deux '6PE':

6PE1:

!
router bgp 10
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.0.0.4 remote-as 10
neighbor 10.0.0.4 update-source Loopback0
!
address-family ipv6
neighbor 10.0.0.4 activate
neighbor 10.0.0.4 send-label
network 3FFE:B00:FFFF::/48
exit-address-family
!

6PE2:

!
router bgp 10
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.0.0.2 remote-as 10
neighbor 10.0.0.2 update-source Loopback0
!
address-family ipv6
neighbor 10.0.0.2 activate
neighbor 10.0.0.2 send-label
network 3FFE:B00:DDDD::/48
exit-address-family
!

5. Résultats et interprétations

Les networks IPv6 vers les CE1 et CE2 sont annoncés par leur PE respectifs.
Le next hop est de la forme ::FFFF:10.0.0.2, 10.0.0.2 est l'interface update source de la session MP-BGP vers 6PE1:

6PE2#show ip bgp ipv6 unicast
BGP table version is 7, local router ID is 10.0.0.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete


Network Next Hop Metric LocPrf Weight Path
*> 3FFE:B00:DDDD::/48 :: 0 32768 i
*>i3FFE:B00:FFFF::/48 ::FFFF:10.0.0.2 0 100 0 i
6PE2#

Le prefixe vers CE2 est présent dans la RIB IPv6:

6PE2#show ipv6 route
IPv6 Routing Table - 5 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C 3FFE:B00:DDDD::/48 [0/0]
via ::, Serial1/3
L 3FFE:B00:DDDD::2/128 [0/0]
via ::, Serial1/3
B 3FFE:B00:FFFF::/48 [200/0]
via ::FFFF:10.0.0.2
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
6PE2#

Le process BGP de 6PE2 génère un label pour le prefixe qu'il annonce, et le remonte dans la LFIB:

6PE2#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 16 10.0.0.2/32 0 Se1/2 point2point
17 Pop Label 10.0.0.3/32 0 Se1/2 point2point
18 Pop Label 192.168.23.0/24 0 Se1/2 point2point
19 Aggregate 101.101.101.4/32[V] \
0 CustIPv4
20 No Label 3FFE:B00:DDDD::/48 \
2080 Se1/3 point2point
6PE2#

Le next-hop annoncé par la session MP-iBGP est 10.0.0.2, ldp annonce le label 16 pour ce préfixe.

6PE2#show ipv6 cef 3FFE:B00:FFFF::/48
3FFE:B00:FFFF::/48
nexthop 192.168.34.3 Serial1/2 label 16 20
6PE2#

Pour le second PE, le principe est identique:

6PE1#show ip bgp ipv6 unicast
BGP table version is 7, local router ID is 10.0.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*>i3FFE:B00:DDDD::/48
::FFFF:10.0.0.4 0 100 0 i
*> 3FFE:B00:FFFF::/48
:: 0 32768 i
6PE1#

6PE1#show ipv6 route
IPv6 Routing Table - 5 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
B 3FFE:B00:DDDD::/48 [200/0]
via ::FFFF:10.0.0.4
C 3FFE:B00:FFFF::/48 [0/0]
via ::, Serial1/0
L 3FFE:B00:FFFF::2/128 [0/0]
via ::, Serial1/0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
6PE1#

6PE1#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 Pop Label 10.0.0.3/32 0 Se1/1 point2point
17 17 10.0.0.4/32 0 Se1/1 point2point
18 Pop Label 192.168.34.0/24 0 Se1/1 point2point
20 Aggregate 3FFE:B00:FFFF::/48 \
0
6PE1#

6PE1#sh ipv6 cef
3FFE:B00:DDDD::/48
nexthop 192.168.23.3 Serial1/1 label 17 20
3FFE:B00:FFFF::/48
attached to Serial1/0
3FFE:B00:FFFF::2/128
receive
FE80::/10
receive
FF00::/8
receive
6PE1#

Unicast Reverse Path Forwarding (uRPF)

Unicast Reverse Path Forwarding (uRPF)

uRPF est une feature permettant d'éviter l'IP Spoofing.
Lorsque urpf est activé sur une interface, le routeur examine chaque paquet reçu en entrée.
Il vérifie ensuite que les paquets arrivent bien par l'interface représentant la 'best return path' vers la source.
Pour cela, urpf effectue un reverse lookup dans la table CEF.

- Si le paquet arrive par la bonne interface, il est forwarded.
- Si le paquet arrive par une interface autre que l'interface inscrite dans la FIB, le paquet est détruit.

Il est possible de créer des exceptions via une acl.

Strict Mode uRPF
Configuration d'uRPF 'strict'
Router(config)# ip cef
Router(config-if)# interface type
Router(config-if)# ip verify unicast source ip verify unicast source reachable-via list

'list' correspond à une acl.
Si cette acl permet une plage d'ip, cette plage à le 'droit' d'être spoofée, le paquet est donc forwardé.
Si cette acl deny une plage d'ip, cette plage ne peut être spoofée, le paquet est détruit (comportement normal).

Pour permettre au routeur de répondre à ses propres requêtes icmp:
ip verify unicast source reachable-via rx allow-self-ping

Loose Mode uRPF
Avec strict mode uRPF, un problème apparait que lorsque le trafic est asymétrique (internet).
Pour éviter cela, on utilise loose mode uRPF.
Dans ce mode, il suffit que la source soit présente dans la table de routage pour que le paquet soit forwardé (quelque soit l'interface de sortie).
Dans le cas contraire, il est détruit.

Configuration d'uRPF 'loose'
Router(config)# ip cef
Router(config-if)# interface type
Router(config-if)# ip verify unicast source reachable-via any

Ici, à partir du moment où une entrée pour joindre l'adresse IP source se trouve dans la table de routage, le trafic est forwardé.
En option, il est possible de spécifier une acl.

ip verify unicast source reachable-via {rx | any} [allow-default] [allow-self-ping] [list] [l2-src] [phys-if]

Divers timers sont configurables pour le calcul du 'drop rate':
ip verify drop-rate compute interval
ip verify drop-rate compute window
ip verify drop-rate notify hold-down
Pour être notifié en cas de dépassement du seuil de paquets détruit:
ip verify unicast notification threshold
(Default is 1000)

Remotely-Triggered Black Hole - RTBH

RTBH est une technique permettant d'éviter qu'une attaque DDoS surcharge la capacité du réseau opérateur.

La technique consiste à envoyer l'ensemble du trafic à destination d'un routeur client vers un black hole.

R2 et R4 constituent le cœur de réseau de l'opérateur.

R5 est le client.
R3 est le routeur permettant l'injection de routes.
R1 représente internet.

Les routeurs R2, R3 et R4 sont dans le même IGP.
Une session iBGP existe entre R2 et R3 et entre R2 et R4. R2 est RR.

R1 et R2 possèdent une session eBGP permettant l'échange des préfixes 150.1.1.1 et 150.5.1.1.

Un DDoS est effectué vers R5, 150.5.1.1.

Les étapes pour effectuer le RTBH sont:
1\ Création d'une route vers Null0 pour un préfixe 'bidon', en général, le TEST-NET (RFC3330), 192.0.2.0/24.
Cette route est présente sur l'ensemble des routeurs de Cœur.

ip route 192.0.2.0 255.255.255.0 Null0 name RTBH

2\ Sur le routeur injectant la route, R3, il faut installer une route statique vers le préfixe attaqué et la faire pointer vers Null0 ( de manière à pouvoir annoncer ce network).
Un tag est ajouté sur la route pour pouvoir effectuer un match dans une route-map.
R3:

ip route 150.5.1.1 255.255.255.255 Null0 tag 666

3\ Toujours sur R3, il faut redistribuer cette route vers le préfixe attaqué.
Une route-map est configurée de manière à modifier le next-hop en 192.0.2.1, qui ira donc pointer vers Null0 pour chaque routeur de coeur.
Cette route-map permet également de faire préférer cette route par rapport à l'originale:

!
route-map RTBH permit 10
match tag 666
set local-preference 700
set origin igp
set ip next-hop 192.0.2.1
!
route-map RTBH permit 20
!

Enfin,

router bgp 3352
redistribute static route-map RTBH

!
Résultat:
Sur R4, à l'origine, la route était apprise correctement:

R4#sh ip route 150.5.1.1
Routing entry for 150.5.1.1/32
Known via "bgp 3352", distance 20, metric 0
Tag 65535, type external
Last update from 150.1.45.5 01:10:58 ago
Routing Descriptor Blocks:
* 150.1.45.5, from 150.1.45.5, 01:10:58 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65535

Suite aux modifications, elle est apprise de la manière suivante:
R4#sh ip route 150.5.1.1
Routing entry for 150.5.1.1/32
Known via "bgp 3352", distance 200, metric 0, type internal
Last update from 192.0.2.1 00:00:08 ago
Routing Descriptor Blocks:
* 192.0.2.1, from 150.2.1.1, 00:00:08 ago
Route metric is 0, traffic share count is 1
AS Hops 0

Et ce, sur chaque routeur de cœur.
L'interêt réside dans le fait que l'action n'est pas effectuée sur l'ensemble des routeurs de cœur, mais bien à partir d'un point centralisé.

L'inconvénient est que le DDoS à réussi, tout le trafic à destination du client est black-holed.

Multicast - Génération de trafic

Pour simuler une source de trafic multicast:

SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#rtr 1
SW1(config-rtr)#type udpEcho dest-ipaddr 224.1.1.1 dest-port 12345 source-ipaddr 10.1.37.7 control disable
SW1(config-rtr-udp)#frequency 5
SW1(config-rtr-udp)#timeout 0
SW1(config-rtr-udp)#exit
SW1(config)#rtr schedule 1 start now
SW1(config)#end
SW1#

Traffic Engineering Tunnel Options

Options TE:
Envoyer le traffic dans un tunnel:
1\ PBR (RAS)
2\ Static Routing (RAS)
3\ Autoroute

Autoroute:
tunnel mpls traffic-eng autoroute announce
Le tail end est accessible via le tunnel.
Tous les équipements derrière le tail-end sont également joignable via ce tunnel.
Le cost vers le tail end est le même que le 'best path' vers l'igp.
Le cost vers les équipements derrière le tail end correspond au cost jusqu'au le tail-end plus le cost 'normal' vers l'igp.
R0:
show ip route
O 10.3.3.1 [110/31] via 10.3.3.1, 00:17:28, Tunnel0
O 10.2.2.1 [110/21] via 10.3.3.1, 00:17:28, Tunnel0



Modifier les métriques:Sur l'interface tunnel:
Par défaut, le cost vers le tail-end est égal au cost IGP.
tunnel mpls traffic-eng autoroute metric 5
Ici, on modifie ce comportement : la metrique vers le tail-end est de 5.
Les addresses derrière le tail-end ont un cost de 5+la valeur IGP.

tunnel mpls traffic-eng autoroute metric relative -5
Sur le head-end, la route vers le tunnel tail-end n'est plus égale au meilleur cost de l'igp, mais à la valeur de l'IGP + la valeur relative.

tunnel mpls traffic-eng autoroute metric absolute 5
Ne fonctionne qu'avec IS-IS: le cost du tail-end et des adresses derrière le tail-end est de 5.

Toutes ces modifications de valeurs ne sont valables que pour la source du tunnel.
Ces costs ne sont pas redistribués dans l'IGP.
Les modifications sont apportées après le calcul SPF.

Bande passante du tunnel

Les interfaces physiques possèdent une bande passante (RSVP):
- resv de pool:
ip rsvp bandwidth 10000
- resv avec sub-pool:ip rsvp bandwidth 10000 5000

Une interface Tunnel peut indiquer la bande passante qui lui sera reservée:
Sur l'interface tunnel:
- Réservation dans le pool,
tunnel mpls traffic-eng bandwidth 1400
- Réservation dans le sub-pool,
tunnel mpls traffic-eng bandwidth sub-pool1400
La BW d'un tunnel ne peut être pris dans le pool et le sub-pool. Si les deux sont spécifiés, par défaut, seul le sub-pool est considéré.

De manière automatique:
tunnel mpls traffic-eng auto-bw
La bp effective est modifiée suivant des timers définis en global:
gsr3(config-if)# tunnel mpls traffic-eng auto-bw ?
collect-bw Just collect Bandwidth info on this tunnel
frequency Frequency to change tunnel BW
max-bw Set the Maximum Bandwidth for auto-bw on this tunnel
min-bw Set the Minimum Bandwidth for auto-bw on this tunnel

vérification de la reservation:
show ip rsvp reservation

Load Sharing:
Deux valeur peuvent être utilisées:
tunnel mpls traffic-eng bandwidth
ou
tunnel mpls traffic-eng load-share

Le ''unequal'' load sharing est possible en jouant sur les valeurs de bandwidth ou load-share de chaque tunnel:
tunnel1: tunnel mpls traffic-eng bandwidth 1000
tunnel2: tunnel mpls traffic-eng bandwidth 100
Le ratio est 1:10.
On peut aussi utiliser la seconde commande:tunnel1: tunnel mpls traffic-eng load-share 40
tunnel2: tunnel mpls traffic-eng load-share 80