21 déc. 2009

OSPF & NBMA Networks Part 2: broadcast

NBMA Networks are Frame-Relay, ATM & X.25 networks.
Multiple devices are attached but are non-broadcast.




The network type is set to 'broadcast'.
The DLCI is treaten as a broadcast link, a DR/BDR election occurs.
OSPF packets are multicast.

On R3:
!
interface Serial1/0.3456 multipoint
ip address 100.3.0.3 255.255.255.0
ip ospf network broadcast
ip ospf priority 10
frame-relay map ip 100.3.0.4 304 broadcast
frame-relay map ip 100.3.0.5 305 broadcast
frame-relay map ip 100.3.0.6 306 broadcast
!
router ospf 1
router-id 100.0.3.1
log-adjacency-changes
redistribute connected subnets
network 100.3.0.0 0.0.0.255 area 0
!

On R4:
!
interface Serial1/0.3456 multipoint
ip address 100.3.0.4 255.255.255.0
ip ospf network broadcast
ip ospf priority 0
frame-relay map ip 100.3.0.5 403
frame-relay map ip 100.3.0.6 403
frame-relay map ip 100.3.0.3 403 broadcast
!
router ospf 1
router-id 100.0.4.1
log-adjacency-changes
redistribute connected subnets
network 100.3.0.0 0.0.0.255 area 0
!

R3#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
100.0.4.1 0 FULL/DROTHER 00:00:31 100.3.0.4 Serial1/0.3456
100.0.5.1 0 FULL/DROTHER 00:00:39 100.3.0.5 Serial1/0.3456
100.0.6.1 0 FULL/DROTHER 00:00:35 100.3.0.6 Serial1/0.3456
R3#

Messages are multicast:
*Dec 21 16:49:36.231: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/0.3456 from 100.3.0.3

OSPF & NBMA Networks Part 1: point-to-multipoint

OSPF Network Type: point-to-multipoint
NBMA Networks are Frame-Relay, ATM & X.25 networks.
Multiple devices are attached but are non-broadcast.





Question
Configure OSPF on R3, R4, R5 and R6 such as no DR election occurs.




Set the network type to 'point-to-multipoint'.
The DLCI is treaten as point-to-point link, so no DR/BDR election occurs.
OSPF packets are still multicast.


On R3:
!
interface Serial1/0.3456 multipoint
 ip address 100.3.0.3 255.255.255.0
 ip ospf network point-to-multipoint
 frame-relay interface-dlci 304 
 frame-relay interface-dlci 305
 frame-relay interface-dlci 306
!
router ospf 1
 router-id 100.1.3.1
 log-adjacency-changes
 network 100.3.0.3 0.0.0.0 area 0
!


On R4:
!
interface Serial1/0.3456 multipoint
 ip address 100.3.0.4 255.255.255.0
 ip ospf network point-to-multipoint
 frame-relay interface-dlci 403
!
router ospf 1
 router-id 100.1.3.1
 log-adjacency-changes
 network 100.3.0.4 0.0.0.0 area 0
!
and so on for R5 and R6.


No DR/BDR election occurs:
R3#show ip ospf neighbor


Neighbor ID Pri State Dead Time Address Interface
100.1.5.9 0 FULL/ - 00:01:37 100.3.0.5 Serial1/0.3456
100.1.4.1 0 FULL/ - 00:01:57 100.3.0.4 Serial1/0.3456
100.1.6.1 0 FULL/ - 00:01:56 100.3.0.6 Serial1/0.3456

28 août 2009

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#

25 août 2009

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#


16 juil. 2009

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)

15 juil. 2009

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.

22 juin 2009

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#

20 juin 2009

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

19 juin 2009

Basic Traffic-Engineering configuration

Configuration Basique d'un tunnel
! En global:
mpls traffic-eng tunnels
!
! Sur les interfaces:
interface S1/0
mpls traffic-eng tunnels
mpls ip
ip rsvp bandwidth 10000
!
! Configuration de IGP:
!OSPF, utilise les ''opaque LSA'', type 10:
router ospf 1
mpls traffic-eng area 0
mpls traffic-eng router-id loopback0
!
! ISIS, utilise les TLV22, TLV134 et TLV135:
router isis
net 49.0001.0000.000a.00
metric-style wide
mpls traffic-eng router-id loopback0
mpls traffic-eng level-1
! ou
router isis
net 49.0001.0000.000a.00
metric-style wide
mpls traffic-eng router-id loopback0
mpls traffic-eng level-2
is-type level-2-only
! attention, un routeur L1/L2 se base sur la topologie L1 pour joindre un autre routeur L1/L2 car ils sont dans la même ''aire" et que se serait illogique de passer par un routeur L2.
! Un routeur L1/L2 ne peut donc faire de TE avec un autre routeur L1/L2 sans ''mpls traffic-eng level-1"
!
!Configuration (minimale) du tunnel:
interface Tunnel0
ip unnumbered Loopback0
tunnel destination 10.3.3.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 5 dynamic

!

Vérifications:
Réservations RSVP (locale):
R0#show ip rsvp interface
interface allocated i/f max flow max sub max
Se1/0 0 10M 10M 0


Allocation label:
R0#show ip rsvp reservation detail filter destination 10.3.3.1
Reservation:
Tun Dest: 10.3.3.1 Tun ID: 0 Ext Tun ID: 10.0.0.1
Tun Sender: 10.0.0.1 LSP ID: 22
Next Hop: 192.168.1.2 on Serial1/0
Label: 24 (outgoing)

Process TE:
R0#show mpls traffic-eng tunnels summary
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled


Forwarding-Table:
R0#show mpls forwarding-table
[T] signifie que le trafic passe par un tunnel.
Pour connaitre le label utilisé pour le tunnel:
show mpls forwarding-table detail


Check du tunnel:
R0#show mpls traffic-eng tunnels tunnel 0

NTP - ACL

NTP - Network Time Protocol Packet types: -  Control messages : don't bother with this. -  NTP request/update messages: used for time sy...