Re: Doubts regarding MPLS destination sharing and cef output

From: Jomi <doctorfleming_at_gmail.com>
Date: Wed, 11 Aug 2010 12:33:37 +0200

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
Received on Wed Aug 11 2010 - 12:33:37 ART

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