Thanks Bryan.
I think we've reached the same conclusion :) For me it was a bit
unexpected behavior, but I guess it makes more sense now. Especially
when I get to the AtoM chapter in my MPLS books :)
On 12/10/2009, at 11:47 , Bryan Bartik wrote:
> Marcel,
>
> There are a few exceptions, but in order to forward labeled packets
> over an
> interface you need "mpls ip" on the interface. A couple of
> exceptions are
> when you are using another protocol to advertise labels over the
> interface
> such as BGP + send-label or RSVP (in MPLS TE). Unlike these scenarios,
> targeted hellos do not remove the need for configuring "mpls ip" on an
> interface.
>
> Remember, targeted hellos are not only used by session protection. For
> example, they are also used in AToM where you need to advertise one
> label
> (VC label) across multiple hops.
>
> On Sun, Oct 11, 2009 at 1:47 AM, Marcel Lammerse
> <m.lammerse_at_mac.com> wrote:
>
>>
>> Hi Bryan,
>>
>> yeah.. still wondering what's going on here.
>>
>> Someone suggested to me that targeted ldp is used more for mpls
>> applications such as atom, not so much for plain label switching
>> between
>> directly connected routers. But, t-ldp is also mentioned as a way
>> of making
>> ldp sessions more resilient in case the directly connected
>> interface between
>> two ldp peers breaks.
>>
>> The way I understand it, there are two ways of configuring a
>> protected ldp
>> session.
>>
>> 1. 'mpls ldp neighbor <ip> targeted ldp' in global config mode
>>
>> 2. 'mpls ip' under the interface + 'mpls ldp session
>> protection' in
>> global config mode
>>
>> So really with ldp session protection, you have both a directly
>> connected
>> ldp session and a 'targeted' ldp session active at the same time.
>>
>> When I try option 1 and remove the 'mpls ip' command from the
>> interface,
>> the labels disappear from the lfib, but the targeted ldp sesions is
>> up. If
>> leave the 'mpls ip' command on the interface, I do receive the
>> labels.
>>
>> So my questions are :
>>
>> 1. Why are there different commands to configure a protected ldp
>> session, that seem to do the same thing?
>> 2. When should I configure a targeted ldp session and what is
>> it used
>> for?
>> 3. Why am I not receiving labels across a targeted ldp session
>> between
>> directly connected neighbors?
>>
>> PE4#sh mpls ldp neighbor
>> Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 4.4.4.4:0
>> TCP connection: 1.1.1.1.646 - 4.4.4.4.13537
>> State: Oper; Msgs sent/rcvd: 15/15; Downstream
>> Up time: 00:00:15
>> LDP discovery sources:
>> FastEthernet1/0, Src IP addr: 172.16.14.1
>> Addresses bound to peer LDP Ident:
>> 1.1.1.1 172.16.12.1 172.16.14.1
>> Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 4.4.4.4:0
>> TCP connection: 3.3.3.3.646 - 4.4.4.4.14581
>> State: Oper; Msgs sent/rcvd: 15/15; Downstream
>> Up time: 00:00:13
>> LDP discovery sources:
>> FastEthernet3/0, Src IP addr: 172.16.34.3
>> Addresses bound to peer LDP Ident:
>> 3.3.3.3 172.16.13.3 172.16.23.3 172.16.34.3
>>
>> PE4#sh mpls forwarding-table 192.168.2.0
>> Local Outgoing Prefix Bytes Label Outgoing
>> Next Hop
>> Label Label or VC or Tunnel Id Switched interface
>> 23 25 192.168.2.0/24 0 Fa1/0
>> 172.16.14.1
>> 19 192.168.2.0/24 0 Fa3/0
>> 172.16.34.3
>> PE4#
>>
>>
>> PE4#sh run int fastEthernet 1/0
>> Building configuration...
>>
>> Current configuration : 105 bytes
>> !
>> interface FastEthernet1/0
>> ip address 172.16.14.4 255.255.255.0
>> duplex auto
>> speed auto
>> mpls ip
>> end
>>
>> PE4#sh run int fastEthernet 3/0
>> Building configuration...
>>
>> Current configuration : 105 bytes
>> !
>> interface FastEthernet3/0
>> ip address 172.16.34.4 255.255.255.0
>> duplex auto
>> speed auto
>> mpls ip
>> end
>>
>> PE4#
>>
>> PE4#conf t
>> Enter configuration commands, one per line. End with CNTL/Z.
>> PE4(config)#int fastEthernet 3/0
>> PE4(config-if)#no mpls ip
>> PE4(config)#int fastEthernet 1/0
>> PE4(config-if)#no mpls ip
>> PE4(config-if)#exit
>> PE4(config)#mpls ldp neighbor 1.1.1.1 targeted ldp
>> PE4(config)#mpls ldp neighbor 3.3.3.3 targeted ldp
>> PE4(config)#
>>
>> PE4#sh mpls ldp neighbor
>> *Oct 11 17:37:53.215: %SYS-5-CONFIG_I: Configured from console by
>> console
>> Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 4.4.4.4:0
>> TCP connection: 3.3.3.3.646 - 4.4.4.4.28418
>> State: Oper; Msgs sent/rcvd: 268/268; Downstream
>> Up time: 03:41:25
>> LDP discovery sources:
>> Targeted Hello 4.4.4.4 -> 3.3.3.3, active, passive
>> Addresses bound to peer LDP Ident:
>> 3.3.3.3 172.16.13.3 172.16.23.3 172.16.34.3
>> Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 4.4.4.4:0
>> TCP connection: 1.1.1.1.646 - 4.4.4.4.24502
>> State: Oper; Msgs sent/rcvd: 35/36; Downstream
>> Up time: 00:18:32
>> LDP discovery sources:
>> Targeted Hello 4.4.4.4 -> 1.1.1.1, active, passive
>> Addresses bound to peer LDP Ident:
>> 1.1.1.1 172.16.12.1 172.16.14.1
>> PE4#
>>
>>
>> PE4#sh mpls forwarding-table 192.168.2.0
>> Local Outgoing Prefix Bytes Label Outgoing
>> Next Hop
>> Label Label or VC or Tunnel Id Switched interface
>> 23 No Label 192.168.2.0/24 0 Fa1/0
>> 172.16.14.1
>> No Label 192.168.2.0/24 0 Fa3/0
>> 172.16.34.3
>> PE4#
>>
>> PE4#sh mpls forwarding-table
>> Local Outgoing Prefix Bytes Label Outgoing
>> Next Hop
>> Label Label or VC or Tunnel Id Switched interface
>> 16 No Label 3.3.3.3/32 41402 Fa3/0
>> 172.16.34.3
>> 17 No Label 2.2.2.2/32 0 Fa1/0
>> 172.16.14.1
>> No Label 2.2.2.2/32 0 Fa3/0
>> 172.16.34.3
>> 18 No Label 1.1.1.1/32 0 Fa1/0
>> 172.16.14.1
>> 19 No Label 172.16.24.0/24 0 Fa1/0
>> 172.16.14.1
>> No Label 172.16.24.0/24 0 Fa3/0
>> 172.16.34.3
>> 20 No Label 172.16.13.0/24 0 Fa3/0
>> 172.16.34.3
>> 21 No Label 172.16.12.0/24 0 Fa1/0
>> 172.16.14.1
>> 22 No Label 172.16.23.0/24 0 Fa3/0
>> 172.16.34.3
>> 23 No Label 192.168.2.0/24 0 Fa1/0
>> 172.16.14.1
>> No Label 192.168.2.0/24 0 Fa3/0
>> 172.16.34.3
>> 24 No Label 12.12.12.2/32 0 Fa1/0
>> 172.16.14.1
>> No Label 12.12.12.2/32 0 Fa3/0
>> 172.16.34.3
>> PE4#
>>
>>
>> Attached a topology diagram. The link between PE1 and PE2 was shut
>> during
>> the lab :
>>
>> PE4#sh ip int brief
>> Interface IP-Address OK? Method Status
>> Protocol
>> FastEthernet0/0 unassigned YES NVRAM
>> administratively down
>> down
>> FastEthernet1/0 172.16.14.4 YES NVRAM up
>> up
>> FastEthernet1/1 unassigned YES NVRAM
>> administratively down
>> down
>> FastEthernet2/0 172.16.24.4 YES NVRAM
>> administratively down
>> down
>> FastEthernet2/1 unassigned YES NVRAM
>> administratively down
>> down
>> FastEthernet3/0 172.16.34.4 YES NVRAM up
>> up
>> FastEthernet3/1 unassigned YES NVRAM
>> administratively down
>> down
>> FastEthernet4/0 unassigned YES NVRAM up
>> up
>> FastEthernet4/1 unassigned YES NVRAM
>> administratively down
>> down
>> SSLVPN-VIF0 unassigned NO unset up
>> up
>> Loopback0 4.4.4.4 YES NVRAM up
>> up
>> PE4#
>>
>>
>>
>>
>>
>> On 11/10/2009, at 10:18 , Bryan Bartik wrote:
>>
>> Marcel,
>>>
>>> Are you still having this issue? Can you post configs and topology?
>>>
>>> On Wed, Oct 7, 2009 at 6:13 PM, Marcel Lammerse <m.lammerse_at_mac.com>
>>> wrote:
>>>
>>> Experts,
>>>>
>>>> here I have a load-balanced path between directly connected ldp
>>>> speakers
>>>> :
>>>>
>>>> PE4#sh mpls forwarding-table 192.168.2.0
>>>> Local Outgoing Prefix Bytes Label Outgoing
>>>> Next Hop
>>>> Label Label or VC or Tunnel Id Switched interface
>>>> 22 25 192.168.2.0/24 0 Fa1/0
>>>> 172.16.14.1
>>>> 23 192.168.2.0/24 0 Fa3/0
>>>> 172.16.34.3
>>>> PE4#
>>>>
>>>> PE4#sh mpls ldp bindings 192.168.2.0 24 detail
>>>> lib entry: 192.168.2.0/24, rev 22, chkpt: none
>>>> local binding: label: 22 (owner LDP)
>>>> Advertised to:
>>>> 1.1.1.1:0 3.3.3.3:0
>>>> remote binding: lsr: 1.1.1.1:0, label: 25
>>>> remote binding: lsr: 3.3.3.3:0, label: 23
>>>> route information: state: none, table: default,
>>>> next-hop: 172.16.14.1, remote label: 25
>>>> route information: state: none, table: default,
>>>> next-hop: 172.16.34.3, remote label: 23
>>>>
>>>> If I change the ldp sessions to t-ldp, and keep everything else
>>>> the same,
>>>> the labels seem to disappear and traffic appears to go out
>>>> untagged :
>>>>
>>>> PE4#sh mpls forwarding-table 192.168.2.0
>>>> Local Outgoing Prefix Bytes Label Outgoing
>>>> Next Hop
>>>> Label Label or VC or Tunnel Id Switched interface
>>>> 22 No Label 192.168.2.0/24 0 Fa1/0
>>>> 172.16.14.1
>>>> No Label 192.168.2.0/24 0 Fa3/0
>>>> 172.16.34.3
>>>> PE4#
>>>>
>>>> PE4#sh mpls ldp bindings 192.168.2.0 24 detail
>>>> lib entry: 192.168.2.0/24, rev 22, chkpt: none
>>>> local binding: label: 22 (owner LDP)
>>>> Advertised to:
>>>> 3.3.3.3:0 1.1.1.1:0
>>>> remote binding: lsr: 3.3.3.3:0, label: 23
>>>> remote binding: lsr: 1.1.1.1:0, label: 25
>>>> route information: state: none, table: default,
>>>> next-hop: 172.16.14.1, remote label: <----- no label
>>>> route information: state: none, table: default,
>>>> next-hop: 172.16.34.3, remote label: <----- no label
>>>> PE4#
>>>>
>>>> I'm a bit confused by this. I would have expected the traffic to
>>>> continue
>>>> to be labeled and the labels to remain the same.
>>>>
>>>> Can anyone shed some light on why this happens?
>>>>
>>>> Thanks,
>>>> Marcel
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Bryan Bartik
>>> CCIE #23707 (R&S), CCNP
>>> Sr. Support Engineer - IPexpert, Inc.
>>> URL: http://www.IPexpert.com
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> --
> Bryan Bartik
> CCIE #23707 (R&S), CCNP
> Sr. Support Engineer - IPexpert, Inc.
> URL: http://www.IPexpert.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Mon Oct 12 2009 - 20:49:44 ART
This archive was generated by hypermail 2.2.0 : Sun Nov 01 2009 - 07:50:59 ART