I think that the "session sourced from the higher IP remains active" rule is important only when two routers establish sessions between them at the same time, session sourced from the higher RID remains active, the other one is terminated (same behavior as in BGP if I recall correctly).
So, in this case only one TCP session was formed (from R2 to R1). I think it depends which session is formed first.. I've thought it would behave a bit differently in this case. I'll have to lab that up when I get back home today. I know that's a weird setup...okay..it's more appropriate to simply call it misconfiguration :-) Thanks, Adam On Wed, May 5, 2010 at 11:49 AM, Rick Mur <[email protected]> wrote: > 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 >>> >>> >> >>
<<Screen shot 2010-05-05 at 18.41.31.png>>
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
