[c-nsp] Questions regarding 6PE and route aggregation

[Spyros Kakaroukas]

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 at cisco.com]
Sent: Tuesday, February 25, 2014 10:55 PM
To: Spyros Kakaroukas; cisco-nsp at 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.