| It seems to be working fine, but you get reaaaally weird combinations of used transport addresses. I have the attached topology (.png).
The forwarding table looks fine as it is load balancing across the 2 equal cost links.
R1(config)#do sh mpls for Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 19 Pop Label 2.2.2.2/32 0 Gi0/0 1.1.12.2 Pop Label 2.2.2.2/32 0 Gi0/1 1.1.21.2
I get an error message about not having the host route on R1 (which is expecting to use the Loopbacks as transport): (though it still works)
R1#sh mpls ldp disc Local LDP Identifier: 1.1.1.1:0 Discovery Sources: Interfaces: GigabitEthernet0/0 (ldp): xmit/recv LDP Id: 2.2.2.2:0; IP addr: 1.1.12.2; no host route GigabitEthernet0/1 (ldp): xmit/recv LDP Id: 2.2.2.2:0; IP addr: 1.1.21.2; no host route
R2#sh mpls ldp discovery Local LDP Identifier: 2.2.2.2:0 Discovery Sources: Interfaces: GigabitEthernet0/0 (ldp): xmit/recv LDP Id: 1.1.1.1:0 GigabitEthernet0/1 (ldp): xmit/recv LDP Id: 1.1.1.1:0
The neighbor comes up:
*May 5 16:49:12.843: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP *May 5 17:52:32.879: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is UP
And the neighbor relationship is using the Loopback of R1 and the interface of R2 as the transport address (not the highest, just the first that returns a hello I guess)
R2#sh mpls ldp nei Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0 TCP connection: 1.1.1.1.646 - 1.1.12.2.13624 State: Oper; Msgs sent/rcvd: 7/7; Downstream Up time: 00:00:26 LDP discovery sources: GigabitEthernet0/0, Src IP addr: 1.1.12.1 GigabitEthernet0/1, Src IP addr: 1.1.21.1 Addresses bound to peer LDP Ident: 1.1.12.1 1.1.21.1 1.1.1.1
R1#sh mpls ldp nei Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 1.1.1.1:0 TCP connection: 1.1.12.2.13624 - 1.1.1.1.646 State: Oper; Msgs sent/rcvd: 9/9; Downstream Up time: 00:02:06 LDP discovery sources: GigabitEthernet0/0, Src IP addr: 1.1.12.2 GigabitEthernet0/1, Src IP addr: 1.1.21.2 Addresses bound to peer LDP Ident: 1.1.12.2 1.1.21.2 2.2.2.2
As you can see it identifies both connections, only R2 still will need to be able to reach the Loopback of R1, otherwise the connection will not come up of course. It's a really weird combination and it's not designed to work like this, but it does and it's load balancing :-)
--
Regards,
Rick Mur
CCIE2 #21946 (R&S / Service Provider)
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com
 On 5 mei 2010, at 17:42, Adam wrote: I do fully agree with you, Rick. I have another question though and this one makes things even more complicated.
One session between two LSRs is sufficient when using per-platform label space. Now, lets assume R1 has two parallel links to R2. LDP RIDs are set to the highest loopback IPs on both boxes. R2 is using physical interfaces as its transport-addresses, at the same time R1's default behavior remains unchanged (transport-address = LDP RID). R1 will try to establish two sessions to R2, R2 will attempt to have one active session to R1.
What will happen in this scenario? How will session establishment look like? Which session should remain active? I know that in the case of two active sessions, the one sourced from
higher IP remains active. Of course, I know that such config is a real mess and it won't work properly (I mean load-balancing) as one side thinks two sessions should be active, while the other assumes only one should be formed :-)
On Wed, May 5, 2010 at 8:50 AM, Rick Mur <[email protected]> wrote:
It would work yes, you would have 1 LDP session between the routers with multiple links between them. Like you said, it complicates things a bit. It's hard to tell where the labels come from and go to, but it definitely works :-)
--
Regards, Rick Mur CCIE2 #21946 (R&S / Service Provider) Sr. Support Engineer – IPexpert, Inc. URL: http://www.IPexpert.com
On 5 mei 2010, at 15:25, Adam wrote: Rick,
Can't we use the same transport address on all links going to another LDP router? I believe that using the same transport address (let's say another (reachable) loopback) on both links going to the remote peer should work (assuming we use per-platform label space). I know that only complicates things and that's definitely not a best practice, but that should work (neighbor LDP ID x reachable via src IP y (physical), transport IP = z (loopback other than LDP RID). Correct me if I'm wrong, please.
Thanks,
Adam
On Wed, May 5, 2010 at 12:56 AM, Rick Mur <[email protected]> wrote:
In the first place I would never configure this in my lab, unless it's asked for!
In 99% of the cases your loopback address (the default LDP Router ID) will be reachable for the other side via your IGP, so the TCP session for LDP will also be using the Loopbacks as source and destination address and the session will come up. So it's very important that your LDP Router ID is reachable for the other side.
To overcome this issue (or when using multiple links and you want LDP load-balancing) you should use the interface address (which is ALWAYS reachable by the other side) to be the transport-address, meaning that it will not use the Router ID as source and destination, but use the interface addresses for the TCP session.
I hope this answers your question.
--
Regards,
Rick Mur
CCIE2 #21946 (R&S / Service Provider)
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com
On 5 mei 2010, at 06:48, venkat wrote:
> And this transport-address should be reachable from neighbor to form adjacency.
>
> On 5/5/10, Adam < [email protected]> wrote:
>> It forces creation of LDP session using that particular address/interface
>> (by default LDP RID is used). If there is more than one link to the other
>> LDP router, you should use the same transport address.
>>
>> On Tue, May 4, 2010 at 2:40 PM, Mustafa Yadav
>> < [email protected]>wrote:
>>
>>> hi guys
>>>
>>> mpls ldp discovery transport-address interface
>>>
>>> Why the above command is so critical?Without this the ldp neighborship did
>>> not come up/
>>>
>>> _______________________________________________
>>> For more information regarding industry leading CCIE Lab training, please
>>> visit www.ipexpert.com
>>>
>>>
>>
>
> --
> Sent from my mobile device
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
|
