True, you would never see this in real-life, unless someone who doesn't know what he's doing did it and they will never ask you to configure this strange behavior in the lab :-)
-- Regards, Rick Mur CCIE2 #21946 (R&S / Service Provider) Sr. Support Engineer – IPexpert, Inc. URL: http://www.IPexpert.com On 5 mei 2010, at 19:22, Adam wrote: > 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 > <Screen shot 2010-05-05 at 18.41.31.png> > 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 >>> >>> >>>
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
