Re: Please confirm (conf#e6a6e7f19f26af5d1595d7c8cbc4c783)

On Tue, Aug 3, 2010 at 6:49 PM, Cisco certification
<ccielab_at_groupstudy.com> wrote:
> Hi,
>
> You have tried to post to a GroupStudy.com certification mailing list. Because
> the server does not recognize you as a confirmed poster, you will be required
> to authenticate that you are using a valid e-mail address and are not a
> spammer. By confirming this e-mail you certify that you are not sending
> Unsolicited Bulk Email (UBE).
>
> PLEASE DO NOT SEND YOUR ORIGINAL MESSAGE AGAIN! BY CONFIRMING THIS EMAIL
> YOUR ORIGINAL MESSAGE (WHICH IS NOW QUEUED IN THE SERVER) WILL BE POSTED.
>
>
> By confirming this e-mail you also certify the following:
>
> 1. The message does NOT break Cisco's Non-Disclosure requirements.
>
> 2. The message is NOT designed to advertise a commercial product.
>
> 3. You understand all postings become property of GroupStudy.com
>
> 4. You have searched the archives prior to posting.
>
> 5. The message is NOT inflammatory.
>
> 6. The message is NOT a test message.
>
> To confirm, simply reply to this message. No editing is necessary. Once
> confirmed, you will be able to post without additional confirmations.
>
>
> Welcome to GroupStudy.com!
>
>
> First time posters to GroupStudy.com are required to agree to the GroupStudy terms and conditions.
> Replying to this email, certifies you have read and agree to the GroupStudy posting guidelines and terms and conditions.
>
> --- Original Message Follows ---
>
> Date: Tue, 3 Aug 2010 16:00:38 +0200
> Subject: Doubts regarding MPLS destination sharing and cef output
> From: Daniel Rodriguez <daniel.rodriguez.lists_at_gmail.com>
> To: ccielab_at_groupstudy.com
>
> 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.
>
>
> (Original message truncated)

Blogs and organic groups at http://www.ccie.net
Received on Wed Aug 04 2010 - 10:50:53 ART