[c-nsp] Aggregate label not generated

[Oliver Boehmer (oboehmer)]

Pshem Kowalczyk <> wrote on Thursday, June 19, 2008 6:38 AM:

> Hi
> 
> 
> 2008/6/19 Peter Rathlev <peter at rathlev.dk>:
>> Well, AFAIK "default-information originate" is needed to advertise
>> defaults also in VRFs. But if PE1 and PE2 are the same HW/SW that
>> shouldn't be the case here, i.e. 0.0.0.0/1 doesn't seem to be
>> considered a "default". 
>> 
>> If I understand it correctly, for a label to be assigned by the
>> router the prefix needs to exist in the RIB "on itself". If the
>> route from PE1, and not the locally generated route, is installed in
>> the RIB, and the route uses Default-IP-Routing-Table as next hop via
>> a Loopback-to-Loopback LSP (L3VPN) you won't have a local label.
>> 
>> The route from PE1 is preferred since BGP admin distance is less than
>> the 250 assigned to the static.

well, BGP path selection will almost always select a locally-generated
prefix (higher weight), so admin-distance doesn't apply in this case.
And the OP showed the route being installed in the RIB (and I'd assume
also in BGP).

> 
> The question here is why is there no label on PE1 at all? It has a
> locally connected interface that gets into bgp using a network
> statement - it should generate a label for it. Unless I'm completely
> wrong here ...

right, PE1 should generate a label, possibly a bug related to the 0/1
prefix. Do you see a lable generated for the 128/1?

Regarding your overall idea/approach: My gut doesn't like it ;-) in the
older LFIB infrastructure (i.e. pre-12.2SB/33S/some-other), packets
coming from the MPLS cloud to a PE and going back out to another PE
doesn't always work. In my opinion, a 2547-architecture really asks for
a PE to hold all routes for a given VPN, and if this number is too high
(I don't think a 28xx is too weak to hold 40k pfx), build a hub&spoke
VPN where the default is generated by some hub-CE, rather than on the
hub-PE.

my 2c,

	oli