[prev in list] [next in list] [prev in thread] [next in thread]
List: cisco-nsp
Subject: Re: [c-nsp] Questions regarding 6PE and route aggregation
From: Spyros Kakaroukas <skakaroukas () rolaware ! com>
Date: 2014-02-26 11:16:30
Message-ID: E6084B57CCD7CC48AC2598DD25CA981721AE8E () MAILSRV02 ! remoteaccess ! gr
[Download RAW message or body]
Hello,
Thanks for the reply.
On scenario B, I propagate the default using the neighbor default-originate command. \
The remote PE gets the route as well as a label for it. However, there doesn't appear \
to be a label for it in the LFIB of the local PE. Creating the static default seems \
to populate the LFIB with an aggregate label. So, I'm guessing it should be there \
without me having to do anything special, but isn't.
I find doing multiple lookups kind of wasteful, but then again, given the simplicity \
and the feature parity we get from 6PE, it might be a good trade-off.
My thoughts and words are my own.
Kind Regards,
Spyros
-----Original Message-----
From: Oliver Boehmer (oboehmer) [mailto:oboehmer@cisco.com]
Sent: Tuesday, February 25, 2014 10:55 PM
To: Spyros Kakaroukas; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Questions regarding 6PE and route aggregation
hi.
note: I haven;t touched 6PE in a while, so I might not be 100% accurate:
>
> I've been trying to evaluate 6PE as a transition mechanism lately and
> I've stumbled upon something I didn't initially expert. My
> understanding of 6PE is as follows ( and feel free to correct me if I'm wrong ☺ ) \
> : PE-A and PE-B peer over IPv4, they exchange routes and labels. Packets
> transit the core over ipv4 and have 2 labels; outer label describes the
> LSP towards the remote PE while the inner label describes the actual
> IPv6 next hop ( "CE" or whatever you want to call it ). Label
> allocation is per-prefix ( unless you switch to 6VPE, where you can
> actually change it, with all the consequences that follow ). So, I've
> been thinking, what if I don't want to send the full table to some PEs,
> but only internal routes and a default route ? Internal routes
> obviously shouldn't pose an issue, but aggregating everything to the
> default is somewhat trickier. So, I fired up my lab, got an ebgp
> session with an upstream and…here's what
> happened:
>
> Scenario A, get a default route from an upstream and advertise it
> downstream while suppressing all other external routes: Everything
> works fine. Would it work fine with >1 upstream though, or would I get
> suboptimal routing, as the PE with the full table would just perform a
> lookup on the inner label ( which would correlate to whatever single
> default route was preferred from upstreams ) ?
yes. you can check this by looking at the LFIB entry of the label BGP assigned to the \
::/0, it should point straight out to the egress interface.
>
> Scenario B, no default route from upstreams. Just generating one
> towards downstreams with default-information originate: Control plane
> looks ok , data plane just fails!
how does the RIB/FIB/LFIB look like? How exactly do you generate the default? via \
"neighbor .... default-information-originate"?
>
> Scenario C, same as scenario B apart from the addition of a static
> default to Null0 on the PE originating the default route: Surprisingly,
> it works. Is it supposed to work though ? If so, should I assume it's
> doing 2 lookups ( one of the label and one for the actual prefix ) with
> all the performance implication this carries ?
My guess is that the PE originates an aggregate label, which tells the PE to do \
another lookup. This is just a guess..
>
> Also, any advise on how you tackled similar issues would be greatly
> appreciated. Assuming scenario C is a valid design, it feels kinda
> wasteful.
why?
BTW: There is a thread on https://supportforums.cisco.com/thread/2006006
about this..
oli
This e-mail and any attachment(s) contained within are confidential and are intended \
only for the use of the individual to whom they are addressed. The information \
contained in this communication may be privileged, or exempt from disclosure. If the \
reader of this message is not the intended recipient, you are hereby notified that \
any dissemination, distribution, or copying of this communication is strictly \
prohibited. If you have received this communication in error, please notify the \
sender and delete the communication without retaining any copies. Rolaware Hellas SA \
is not responsible for, nor endorses, any opinion, recommendation, conclusion, \
solicitation, offer or agreement or any information contained in this communication.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
[prev in list] [next in list] [prev in thread] [next in thread]