************************************************************************* LDP ****************************************************************************************************
42> Two types of LDP:-
Link LDP is used to establish transport tunnnels and T_LDP is used to transport service tunnels.
43> During the initial discovery phase LDP sends hello messages to the destination multicast address of 224.0.0.2 and the well known udp port of 646. After the routers discover each other hellos are sent to keep the adjacency alive.
44> A single LDP session exists between two peers although there might be multiple peers.
45> Link ldp sessions are created between all the adjacent routers leading to a full mesh of ldp tunnels.
46> config router ldp#
Interface-parameters
Interface x
47> The hello messages are sent to 224.0.0.2 to ensure that if several routers are attached to the same broadcast domain everone should receive that.
48> Parameters included in the hello messages:-
Version=1
LDP ID (explained later)
Message type:- Hello
Hello Timeout=15 secs
Transport address
Configuration Sequence number
49> LDP identifier is a six octet field the first 4 octets identify the LSR and is globally unique generally the system ip address of the router the last two octets identify the label space and is set to 0 for platform wide. Per interface label space is used if we are using ATM or FR or a combination of Ethernet and ATM/FR.
----------------------------------------------------------------
| | |
|LSR-id (4 bytes) | Label space ID (2 bytes) |
----------------------------------------------------------------
50> Example :-
| Router 1| ------------------------------------------- | Router 2|
10.10.10.4 10.10.10.6
LDP id:- 10.10.10.4:0 LDP-ID 10.10.10.6:0
Transport address:- 10.10.10.4 Transport address:- 10.10.10.6
Message Type:- Hello Message Type:- Hello
Hello Timeout=15 secs Hello Timeout=15 secs
Configration Sequence number Configuration Sequence number
51>Hello Timeout:- Routers continue to exchange hellos the neighbor is considered down if no hellos are received within the timeout period.
52> Configuration Sequence number is used to detect configuration changes on the sending LSR.
53> Hello Timeout by default is 15 secs and the hello factor is 3 so 15/3=5 hence each hello messages are sent after 5 secs.
54> If the router have multiple interfaces a separate set of hello messages are sent for each of the interfaces.
Config>router>ldp
Hello <timeout> <factor> <============= Global applies for all the interfaces
Interface parameters
Interface xxx
Hello <timeout> < factor> <================ Applied at the interface level over-rides the global setting
55> The hellos on both sides of the peer need not match, a negotiation takes place where the lower value is selected.
56> The status of the discovery message can be seen from show router ldp discovery detail.
State of the discovery message
Hold Time Remaining
Hello Sent and Hello Received
Local and Remote ip address
57> After the discovery process is completed, one side of the peer assumes the active role and initiates a TCP session with the neighbouring peer transport address, always the peer with the higher transport address takes that role.
58> The TCP port used is 646
59> Which ip address the routers choose to establish the session with this is also exchanged during the exchange of the hello message.
60> Two cell mode interfaces two sessions are established
Frame mode and Cell mode interface two sessions
Frame mode & Frame mode one session is established.
61> By default the transport address is set to the system ip address however this can be modified this is generally done for interoperability reasons.
62> config > router>ldp#
Interface xxx
transport address xxx <========== xxx is the name of the interface ???
63> show router ldp session <========= Provides the status of the LDP session
show router ldp session detail
64> The TCP session is established with the init messages
R1----------------------------------------------------------- R2
Dest ip = R2 transport address Dest ip =R1 transport address
TCP dest port= 646 Dst port= Any random
Source port=Any source port Source port=646
LDP-Id
Keepalive timeout Same as in R2
Message Type
Session Parameters
65> The session is established only after it receives a keep-alive message from R2.
66> Link failure lower layer protocols generally detect and inform the upper layer protocols however in case of corner case situations keepalives are also sent between the nodes hence
Keepalive are generally sent and received to maintain the TCP session.
67> config> router> ldo#
keepalive 90 3
interface parameters
interface abc
keepalive 30 3
By default it 30/3=10 seconds ie keepalive are by default sent every 10 seconds.
68> LDP sessions will be established even if the keep-alive between the routers do not match the lower one is considered.
69> By default once an LDP is established labels are generated for the system ip address and are advertised to the neighbor.
70> Link ldp sessions are created between the adjacent routers labels will be flooded and a full mesh of transport tunnels will be created.
71> show router ldp parameters
Downstream Unsolicited:- Labels are distributed to all LDP peers
Ordered Control:- A peer generates its own label for the system ip address by default, and it will also generate its own label for the peer system ip address only after it receves one from its peer.
Liberal Label retention:- All the labels are retained in the control plane, however one label is used in the data plane.
72> R4------------- R5 (5.5.5.5/32)
|
|
|
R6
For the system ip address 5.5.5.5/32 this is advertised to R4 and R6 with the same label space.
73> DU mode hence no requests are required from R4 or R6 the labels are advertised with the help of the label mapping message.
74> Labels are stored in the control plane in show router ldp bindings
Egress label:- Label which it has received from its peer for a particular FEC
Ingress Label:- Label which is locally generated.
75> If there is no ingress label for a particular prefix it means that the tunnel terminates on that particular PE.
76> Label Mapping messagE:-
Version
LDP-id
FeC
Label
Message Type:- Label maping (ox400)
77> The fib entries contains the active ip next hop information, it does not contain any redundant entries, the labels for the active next hop are placed in LFIB.
78> LIB:-
show router ldp bindings========> LIB
show router fib 1 =============> FIB entries on IOM 1
show router ldp bindings active ===========> LFIB
79> R4------------- R5 (5.5.5.5/32)
|
|
|
R6 (6.6.6.6/32)
R6 will advertise a label mapping message to R5, R5 after receiving the label mapping message will generate its own label for the FEC 6.6.6.6/32 and advertise it to R4.
Label advertised by R6 will be the ingress label for R6 and ingress label for R5.
A:R4# show router ldp bindings
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix Peer IngLbl EgrLbl EgrIntf/ EgrNextHop
-------------------------------------------------------------------------------
10.10.10.6/32 10.10.10.2 131070 -- -- --
10.10.10.6/32 10.10.10.5 131070 -- -- --
10.10.10.6/32 10.10.10.6 -- 131071 1/1/4 10.4.6.6
-------------------------------------------------------------------------------
80> In LDP the labels are flooded hence R4 receives a label from both R5 and R2 as seen in the above topology these labels are present in LIB as it works Liberal label retention mode, this helps to decrease the failure times, in case an interface becomes unavailable.
81> All the labels are present in the LIB however the labels from the active next hop are present in the ldp bindings active.
82> All the traffic hitting a particular SAP,which belongs to a service will always be label switched.
83>
As we can see in the above output R1 uses R2 as the next hop to reach 10.10.10.6 hence the Egress label used is 131068, however R1 also advertises a label to R2 for the prefix 10.10.10.6/32 however presently the label will not be in use as R2 will already the next hop to reach that prefix, this label will only be used if all the links from R2 to R6 is not available.
84> Since R3 is not the preferred next hop to reach R6 it is marked as used with an U.
85> R1 will also install a label with the swap option, ie if it becomes an LSR for a particular prefix.
86>Given below is an example where R1 can act as an LSR:-
87> show router tunnel-table displays all the tunnels that are available on a particular node the Metric displayed is the IGP metric.
88> LSP-Ping:- Checks the reachability of the prefix through the LDP tunnel unidirectionally in one direction only.
89> oam lsp-ping prefix 10.10.1.6/32
By default only 1 packets are sent this can be increased by using the send-count command
90> This contains MPLS echo request and MPLs echo reply packets, the echo request packets are encapsulated within the MPLS labels. The TTL is set to 255.
91> MPLS echo request are sent over UDP with a destination port of 3503.
92> Echo reply does not use the tunnel and is ip routed the source port used is 3503 and a destination port is arbitarily chosen.
93>
RTT===> Round trip delay this is the time taken between sending the echo request and getting a reply back.
94> RC==> Return code used by the egress router to indicate the status of the prefix, RC=3 the egress router has learned that it has this prefix.
95> oam lsp-trace prefix x.x.x.x/32
96> Used to gather hop information along the LSP path.
97> Separate request packets are sent per downstream router the MPLS TTL value is incremented at each request.
98> RC=8 (DSR Match label):- This is seen in the intermediate routers ie the intermediate routers is able to locate an downstream label for the incoming label.
99> RC=3 This is the owner of the prefix.
100>
R1 first MPLS echo request with a TTL=1, R2 consumes the packet and gives a reply back to R1. The echo reply sent by R2 is ip-routed.
101> R1 again sends a Echo request with a TTL=2, this is consumed by R4.
102> If ecmp is not enabled and we have redundant paths to a destination address with the same cost the lowest next hop for the directly connected interface address is used.
103> config>router>ecmp < number of routes>
Multiple entries for the LFIB is installed for a particular prefix.
Two different labels are installed for the same prefix
104> A hashing algorithm distrbutes the traffic between the two links.
105> Only a label is distributed for the system address by default, if need be an export policy can be created to distribute labels for the other interfaces also.
106> config router policy-options
begin
prefix-list prefix x.x.x.x/24 longer /exact
Policy-statement export
Entry 1
from prefix-lisr prefix
exit
action accept
Commit
Config router ldp
Export export
From protocol direct
Action accept can also be used.
107> Certain label bindings can be rejected upon receipt for this we need to create an export policy.
108> Generally still the routers keep the labels but do not generate its own bindings foethose labels,
109>Hence the labels will be present in the LIB but not the LFIB.
110> The following is used to reject all the prefixes.
111> An LDP router can instruct its peers to release a particular label which it has advertised before this is done with the help of label withdraw message.
112> When a label withdraw message is received from the peer, the peer responds with the label release message as provided in the below snapshot:-
113> As seen a network goes down beyond R6 hence a label withdraw message is advertised by R6.
114> Label withdraw message can be sent for the folllowing reasons:-
An MTU change on the interface causes a router to withdrawal the previously assigned label and re-signal the FEC
with the new MTU.
A network change, such as a failed interface, causes the router to remove a FEC from its FIB. The router had
previously generated and advertised a label for this FEC.
The router is configured to stop generating labels for specified FECs (for example, the removal of the export
policy).
A service manager command is issued to clear the labels, the labels are withdrawn, and new label mappings are
issued (for example, clear router ldp instance).
115> Label Release message is generated for the folowing reasons:-
The LSR receives a label withdraw message from a peer.
The LSR operates in Conservative label retention mode, and receives a label from a peer that is not the next-hop
router for the FEC.
The LSR operates in Conservative label retention mode, and the peer from whom it received the label for a FEC is
no longer the next-hop router for that FEC (for example, the result of a network failure or topological change).
There is no more memory to store a received label and the label is released.
116>
In the above scenario there are 2 /32 prefixes which are being advertised and we are summarizing the routes to 192.168.6.0/24 before being advertised to area 0.
117> Hence only 1 label will be generated for the prefix 192.168.6.0. Hence the traffic will not be able to reach the prefixes mentioned above.
118> Labels will be present in LIB, however none of them will be advertised in LFIB
119> The following command can be used to fix such situations.
Config router ldp aggregate-prefix-match
Given below is an exampls:-
***************************************************************** Targeted LDP*************************************************************************************************
120 > T-LDP is used to create the service tunnels, T_LDP advertises the service labels which is used to demultiplex the traffic and based on the labels associate them to proper services.
121> Peers do not have to be directly connected (typically established
between 2 PE routers that have services configured)
Also used in the LDP over RSVP solution.
122> For a Layer 3 (IP) VPN Service, the service labels are signaled via the MP-BGP (Multi-Protocol Border Gateway Protocol).
Targeted LDP is not utilized in pure Layer 3 VPN service environments.
123> The following snapshot provides a view of session establishment between two LDP peers:-
124>
The above command is used during the configuration of L3 VPN.
125> Targeted session can be automatically created during the configuration of SDP or can also be created manually.
The above command should be executed both the sides or the sdp should be configured both the sides for the session to establish.
126>These are the reasons for which T_LDP can also be configured manually.
The operator may want to modify the session parameters (such as hello or keepalive timeout) from the default
values (see the example on the next page).
The operator may want to avoid peering with certain routers, probably those under a different administration (see
the example on the next page).
The targeted LDP session might be required for a special feature called LDP over RSVP-TE (discussed in Module 5 of
this course).
The targeted LDP session might have to be manually specified for interoperability reasons, if required by another
router vendor.
127> Given below is a snapshot of different LDP label types:-
128>
Given below are some of the commands used to verify the ldp session:-
Show router ldp peer
129>Auto Created:- No displays the ldp session is manually created.
130 >It also displays the KA interval and KA timeout
131> show router ldp peers displays the status of the LDP peers.
132>Link, Targeted or Both can be displayed depending upon the type of adjacency.
133>The show router ldp status command output displays the general statistics regarding the LDP process.
“Active Adjacencies” indicates successfully discovered Link LDP and Targeted LDP peers (via Hello messages).
“Active Sessions” indicates successfully established Link LDP and Targeted LDP sessions (via Init and Keepalive
messages).
“Active Interfaces” indicates the number of core interfaces on which Link LDP is enabled.
“Active Peers” indicates the number of active Targeted LDP peers that are provisioned via either manual or automatic
methods.
Again, note that a session does not need to be established for a peer to be listed.
Peers need not be established to be listed.
134> LDP authenticaion can be enabled to prevent LDP from TCP spoofing attacks
This is an MD5 based autthentication and the password are never sent through the wire as clear text.
*A:R1>config>router>ldp# info
----------------------------------------------
peer-parameters
peer 10.10.10.2
authentication-key "7ZooHlzw8OE8Hs6IKYJ1kiES27LcfN23" hash2
exit
Exit
************************************************************************* LDP ****************************************************************************************************
42> Two types of LDP:-
Link LDP is used to establish transport tunnnels and T_LDP is used to transport service tunnels.
43> During the initial discovery phase LDP sends hello messages to the destination multicast address of 224.0.0.2 and the well known udp port of 646. After the routers discover each other hellos are sent to keep the adjacency alive.
44> A single LDP session exists between two peers although there might be multiple peers.
45> Link ldp sessions are created between all the adjacent routers leading to a full mesh of ldp tunnels.
46> config router ldp#
Interface-parameters
Interface x
47> The hello messages are sent to 224.0.0.2 to ensure that if several routers are attached to the same broadcast domain everone should receive that.
48> Parameters included in the hello messages:-
Version=1
LDP ID (explained later)
Message type:- Hello
Hello Timeout=15 secs
Transport address
Configuration Sequence number
49> LDP identifier is a six octet field the first 4 octets identify the LSR and is globally unique generally the system ip address of the router the last two octets identify the label space and is set to 0 for platform wide. Per interface label space is used if we are using ATM or FR or a combination of Ethernet and ATM/FR.
----------------------------------------------------------------
| | |
|LSR-id (4 bytes) | Label space ID (2 bytes) |
----------------------------------------------------------------
50> Example :-
| Router 1| ------------------------------------------- | Router 2|
10.10.10.4 10.10.10.6
LDP id:- 10.10.10.4:0 LDP-ID 10.10.10.6:0
Transport address:- 10.10.10.4 Transport address:- 10.10.10.6
Message Type:- Hello Message Type:- Hello
Hello Timeout=15 secs Hello Timeout=15 secs
Configration Sequence number Configuration Sequence number
51>Hello Timeout:- Routers continue to exchange hellos the neighbor is considered down if no hellos are received within the timeout period.
52> Configuration Sequence number is used to detect configuration changes on the sending LSR.
53> Hello Timeout by default is 15 secs and the hello factor is 3 so 15/3=5 hence each hello messages are sent after 5 secs.
54> If the router have multiple interfaces a separate set of hello messages are sent for each of the interfaces.
Config>router>ldp
Hello <timeout> <factor> <============= Global applies for all the interfaces
Interface parameters
Interface xxx
Hello <timeout> < factor> <================ Applied at the interface level over-rides the global setting
55> The hellos on both sides of the peer need not match, a negotiation takes place where the lower value is selected.
56> The status of the discovery message can be seen from show router ldp discovery detail.
State of the discovery message
Hold Time Remaining
Hello Sent and Hello Received
Local and Remote ip address
57> After the discovery process is completed, one side of the peer assumes the active role and initiates a TCP session with the neighbouring peer transport address, always the peer with the higher transport address takes that role.
58> The TCP port used is 646
59> Which ip address the routers choose to establish the session with this is also exchanged during the exchange of the hello message.
60> Two cell mode interfaces two sessions are established
Frame mode and Cell mode interface two sessions
Frame mode & Frame mode one session is established.
61> By default the transport address is set to the system ip address however this can be modified this is generally done for interoperability reasons.
62> config > router>ldp#
Interface xxx
transport address xxx <========== xxx is the name of the interface ???
63> show router ldp session <========= Provides the status of the LDP session
show router ldp session detail
64> The TCP session is established with the init messages
R1----------------------------------------------------------- R2
Dest ip = R2 transport address Dest ip =R1 transport address
TCP dest port= 646 Dst port= Any random
Source port=Any source port Source port=646
LDP-Id
Keepalive timeout Same as in R2
Message Type
Session Parameters
65> The session is established only after it receives a keep-alive message from R2.
66> Link failure lower layer protocols generally detect and inform the upper layer protocols however in case of corner case situations keepalives are also sent between the nodes hence
Keepalive are generally sent and received to maintain the TCP session.
67> config> router> ldo#
keepalive 90 3
interface parameters
interface abc
keepalive 30 3
By default it 30/3=10 seconds ie keepalive are by default sent every 10 seconds.
68> LDP sessions will be established even if the keep-alive between the routers do not match the lower one is considered.
69> By default once an LDP is established labels are generated for the system ip address and are advertised to the neighbor.
70> Link ldp sessions are created between the adjacent routers labels will be flooded and a full mesh of transport tunnels will be created.
71> show router ldp parameters
Downstream Unsolicited:- Labels are distributed to all LDP peers
Ordered Control:- A peer generates its own label for the system ip address by default, and it will also generate its own label for the peer system ip address only after it receves one from its peer.
Liberal Label retention:- All the labels are retained in the control plane, however one label is used in the data plane.
72> R4------------- R5 (5.5.5.5/32)
|
|
|
R6
For the system ip address 5.5.5.5/32 this is advertised to R4 and R6 with the same label space.
73> DU mode hence no requests are required from R4 or R6 the labels are advertised with the help of the label mapping message.
74> Labels are stored in the control plane in show router ldp bindings
Egress label:- Label which it has received from its peer for a particular FEC
Ingress Label:- Label which is locally generated.
75> If there is no ingress label for a particular prefix it means that the tunnel terminates on that particular PE.
76> Label Mapping messagE:-
Version
LDP-id
FeC
Label
Message Type:- Label maping (ox400)
77> The fib entries contains the active ip next hop information, it does not contain any redundant entries, the labels for the active next hop are placed in LFIB.
78> LIB:-
show router ldp bindings========> LIB
show router fib 1 =============> FIB entries on IOM 1
show router ldp bindings active ===========> LFIB
79> R4------------- R5 (5.5.5.5/32)
|
|
|
R6 (6.6.6.6/32)
R6 will advertise a label mapping message to R5, R5 after receiving the label mapping message will generate its own label for the FEC 6.6.6.6/32 and advertise it to R4.
Label advertised by R6 will be the ingress label for R6 and ingress label for R5.
A:R4# show router ldp bindings
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix Peer IngLbl EgrLbl EgrIntf/ EgrNextHop
-------------------------------------------------------------------------------
10.10.10.6/32 10.10.10.2 131070 -- -- --
10.10.10.6/32 10.10.10.5 131070 -- -- --
10.10.10.6/32 10.10.10.6 -- 131071 1/1/4 10.4.6.6
-------------------------------------------------------------------------------
80> In LDP the labels are flooded hence R4 receives a label from both R5 and R2 as seen in the above topology these labels are present in LIB as it works Liberal label retention mode, this helps to decrease the failure times, in case an interface becomes unavailable.
81> All the labels are present in the LIB however the labels from the active next hop are present in the ldp bindings active.
82> All the traffic hitting a particular SAP,which belongs to a service will always be label switched.
83>
As we can see in the above output R1 uses R2 as the next hop to reach 10.10.10.6 hence the Egress label used is 131068, however R1 also advertises a label to R2 for the prefix 10.10.10.6/32 however presently the label will not be in use as R2 will already the next hop to reach that prefix, this label will only be used if all the links from R2 to R6 is not available.
84> Since R3 is not the preferred next hop to reach R6 it is marked as used with an U.
85> R1 will also install a label with the swap option, ie if it becomes an LSR for a particular prefix.
86>Given below is an example where R1 can act as an LSR:-
87> show router tunnel-table displays all the tunnels that are available on a particular node the Metric displayed is the IGP metric.
88> LSP-Ping:- Checks the reachability of the prefix through the LDP tunnel unidirectionally in one direction only.
89> oam lsp-ping prefix 10.10.1.6/32
By default only 1 packets are sent this can be increased by using the send-count command
90> This contains MPLS echo request and MPLs echo reply packets, the echo request packets are encapsulated within the MPLS labels. The TTL is set to 255.
91> MPLS echo request are sent over UDP with a destination port of 3503.
92> Echo reply does not use the tunnel and is ip routed the source port used is 3503 and a destination port is arbitarily chosen.
93>
RTT===> Round trip delay this is the time taken between sending the echo request and getting a reply back.
94> RC==> Return code used by the egress router to indicate the status of the prefix, RC=3 the egress router has learned that it has this prefix.
95> oam lsp-trace prefix x.x.x.x/32
96> Used to gather hop information along the LSP path.
97> Separate request packets are sent per downstream router the MPLS TTL value is incremented at each request.
98> RC=8 (DSR Match label):- This is seen in the intermediate routers ie the intermediate routers is able to locate an downstream label for the incoming label.
99> RC=3 This is the owner of the prefix.
100>
R1 first MPLS echo request with a TTL=1, R2 consumes the packet and gives a reply back to R1. The echo reply sent by R2 is ip-routed.
101> R1 again sends a Echo request with a TTL=2, this is consumed by R4.
102> If ecmp is not enabled and we have redundant paths to a destination address with the same cost the lowest next hop for the directly connected interface address is used.
103> config>router>ecmp < number of routes>
Multiple entries for the LFIB is installed for a particular prefix.
Two different labels are installed for the same prefix
104> A hashing algorithm distrbutes the traffic between the two links.
105> Only a label is distributed for the system address by default, if need be an export policy can be created to distribute labels for the other interfaces also.
106> config router policy-options
begin
prefix-list prefix x.x.x.x/24 longer /exact
Policy-statement export
Entry 1
from prefix-lisr prefix
exit
action accept
Commit
Config router ldp
Export export
From protocol direct
Action accept can also be used.
107> Certain label bindings can be rejected upon receipt for this we need to create an export policy.
108> Generally still the routers keep the labels but do not generate its own bindings foethose labels,
109>Hence the labels will be present in the LIB but not the LFIB.
110> The following is used to reject all the prefixes.
111> An LDP router can instruct its peers to release a particular label which it has advertised before this is done with the help of label withdraw message.
112> When a label withdraw message is received from the peer, the peer responds with the label release message as provided in the below snapshot:-
113> As seen a network goes down beyond R6 hence a label withdraw message is advertised by R6.
114> Label withdraw message can be sent for the folllowing reasons:-
An MTU change on the interface causes a router to withdrawal the previously assigned label and re-signal the FEC
with the new MTU.
A network change, such as a failed interface, causes the router to remove a FEC from its FIB. The router had
previously generated and advertised a label for this FEC.
The router is configured to stop generating labels for specified FECs (for example, the removal of the export
policy).
A service manager command is issued to clear the labels, the labels are withdrawn, and new label mappings are
issued (for example, clear router ldp instance).
115> Label Release message is generated for the folowing reasons:-
The LSR receives a label withdraw message from a peer.
The LSR operates in Conservative label retention mode, and receives a label from a peer that is not the next-hop
router for the FEC.
The LSR operates in Conservative label retention mode, and the peer from whom it received the label for a FEC is
no longer the next-hop router for that FEC (for example, the result of a network failure or topological change).
There is no more memory to store a received label and the label is released.
116>
In the above scenario there are 2 /32 prefixes which are being advertised and we are summarizing the routes to 192.168.6.0/24 before being advertised to area 0.
117> Hence only 1 label will be generated for the prefix 192.168.6.0. Hence the traffic will not be able to reach the prefixes mentioned above.
118> Labels will be present in LIB, however none of them will be advertised in LFIB
119> The following command can be used to fix such situations.
Config router ldp aggregate-prefix-match
Given below is an exampls:-
***************************************************************** Targeted LDP*************************************************************************************************
120 > T-LDP is used to create the service tunnels, T_LDP advertises the service labels which is used to demultiplex the traffic and based on the labels associate them to proper services.
121> Peers do not have to be directly connected (typically established
between 2 PE routers that have services configured)
Also used in the LDP over RSVP solution.
122> For a Layer 3 (IP) VPN Service, the service labels are signaled via the MP-BGP (Multi-Protocol Border Gateway Protocol).
Targeted LDP is not utilized in pure Layer 3 VPN service environments.
123> The following snapshot provides a view of session establishment between two LDP peers:-
124>
The above command is used during the configuration of L3 VPN.
125> Targeted session can be automatically created during the configuration of SDP or can also be created manually.
The above command should be executed both the sides or the sdp should be configured both the sides for the session to establish.
126>These are the reasons for which T_LDP can also be configured manually.
The operator may want to modify the session parameters (such as hello or keepalive timeout) from the default
values (see the example on the next page).
The operator may want to avoid peering with certain routers, probably those under a different administration (see
the example on the next page).
The targeted LDP session might be required for a special feature called LDP over RSVP-TE (discussed in Module 5 of
this course).
The targeted LDP session might have to be manually specified for interoperability reasons, if required by another
router vendor.
127> Given below is a snapshot of different LDP label types:-
128>
Given below are some of the commands used to verify the ldp session:-
Show router ldp peer
129>Auto Created:- No displays the ldp session is manually created.
130 >It also displays the KA interval and KA timeout
131> show router ldp peers displays the status of the LDP peers.
132>Link, Targeted or Both can be displayed depending upon the type of adjacency.
133>The show router ldp status command output displays the general statistics regarding the LDP process.
“Active Adjacencies” indicates successfully discovered Link LDP and Targeted LDP peers (via Hello messages).
“Active Sessions” indicates successfully established Link LDP and Targeted LDP sessions (via Init and Keepalive
messages).
“Active Interfaces” indicates the number of core interfaces on which Link LDP is enabled.
“Active Peers” indicates the number of active Targeted LDP peers that are provisioned via either manual or automatic
methods.
Again, note that a session does not need to be established for a peer to be listed.
Peers need not be established to be listed.
134> LDP authenticaion can be enabled to prevent LDP from TCP spoofing attacks
This is an MD5 based autthentication and the password are never sent through the wire as clear text.
*A:R1>config>router>ldp# info
----------------------------------------------
peer-parameters
peer 10.10.10.2
authentication-key "7ZooHlzw8OE8Hs6IKYJ1kiES27LcfN23" hash2
exit
Exit
42> Two types of LDP:-
Link LDP is used to establish transport tunnnels and T_LDP is used to transport service tunnels.
43> During the initial discovery phase LDP sends hello messages to the destination multicast address of 224.0.0.2 and the well known udp port of 646. After the routers discover each other hellos are sent to keep the adjacency alive.
44> A single LDP session exists between two peers although there might be multiple peers.
45> Link ldp sessions are created between all the adjacent routers leading to a full mesh of ldp tunnels.
46> config router ldp#
Interface-parameters
Interface x
47> The hello messages are sent to 224.0.0.2 to ensure that if several routers are attached to the same broadcast domain everone should receive that.
48> Parameters included in the hello messages:-
Version=1
LDP ID (explained later)
Message type:- Hello
Hello Timeout=15 secs
Transport address
Configuration Sequence number
49> LDP identifier is a six octet field the first 4 octets identify the LSR and is globally unique generally the system ip address of the router the last two octets identify the label space and is set to 0 for platform wide. Per interface label space is used if we are using ATM or FR or a combination of Ethernet and ATM/FR.
----------------------------------------------------------------
| | |
|LSR-id (4 bytes) | Label space ID (2 bytes) |
----------------------------------------------------------------
50> Example :-
| Router 1| ------------------------------------------- | Router 2|
10.10.10.4 10.10.10.6
LDP id:- 10.10.10.4:0 LDP-ID 10.10.10.6:0
Transport address:- 10.10.10.4 Transport address:- 10.10.10.6
Message Type:- Hello Message Type:- Hello
Hello Timeout=15 secs Hello Timeout=15 secs
Configration Sequence number Configuration Sequence number
51>Hello Timeout:- Routers continue to exchange hellos the neighbor is considered down if no hellos are received within the timeout period.
52> Configuration Sequence number is used to detect configuration changes on the sending LSR.
53> Hello Timeout by default is 15 secs and the hello factor is 3 so 15/3=5 hence each hello messages are sent after 5 secs.
54> If the router have multiple interfaces a separate set of hello messages are sent for each of the interfaces.
Config>router>ldp
Hello <timeout> <factor> <============= Global applies for all the interfaces
Interface parameters
Interface xxx
Hello <timeout> < factor> <================ Applied at the interface level over-rides the global setting
55> The hellos on both sides of the peer need not match, a negotiation takes place where the lower value is selected.
56> The status of the discovery message can be seen from show router ldp discovery detail.
State of the discovery message
Hold Time Remaining
Hello Sent and Hello Received
Local and Remote ip address
57> After the discovery process is completed, one side of the peer assumes the active role and initiates a TCP session with the neighbouring peer transport address, always the peer with the higher transport address takes that role.
58> The TCP port used is 646
59> Which ip address the routers choose to establish the session with this is also exchanged during the exchange of the hello message.
60> Two cell mode interfaces two sessions are established
Frame mode and Cell mode interface two sessions
Frame mode & Frame mode one session is established.
61> By default the transport address is set to the system ip address however this can be modified this is generally done for interoperability reasons.
62> config > router>ldp#
Interface xxx
transport address xxx <========== xxx is the name of the interface ???
63> show router ldp session <========= Provides the status of the LDP session
show router ldp session detail
64> The TCP session is established with the init messages
R1----------------------------------------------------------- R2
Dest ip = R2 transport address Dest ip =R1 transport address
TCP dest port= 646 Dst port= Any random
Source port=Any source port Source port=646
LDP-Id
Keepalive timeout Same as in R2
Message Type
Session Parameters
65> The session is established only after it receives a keep-alive message from R2.
66> Link failure lower layer protocols generally detect and inform the upper layer protocols however in case of corner case situations keepalives are also sent between the nodes hence
Keepalive are generally sent and received to maintain the TCP session.
67> config> router> ldo#
keepalive 90 3
interface parameters
interface abc
keepalive 30 3
By default it 30/3=10 seconds ie keepalive are by default sent every 10 seconds.
68> LDP sessions will be established even if the keep-alive between the routers do not match the lower one is considered.
69> By default once an LDP is established labels are generated for the system ip address and are advertised to the neighbor.
70> Link ldp sessions are created between the adjacent routers labels will be flooded and a full mesh of transport tunnels will be created.
71> show router ldp parameters
Downstream Unsolicited:- Labels are distributed to all LDP peers
Ordered Control:- A peer generates its own label for the system ip address by default, and it will also generate its own label for the peer system ip address only after it receves one from its peer.
Liberal Label retention:- All the labels are retained in the control plane, however one label is used in the data plane.
72> R4------------- R5 (5.5.5.5/32)
|
|
|
R6
For the system ip address 5.5.5.5/32 this is advertised to R4 and R6 with the same label space.
73> DU mode hence no requests are required from R4 or R6 the labels are advertised with the help of the label mapping message.
74> Labels are stored in the control plane in show router ldp bindings
Egress label:- Label which it has received from its peer for a particular FEC
Ingress Label:- Label which is locally generated.
75> If there is no ingress label for a particular prefix it means that the tunnel terminates on that particular PE.
76> Label Mapping messagE:-
Version
LDP-id
FeC
Label
Message Type:- Label maping (ox400)
77> The fib entries contains the active ip next hop information, it does not contain any redundant entries, the labels for the active next hop are placed in LFIB.
78> LIB:-
show router ldp bindings========> LIB
show router fib 1 =============> FIB entries on IOM 1
show router ldp bindings active ===========> LFIB
79> R4------------- R5 (5.5.5.5/32)
|
|
|
R6 (6.6.6.6/32)
R6 will advertise a label mapping message to R5, R5 after receiving the label mapping message will generate its own label for the FEC 6.6.6.6/32 and advertise it to R4.
Label advertised by R6 will be the ingress label for R6 and ingress label for R5.
A:R4# show router ldp bindings
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix Peer IngLbl EgrLbl EgrIntf/ EgrNextHop
-------------------------------------------------------------------------------
10.10.10.6/32 10.10.10.2 131070 -- -- --
10.10.10.6/32 10.10.10.5 131070 -- -- --
10.10.10.6/32 10.10.10.6 -- 131071 1/1/4 10.4.6.6
-------------------------------------------------------------------------------
80> In LDP the labels are flooded hence R4 receives a label from both R5 and R2 as seen in the above topology these labels are present in LIB as it works Liberal label retention mode, this helps to decrease the failure times, in case an interface becomes unavailable.
81> All the labels are present in the LIB however the labels from the active next hop are present in the ldp bindings active.
82> All the traffic hitting a particular SAP,which belongs to a service will always be label switched.
83>
As we can see in the above output R1 uses R2 as the next hop to reach 10.10.10.6 hence the Egress label used is 131068, however R1 also advertises a label to R2 for the prefix 10.10.10.6/32 however presently the label will not be in use as R2 will already the next hop to reach that prefix, this label will only be used if all the links from R2 to R6 is not available.
84> Since R3 is not the preferred next hop to reach R6 it is marked as used with an U.
85> R1 will also install a label with the swap option, ie if it becomes an LSR for a particular prefix.
86>Given below is an example where R1 can act as an LSR:-
87> show router tunnel-table displays all the tunnels that are available on a particular node the Metric displayed is the IGP metric.
88> LSP-Ping:- Checks the reachability of the prefix through the LDP tunnel unidirectionally in one direction only.
89> oam lsp-ping prefix 10.10.1.6/32
By default only 1 packets are sent this can be increased by using the send-count command
90> This contains MPLS echo request and MPLs echo reply packets, the echo request packets are encapsulated within the MPLS labels. The TTL is set to 255.
91> MPLS echo request are sent over UDP with a destination port of 3503.
92> Echo reply does not use the tunnel and is ip routed the source port used is 3503 and a destination port is arbitarily chosen.
93>
RTT===> Round trip delay this is the time taken between sending the echo request and getting a reply back.
94> RC==> Return code used by the egress router to indicate the status of the prefix, RC=3 the egress router has learned that it has this prefix.
95> oam lsp-trace prefix x.x.x.x/32
96> Used to gather hop information along the LSP path.
97> Separate request packets are sent per downstream router the MPLS TTL value is incremented at each request.
98> RC=8 (DSR Match label):- This is seen in the intermediate routers ie the intermediate routers is able to locate an downstream label for the incoming label.
99> RC=3 This is the owner of the prefix.
100>
R1 first MPLS echo request with a TTL=1, R2 consumes the packet and gives a reply back to R1. The echo reply sent by R2 is ip-routed.
101> R1 again sends a Echo request with a TTL=2, this is consumed by R4.
102> If ecmp is not enabled and we have redundant paths to a destination address with the same cost the lowest next hop for the directly connected interface address is used.
103> config>router>ecmp < number of routes>
Multiple entries for the LFIB is installed for a particular prefix.
Two different labels are installed for the same prefix
104> A hashing algorithm distrbutes the traffic between the two links.
105> Only a label is distributed for the system address by default, if need be an export policy can be created to distribute labels for the other interfaces also.
106> config router policy-options
begin
prefix-list prefix x.x.x.x/24 longer /exact
Policy-statement export
Entry 1
from prefix-lisr prefix
exit
action accept
Commit
Config router ldp
Export export
From protocol direct
Action accept can also be used.
107> Certain label bindings can be rejected upon receipt for this we need to create an export policy.
108> Generally still the routers keep the labels but do not generate its own bindings foethose labels,
109>Hence the labels will be present in the LIB but not the LFIB.
110> The following is used to reject all the prefixes.
111> An LDP router can instruct its peers to release a particular label which it has advertised before this is done with the help of label withdraw message.
112> When a label withdraw message is received from the peer, the peer responds with the label release message as provided in the below snapshot:-
113> As seen a network goes down beyond R6 hence a label withdraw message is advertised by R6.
114> Label withdraw message can be sent for the folllowing reasons:-
An MTU change on the interface causes a router to withdrawal the previously assigned label and re-signal the FEC
with the new MTU.
A network change, such as a failed interface, causes the router to remove a FEC from its FIB. The router had
previously generated and advertised a label for this FEC.
The router is configured to stop generating labels for specified FECs (for example, the removal of the export
policy).
A service manager command is issued to clear the labels, the labels are withdrawn, and new label mappings are
issued (for example, clear router ldp instance).
115> Label Release message is generated for the folowing reasons:-
The LSR receives a label withdraw message from a peer.
The LSR operates in Conservative label retention mode, and receives a label from a peer that is not the next-hop
router for the FEC.
The LSR operates in Conservative label retention mode, and the peer from whom it received the label for a FEC is
no longer the next-hop router for that FEC (for example, the result of a network failure or topological change).
There is no more memory to store a received label and the label is released.
116>
In the above scenario there are 2 /32 prefixes which are being advertised and we are summarizing the routes to 192.168.6.0/24 before being advertised to area 0.
117> Hence only 1 label will be generated for the prefix 192.168.6.0. Hence the traffic will not be able to reach the prefixes mentioned above.
118> Labels will be present in LIB, however none of them will be advertised in LFIB
119> The following command can be used to fix such situations.
Config router ldp aggregate-prefix-match
Given below is an exampls:-
***************************************************************** Targeted LDP*************************************************************************************************
120 > T-LDP is used to create the service tunnels, T_LDP advertises the service labels which is used to demultiplex the traffic and based on the labels associate them to proper services.
121> Peers do not have to be directly connected (typically established
between 2 PE routers that have services configured)
Also used in the LDP over RSVP solution.
122> For a Layer 3 (IP) VPN Service, the service labels are signaled via the MP-BGP (Multi-Protocol Border Gateway Protocol).
Targeted LDP is not utilized in pure Layer 3 VPN service environments.
123> The following snapshot provides a view of session establishment between two LDP peers:-
124>
The above command is used during the configuration of L3 VPN.
125> Targeted session can be automatically created during the configuration of SDP or can also be created manually.
The above command should be executed both the sides or the sdp should be configured both the sides for the session to establish.
126>These are the reasons for which T_LDP can also be configured manually.
The operator may want to modify the session parameters (such as hello or keepalive timeout) from the default
values (see the example on the next page).
The operator may want to avoid peering with certain routers, probably those under a different administration (see
the example on the next page).
The targeted LDP session might be required for a special feature called LDP over RSVP-TE (discussed in Module 5 of
this course).
The targeted LDP session might have to be manually specified for interoperability reasons, if required by another
router vendor.
127> Given below is a snapshot of different LDP label types:-
128>
Given below are some of the commands used to verify the ldp session:-
Show router ldp peer
129>Auto Created:- No displays the ldp session is manually created.
130 >It also displays the KA interval and KA timeout
131> show router ldp peers displays the status of the LDP peers.
132>Link, Targeted or Both can be displayed depending upon the type of adjacency.
133>The show router ldp status command output displays the general statistics regarding the LDP process.
“Active Adjacencies” indicates successfully discovered Link LDP and Targeted LDP peers (via Hello messages).
“Active Sessions” indicates successfully established Link LDP and Targeted LDP sessions (via Init and Keepalive
messages).
“Active Interfaces” indicates the number of core interfaces on which Link LDP is enabled.
“Active Peers” indicates the number of active Targeted LDP peers that are provisioned via either manual or automatic
methods.
Again, note that a session does not need to be established for a peer to be listed.
Peers need not be established to be listed.
134> LDP authenticaion can be enabled to prevent LDP from TCP spoofing attacks
This is an MD5 based autthentication and the password are never sent through the wire as clear text.
*A:R1>config>router>ldp# info
----------------------------------------------
peer-parameters
peer 10.10.10.2
authentication-key "7ZooHlzw8OE8Hs6IKYJ1kiES27LcfN23" hash2
exit
Exit
************************************************************************* LDP ****************************************************************************************************
42> Two types of LDP:-
Link LDP is used to establish transport tunnnels and T_LDP is used to transport service tunnels.
43> During the initial discovery phase LDP sends hello messages to the destination multicast address of 224.0.0.2 and the well known udp port of 646. After the routers discover each other hellos are sent to keep the adjacency alive.
44> A single LDP session exists between two peers although there might be multiple peers.
45> Link ldp sessions are created between all the adjacent routers leading to a full mesh of ldp tunnels.
46> config router ldp#
Interface-parameters
Interface x
47> The hello messages are sent to 224.0.0.2 to ensure that if several routers are attached to the same broadcast domain everone should receive that.
48> Parameters included in the hello messages:-
Version=1
LDP ID (explained later)
Message type:- Hello
Hello Timeout=15 secs
Transport address
Configuration Sequence number
49> LDP identifier is a six octet field the first 4 octets identify the LSR and is globally unique generally the system ip address of the router the last two octets identify the label space and is set to 0 for platform wide. Per interface label space is used if we are using ATM or FR or a combination of Ethernet and ATM/FR.
----------------------------------------------------------------
| | |
|LSR-id (4 bytes) | Label space ID (2 bytes) |
----------------------------------------------------------------
50> Example :-
| Router 1| ------------------------------------------- | Router 2|
10.10.10.4 10.10.10.6
LDP id:- 10.10.10.4:0 LDP-ID 10.10.10.6:0
Transport address:- 10.10.10.4 Transport address:- 10.10.10.6
Message Type:- Hello Message Type:- Hello
Hello Timeout=15 secs Hello Timeout=15 secs
Configration Sequence number Configuration Sequence number
51>Hello Timeout:- Routers continue to exchange hellos the neighbor is considered down if no hellos are received within the timeout period.
52> Configuration Sequence number is used to detect configuration changes on the sending LSR.
53> Hello Timeout by default is 15 secs and the hello factor is 3 so 15/3=5 hence each hello messages are sent after 5 secs.
54> If the router have multiple interfaces a separate set of hello messages are sent for each of the interfaces.
Config>router>ldp
Hello <timeout> <factor> <============= Global applies for all the interfaces
Interface parameters
Interface xxx
Hello <timeout> < factor> <================ Applied at the interface level over-rides the global setting
55> The hellos on both sides of the peer need not match, a negotiation takes place where the lower value is selected.
56> The status of the discovery message can be seen from show router ldp discovery detail.
State of the discovery message
Hold Time Remaining
Hello Sent and Hello Received
Local and Remote ip address
57> After the discovery process is completed, one side of the peer assumes the active role and initiates a TCP session with the neighbouring peer transport address, always the peer with the higher transport address takes that role.
58> The TCP port used is 646
59> Which ip address the routers choose to establish the session with this is also exchanged during the exchange of the hello message.
60> Two cell mode interfaces two sessions are established
Frame mode and Cell mode interface two sessions
Frame mode & Frame mode one session is established.
61> By default the transport address is set to the system ip address however this can be modified this is generally done for interoperability reasons.
62> config > router>ldp#
Interface xxx
transport address xxx <========== xxx is the name of the interface ???
63> show router ldp session <========= Provides the status of the LDP session
show router ldp session detail
64> The TCP session is established with the init messages
R1----------------------------------------------------------- R2
Dest ip = R2 transport address Dest ip =R1 transport address
TCP dest port= 646 Dst port= Any random
Source port=Any source port Source port=646
LDP-Id
Keepalive timeout Same as in R2
Message Type
Session Parameters
65> The session is established only after it receives a keep-alive message from R2.
66> Link failure lower layer protocols generally detect and inform the upper layer protocols however in case of corner case situations keepalives are also sent between the nodes hence
Keepalive are generally sent and received to maintain the TCP session.
67> config> router> ldo#
keepalive 90 3
interface parameters
interface abc
keepalive 30 3
By default it 30/3=10 seconds ie keepalive are by default sent every 10 seconds.
68> LDP sessions will be established even if the keep-alive between the routers do not match the lower one is considered.
69> By default once an LDP is established labels are generated for the system ip address and are advertised to the neighbor.
70> Link ldp sessions are created between the adjacent routers labels will be flooded and a full mesh of transport tunnels will be created.
71> show router ldp parameters
Downstream Unsolicited:- Labels are distributed to all LDP peers
Ordered Control:- A peer generates its own label for the system ip address by default, and it will also generate its own label for the peer system ip address only after it receves one from its peer.
Liberal Label retention:- All the labels are retained in the control plane, however one label is used in the data plane.
72> R4------------- R5 (5.5.5.5/32)
|
|
|
R6
For the system ip address 5.5.5.5/32 this is advertised to R4 and R6 with the same label space.
73> DU mode hence no requests are required from R4 or R6 the labels are advertised with the help of the label mapping message.
74> Labels are stored in the control plane in show router ldp bindings
Egress label:- Label which it has received from its peer for a particular FEC
Ingress Label:- Label which is locally generated.
75> If there is no ingress label for a particular prefix it means that the tunnel terminates on that particular PE.
76> Label Mapping messagE:-
Version
LDP-id
FeC
Label
Message Type:- Label maping (ox400)
77> The fib entries contains the active ip next hop information, it does not contain any redundant entries, the labels for the active next hop are placed in LFIB.
78> LIB:-
show router ldp bindings========> LIB
show router fib 1 =============> FIB entries on IOM 1
show router ldp bindings active ===========> LFIB
79> R4------------- R5 (5.5.5.5/32)
|
|
|
R6 (6.6.6.6/32)
R6 will advertise a label mapping message to R5, R5 after receiving the label mapping message will generate its own label for the FEC 6.6.6.6/32 and advertise it to R4.
Label advertised by R6 will be the ingress label for R6 and ingress label for R5.
A:R4# show router ldp bindings
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix Peer IngLbl EgrLbl EgrIntf/ EgrNextHop
-------------------------------------------------------------------------------
10.10.10.6/32 10.10.10.2 131070 -- -- --
10.10.10.6/32 10.10.10.5 131070 -- -- --
10.10.10.6/32 10.10.10.6 -- 131071 1/1/4 10.4.6.6
-------------------------------------------------------------------------------
80> In LDP the labels are flooded hence R4 receives a label from both R5 and R2 as seen in the above topology these labels are present in LIB as it works Liberal label retention mode, this helps to decrease the failure times, in case an interface becomes unavailable.
81> All the labels are present in the LIB however the labels from the active next hop are present in the ldp bindings active.
82> All the traffic hitting a particular SAP,which belongs to a service will always be label switched.
83>
As we can see in the above output R1 uses R2 as the next hop to reach 10.10.10.6 hence the Egress label used is 131068, however R1 also advertises a label to R2 for the prefix 10.10.10.6/32 however presently the label will not be in use as R2 will already the next hop to reach that prefix, this label will only be used if all the links from R2 to R6 is not available.
84> Since R3 is not the preferred next hop to reach R6 it is marked as used with an U.
85> R1 will also install a label with the swap option, ie if it becomes an LSR for a particular prefix.
86>Given below is an example where R1 can act as an LSR:-
87> show router tunnel-table displays all the tunnels that are available on a particular node the Metric displayed is the IGP metric.
88> LSP-Ping:- Checks the reachability of the prefix through the LDP tunnel unidirectionally in one direction only.
89> oam lsp-ping prefix 10.10.1.6/32
By default only 1 packets are sent this can be increased by using the send-count command
90> This contains MPLS echo request and MPLs echo reply packets, the echo request packets are encapsulated within the MPLS labels. The TTL is set to 255.
91> MPLS echo request are sent over UDP with a destination port of 3503.
92> Echo reply does not use the tunnel and is ip routed the source port used is 3503 and a destination port is arbitarily chosen.
93>
RTT===> Round trip delay this is the time taken between sending the echo request and getting a reply back.
94> RC==> Return code used by the egress router to indicate the status of the prefix, RC=3 the egress router has learned that it has this prefix.
95> oam lsp-trace prefix x.x.x.x/32
96> Used to gather hop information along the LSP path.
97> Separate request packets are sent per downstream router the MPLS TTL value is incremented at each request.
98> RC=8 (DSR Match label):- This is seen in the intermediate routers ie the intermediate routers is able to locate an downstream label for the incoming label.
99> RC=3 This is the owner of the prefix.
100>
R1 first MPLS echo request with a TTL=1, R2 consumes the packet and gives a reply back to R1. The echo reply sent by R2 is ip-routed.
101> R1 again sends a Echo request with a TTL=2, this is consumed by R4.
102> If ecmp is not enabled and we have redundant paths to a destination address with the same cost the lowest next hop for the directly connected interface address is used.
103> config>router>ecmp < number of routes>
Multiple entries for the LFIB is installed for a particular prefix.
Two different labels are installed for the same prefix
104> A hashing algorithm distrbutes the traffic between the two links.
105> Only a label is distributed for the system address by default, if need be an export policy can be created to distribute labels for the other interfaces also.
106> config router policy-options
begin
prefix-list prefix x.x.x.x/24 longer /exact
Policy-statement export
Entry 1
from prefix-lisr prefix
exit
action accept
Commit
Config router ldp
Export export
From protocol direct
Action accept can also be used.
107> Certain label bindings can be rejected upon receipt for this we need to create an export policy.
108> Generally still the routers keep the labels but do not generate its own bindings foethose labels,
109>Hence the labels will be present in the LIB but not the LFIB.
110> The following is used to reject all the prefixes.
111> An LDP router can instruct its peers to release a particular label which it has advertised before this is done with the help of label withdraw message.
112> When a label withdraw message is received from the peer, the peer responds with the label release message as provided in the below snapshot:-
113> As seen a network goes down beyond R6 hence a label withdraw message is advertised by R6.
114> Label withdraw message can be sent for the folllowing reasons:-
An MTU change on the interface causes a router to withdrawal the previously assigned label and re-signal the FEC
with the new MTU.
A network change, such as a failed interface, causes the router to remove a FEC from its FIB. The router had
previously generated and advertised a label for this FEC.
The router is configured to stop generating labels for specified FECs (for example, the removal of the export
policy).
A service manager command is issued to clear the labels, the labels are withdrawn, and new label mappings are
issued (for example, clear router ldp instance).
115> Label Release message is generated for the folowing reasons:-
The LSR receives a label withdraw message from a peer.
The LSR operates in Conservative label retention mode, and receives a label from a peer that is not the next-hop
router for the FEC.
The LSR operates in Conservative label retention mode, and the peer from whom it received the label for a FEC is
no longer the next-hop router for that FEC (for example, the result of a network failure or topological change).
There is no more memory to store a received label and the label is released.
116>
In the above scenario there are 2 /32 prefixes which are being advertised and we are summarizing the routes to 192.168.6.0/24 before being advertised to area 0.
117> Hence only 1 label will be generated for the prefix 192.168.6.0. Hence the traffic will not be able to reach the prefixes mentioned above.
118> Labels will be present in LIB, however none of them will be advertised in LFIB
119> The following command can be used to fix such situations.
Config router ldp aggregate-prefix-match
Given below is an exampls:-
***************************************************************** Targeted LDP*************************************************************************************************
120 > T-LDP is used to create the service tunnels, T_LDP advertises the service labels which is used to demultiplex the traffic and based on the labels associate them to proper services.
121> Peers do not have to be directly connected (typically established
between 2 PE routers that have services configured)
Also used in the LDP over RSVP solution.
122> For a Layer 3 (IP) VPN Service, the service labels are signaled via the MP-BGP (Multi-Protocol Border Gateway Protocol).
Targeted LDP is not utilized in pure Layer 3 VPN service environments.
123> The following snapshot provides a view of session establishment between two LDP peers:-
124>
The above command is used during the configuration of L3 VPN.
125> Targeted session can be automatically created during the configuration of SDP or can also be created manually.
The above command should be executed both the sides or the sdp should be configured both the sides for the session to establish.
126>These are the reasons for which T_LDP can also be configured manually.
The operator may want to modify the session parameters (such as hello or keepalive timeout) from the default
values (see the example on the next page).
The operator may want to avoid peering with certain routers, probably those under a different administration (see
the example on the next page).
The targeted LDP session might be required for a special feature called LDP over RSVP-TE (discussed in Module 5 of
this course).
The targeted LDP session might have to be manually specified for interoperability reasons, if required by another
router vendor.
127> Given below is a snapshot of different LDP label types:-
128>
Given below are some of the commands used to verify the ldp session:-
Show router ldp peer
129>Auto Created:- No displays the ldp session is manually created.
130 >It also displays the KA interval and KA timeout
131> show router ldp peers displays the status of the LDP peers.
132>Link, Targeted or Both can be displayed depending upon the type of adjacency.
133>The show router ldp status command output displays the general statistics regarding the LDP process.
“Active Adjacencies” indicates successfully discovered Link LDP and Targeted LDP peers (via Hello messages).
“Active Sessions” indicates successfully established Link LDP and Targeted LDP sessions (via Init and Keepalive
messages).
“Active Interfaces” indicates the number of core interfaces on which Link LDP is enabled.
“Active Peers” indicates the number of active Targeted LDP peers that are provisioned via either manual or automatic
methods.
Again, note that a session does not need to be established for a peer to be listed.
Peers need not be established to be listed.
134> LDP authenticaion can be enabled to prevent LDP from TCP spoofing attacks
This is an MD5 based autthentication and the password are never sent through the wire as clear text.
*A:R1>config>router>ldp# info
----------------------------------------------
peer-parameters
peer 10.10.10.2
authentication-key "7ZooHlzw8OE8Hs6IKYJ1kiES27LcfN23" hash2
exit
Exit
