Re: Doubts regarding MPLS destination sharing and cef output

From: Daniel Rodriguez <daniel.rodriguez.lists_at_gmail.com>
Date: Wed, 11 Aug 2010 18:10:12 +0200

Hi Srinivas,

Thank you for the reply.

I understand the recursive lookups needed and that its going to still
use 2 outbound interfaces.

The doubts that I had, was regarding the tag rewrite only on one
interface, and I couldn't find any documentation on that.

When you said "the first one" do you mean the "first one" to come up?,
maybe the higher port id?, The first one to form a LDP adjacency?... I
still don't have it clear, but anyway, thank you for the reply.

Best Regards,

On Wed, Aug 11, 2010 at 2:01 PM, srinivas pv <vsrinivas.paturi_at_gmail.com> wrote:
> Hi,
> show ip cef 6.6.6.0
> 6.6.6.0/24, version 32, epoch 0, per-destination sharing
> 0 packets, 0 bytes
> tag information from 66.66.66.66/32, shared
> local tag: 22
> via 66.66.66.66, 0 dependencies, recursive
> next hop 10.10.13.3, FastEthernet0/0 via 66.66.66.66/32
> valid adjacency
> tag rewrite with Fa0/1, 10.10.31.3, tags imposed: {21}
> Recursive load sharing using 66.66.66.66/32.
> Here 'Recursive load sharing ...' indicates that iBGP next hop (66.66.66.66)
> is load balanced and it requires further lookups during forwarding time.
> It may show only one outbound interface ( I think the first one), but for
> load sharing it still uses 2 interfaces.
> Thanks,
> Srinivas
> On Wed, Aug 11, 2010 at 4:03 PM, Jomi <doctorfleming_at_gmail.com> wrote:
>>
>> Hi Daniel,
>>
>> Yeah, it seems a little weird. Have you got any news??
>> Anyone could give an explanation about this behaviour??
>>
>>
>> On Tue, Aug 3, 2010 at 4:00 PM, Daniel Rodriguez <
>> daniel.rodriguez.lists_at_gmail.com> wrote:
>>
>> > Hi everybody,
>> >
>> > I m having a doubt regarding what I m seen on the show mpls / route
>> > tables and what actually cef is showing up to me in a simple lab.
>> >
>> > I have a something like this topology:
>> >
>> > R6 = R5 = R2 = R3 = R4
>> >
>> > All connected using FastEthernet interfaces (two links between them).
>> >
>> > between R6 and R4 there is a iBGP neighbor relationship build up, and
>> > a redistribute connected so a loopback addres (/24) gets into the BGP
>> > table.
>> >
>> > From R4:
>> >
>> > show ip bgp 6.6.6.0
>> > BGP routing table entry for 6.6.6.0/24, version 9
>> > Paths: (1 available, best #1, table Default-IP-Routing-Table)
>> > Not advertised to any peer
>> > Local
>> > 66.66.66.66 (metric 23) from 66.66.66.66 (66.66.66.66)
>> > Origin incomplete, metric 0, localpref 100, valid, internal, best
>> >
>> > That looks good.
>> >
>> > show mpls for 6.6.6.0
>> > Local Outgoing Prefix Bytes tag Outgoing Next Hop
>> > tag tag or VC or Tunnel Id switched interface
>> > 22 21 6.6.6.0/24 0 Fa0/1 10.10.31.3
>> > 21 6.6.6.0/24 0 Fa0/0 10.10.13.3
>> >
>> > show mpls for 6.6.6.0 deta
>> > Local Outgoing Prefix Bytes tag Outgoing Next Hop
>> > tag tag or VC or Tunnel Id switched interface
>> > 22 21 6.6.6.0/24 0 Fa0/1 10.10.31.3
>> > MAC/Encaps=14/18, MRU=1500, Tag Stack{21}
>> > C20115640020C202156400018847 00015000
>> > No output feature configured
>> > Per-destination load-sharing, slots: 0 2 4 6 8 10 12 14
>> > 21 6.6.6.0/24 0 Fa0/0 10.10.13.3
>> > MAC/Encaps=14/18, MRU=1500, Tag Stack{21}
>> > C20115640010C202156400008847 00015000
>> > No output feature configured
>> > Per-destination load-sharing, slots: 1 3 5 7 9 11 13 15
>> >
>> > We have per-destination load-sharing with the reference to the slots
>> > used. That looks fine to me.
>> >
>> > But here we come to the doubts I m having.
>> >
>> > The cef output only reference one of the interfaces as a tag rewrite
>> > (in this case Fa0/1):
>> >
>> > show ip cef 6.6.6.0
>> > 6.6.6.0/24, version 32, epoch 0, per-destination sharing
>> > 0 packets, 0 bytes
>> > tag information from 66.66.66.66/32, shared
>> > local tag: 22
>> > via 66.66.66.66, 0 dependencies, recursive
>> > next hop 10.10.13.3, FastEthernet0/0 via 66.66.66.66/32
>> > valid adjacency
>> > tag rewrite with Fa0/1, 10.10.31.3, tags imposed: {21}
>> > Recursive load sharing using 66.66.66.66/32.
>> >
>> > If I do recursive lookup on the 66.66.66.66 (destination router-id)
>> > address I see that it actually have a reference to both outbound
>> > interfaces (with tags imposed)
>> >
>> > show ip cef 66.66.66.66
>> > 66.66.66.66/32, version 31, epoch 0, per-destination sharing
>> > 0 packets, 0 bytes
>> > tag information set, shared
>> > local tag: 22
>> > via 10.10.31.3, FastEthernet0/1, 0 dependencies
>> > traffic share 1
>> > next hop 10.10.31.3, FastEthernet0/1
>> > valid adjacency
>> > tag rewrite with Fa0/1, 10.10.31.3, tags imposed: {21}
>> > via 10.10.13.3, FastEthernet0/0, 1 dependency
>> > traffic share 1
>> > next hop 10.10.13.3, FastEthernet0/0
>> > valid adjacency
>> > tag rewrite with Fa0/0, 10.10.13.3, tags imposed: {21}
>> > 0 packets, 0 bytes switched through the prefix
>> > tmstats: external 0 packets, 0 bytes
>> > internal 0 packets, 0 bytes
>> >
>> > If I take a look at the internal information, it shows:
>> >
>> > show ip cef 6.6.6.0 inter
>> > 6.6.6.0/24, version 32, epoch 0, per-destination sharing
>> > 0 packets, 0 bytes
>> > tag information from 66.66.66.66/32, shared
>> > local tag: 22
>> > via 66.66.66.66, 0 dependencies, recursive
>> > next hop 10.10.13.3, FastEthernet0/0 via 66.66.66.66/32
>> > valid adjacency
>> > tag rewrite with Fa0/1, 10.10.31.3, tags imposed: {21}
>> >
>> > Recursive load sharing using 66.66.66.66/32
>> > Load distribution: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 (refcount 2)
>> >
>> > Hash OK Interface Address Packets Tags
>> > imposed
>> > 1 Y FastEthernet0/1 10.10.31.3 0 {21}
>> > 2 Y FastEthernet0/0 10.10.13.3 0 {21}
>> > 3 Y FastEthernet0/1 10.10.31.3 0 {21}
>> > 4 Y FastEthernet0/0 10.10.13.3 0 {21}
>> > 5 Y FastEthernet0/1 10.10.31.3 0 {21}
>> > 6 Y FastEthernet0/0 10.10.13.3 0 {21}
>> > 7 Y FastEthernet0/1 10.10.31.3 0 {21}
>> > 8 Y FastEthernet0/0 10.10.13.3 0 {21}
>> > 9 Y FastEthernet0/1 10.10.31.3 0 {21}
>> > 10 Y FastEthernet0/0 10.10.13.3 0 {21}
>> > 11 Y FastEthernet0/1 10.10.31.3 0 {21}
>> > 12 Y FastEthernet0/0 10.10.13.3 0 {21}
>> > 13 Y FastEthernet0/1 10.10.31.3 0 {21}
>> > 14 Y FastEthernet0/0 10.10.13.3 0 {21}
>> > 15 Y FastEthernet0/1 10.10.31.3 0 {21}
>> > 16 Y FastEthernet0/0 10.10.13.3 0 {21}
>> >
>> > I see that there is actually a reference to both interfaces with the
>> > correct tags imposed.
>> >
>> > I understand that for the prefix 6.6.6.0, cef is actually doing a
>> > recursive lookup on the destination router-id (66.66.66.66) and is
>> > using that adjacency information with both outbound interfaces to send
>> > packets:
>> >
>> > Router#show ip cef exact-route 44.44.44.44 6.6.6.2
>> > 44.44.44.44 -> 6.6.6.2 : FastEthernet0/1 (next hop
>> > 10.10.31.3)
>> > Router#show ip cef exact-route 44.44.44.44 6.6.6.3
>> > 44.44.44.44 -> 6.6.6.3 : FastEthernet0/0 (next hop
>> > 10.10.13.3)
>> >
>> > But why in the show ip cef I only get one outbound rewrite interface:
>> >
>> > via 66.66.66.66, 0 dependencies, recursive
>> > next hop 10.10.13.3, FastEthernet0/0 via 66.66.66.66/32
>> > valid adjacency
>> > tag rewrite with Fa0/1, 10.10.31.3, tags imposed: {21}
>> >
>> > Why only one?, why that one?, what s the criteria used?
>> >
>> > If any one can give me a light on this it would be very nice.
>> >
>> > Best Regards,
>> >
>> >
>> > 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
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Wed Aug 11 2010 - 18:10:12 ART

This archive was generated by hypermail 2.2.0 : Wed Sep 01 2010 - 11:20:52 ART