Re: Importing full/inactive IPv4 global table in to VRF
 

Hi,
Due to some specific reasons, I'm trying to import the full BGP
routes from a single service provider A into a dedicated VRF of a
customer (downstream BGP customer). Yes i know that importing full
IPv4 global table into VRF is not scalable but in this case I have no
other options. Other elements involved are:

- The router connecting to provider A is multihomed to multiple
providers.

- I have to ensure all routes from provider A is not lost through BGP
best path selection. The
customer has to see all routes (RIB/inactive routes) and not the
best path only (FIB).

- I might need to replicate the same config for the same customer for
full routes from provider B and C as well, on separate VRFs.

Need some suggestions and help to address the scenario mentioned
above. Thanks.

Regards,
Kana

Re: Importing full/inactive IPv4 global table in to VRF
 

On Sat, 4 Apr 2009 08:29:04 -0700 (PDT), Kana <kanagaraj.k@gmail.com>
wrote:

>Hi,
> Due to some specific reasons, I'm trying to import the full BGP
>routes from a single service provider A into a dedicated VRF of a
>customer (downstream BGP customer). Yes i know that importing full
>IPv4 global table into VRF is not scalable but in this case I have no
>other options. Other elements involved are:
>
>- The router connecting to provider A is multihomed to multiple
>providers.
>
>- I have to ensure all routes from provider A is not lost through BGP
>best path selection. The
> customer has to see all routes (RIB/inactive routes) and not the
>best path only (FIB).

if you only have 1 route out havent you already lost all that?

anyhow - i havent tried this, but there is a way to avoid importing
all the routes.
if you must, try the "carrier supporting carrier" style option - you
will need to let a CE at each side carry the BGP, but will not need to
import it into the VRF.
http://www.cisco.com/en/US/docs/ios/.../fscsclbl.html
>
>- I might need to replicate the same config for the same customer for
>full routes from provider B and C as well, on separate VRFs.
>
>Need some suggestions and help to address the scenario mentioned
>above. Thanks.
>
>Regards,
>Kana
--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

Re: Importing full/inactive IPv4 global table in to VRF
 

On Apr 5, 4:21*am, Stephen <stephen_h...@xyzworld.com> wrote:
> On Sat, 4 Apr 2009 08:29:04 -0700 (PDT), Kana <kanagara...@gmail.com>
> wrote:
>
> >Hi,
> > * * Due to some specific reasons, I'm trying to import the full BGP
> >routes from a single service provider A into a dedicated VRF of a
> >customer (downstream BGP customer). Yes i know that importing full
> >IPv4 global table into VRF is not scalable but in this case I have no
> >other options. Other elements involved are:
>
> >- The router connecting to provider A is multihomed to multiple
> >providers.
>
> >- I have to ensure all routes from provider A is not lost through BGP
> >best path selection. The
> > *customer has to see all routes (RIB/inactive routes) and not the
> >best path only (FIB).
>
> if you only have 1 route out havent you already lost all that?
>
> anyhow - i havent tried this, but there is a way to avoid importing
> all the routes.
> if you must, try the "carrier supporting carrier" style option - you
> will need to let a CE at each side carry the BGP, but will not need to
> import it into the VRF.http://www.cisco.com/en/US/docs/ios/.../fscsclbl.html
>

If I'm not mistaken CSC is used to interconnect a customer carrier
POPs through another providers MPLS backbone, ensuring labels are
carried using BGP. But in our case, we are providing transit routes to
the BGP customer from specific upstream without losing its routes to
BGP best path selection. If the router connecting to the connecting to
the upstream does not have any other external BGP session it would be
a clear cut. In this case though its multihomed to multiple transit
providers.

/Kana

Re: Importing full/inactive IPv4 global table in to VRF
 

On Sun, 5 Apr 2009 05:53:48 -0700 (PDT), Kanagaraj Krishna
<kanagaraj.k@gmail.com> wrote:

>On Apr 5, 4:21*am, Stephen <stephen_h...@xyzworld.com> wrote:
>> On Sat, 4 Apr 2009 08:29:04 -0700 (PDT), Kana <kanagara...@gmail.com>
>> wrote:
>>
>> >Hi,
>> > * * Due to some specific reasons, I'm trying to import the full BGP
>> >routes from a single service provider A into a dedicated VRF of a
>> >customer (downstream BGP customer). Yes i know that importing full
>> >IPv4 global table into VRF is not scalable but in this case I have no
>> >other options. Other elements involved are:
>>
>> >- The router connecting to provider A is multihomed to multiple
>> >providers.
>>
>> >- I have to ensure all routes from provider A is not lost through BGP
>> >best path selection. The
>> > *customer has to see all routes (RIB/inactive routes) and not the
>> >best path only (FIB).
>>
>> if you only have 1 route out havent you already lost all that?
>>
>> anyhow - i havent tried this, but there is a way to avoid importing
>> all the routes.
>> if you must, try the "carrier supporting carrier" style option - you
>> will need to let a CE at each side carry the BGP, but will not need to
>> import it into the VRF.http://www.cisco.com/en/US/docs/ios/.../fscsclbl.html
>>
>
>If I'm not mistaken CSC is used to interconnect a customer carrier
>POPs through another providers MPLS backbone, ensuring labels are
>carried using BGP. But in our case, we are providing transit routes to
>the BGP customer from specific upstream without losing its routes to
>BGP best path selection. If the router connecting to the connecting to
>the upstream does not have any other external BGP session it would be
>a clear cut. In this case though its multihomed to multiple transit
>providers.

Ignore the stuff about where you think it might be applicable and
focus on what it does.

it allows an MPLS VPN to act as a transit link for a customer with
lots of BGP routes / other info without importing all the BGP routes
into the VPN.

The key is to allow label switching down to a CE router so you dont
need all those "foreign" BGP routes within your internal MP-BGP - that
can happen between the 2 (or more ) CE routers.
Or if you are not comfortable providing labels to a customer (which
AFAICT my company would not be) then you need to manage the CE routers
- but that is the only place the customer BGP tables are needed.

Basically you are pushing the customer BGP peering outside the MPLS PE
domain of your network.
>
>/Kana
--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl

Re: Importing full/inactive IPv4 global table in to VRF
 

On Apr 5, 11:13*pm, Stephen <stephen_h...@xyzworld.com> wrote:
> On Sun, 5 Apr 2009 05:53:48 -0700 (PDT),KanagarajKrishna
>
>
>
>
>
> <kanagara...@gmail.com> wrote:
> >On Apr 5, 4:21*am, Stephen <stephen_h...@xyzworld.com> wrote:
> >> On Sat, 4 Apr 2009 08:29:04 -0700 (PDT), Kana <kanagara...@gmail.com>
> >> wrote:
>
> >> >Hi,
> >> > * * Due to some specific reasons, I'm trying to import the full BGP
> >> >routes from a single service provider A into a dedicated VRF of a
> >> >customer (downstream BGP customer). Yes i know that importing full
> >> >IPv4 global table into VRF is not scalable but in this case I have no
> >> >other options. Other elements involved are:
>
> >> >- The router connecting to provider A is multihomed to multiple
> >> >providers.
>
> >> >- I have to ensure all routes from provider A is not lost through BGP
> >> >best path selection. The
> >> > *customer has to see all routes (RIB/inactive routes) and not the
> >> >best path only (FIB).
>
> >> if you only have 1 route out havent you already lost all that?
>
> >> anyhow - i havent tried this, but there is a way to avoid importing
> >> all the routes.
> >> if you must, try the "carrier supporting carrier" style option - you
> >> will need to let a CE at each side carry the BGP, but will not need to
> >> import it into the VRF.http://www.cisco.com/en/US/docs/ios/.../fscsclbl.html
>
> >If I'm not mistaken CSC is used to interconnect a customer carrier
> >POPs through another providers MPLS backbone, ensuring labels are
> >carried using BGP. But in our case, we are providing transit routes to
> >the BGP customer from specific upstream without losing its routes to
> >BGP best path selection. If the router connecting to the connecting to
> >the upstream does not have any other external BGP session it would be
> >a clear cut. In this case though its multihomed to multiple transit
> >providers.
>
> Ignore the stuff about where you think it might be applicable and
> focus on what it does.
>
> it allows an MPLS VPN to act as a transit link for a customer with
> lots of BGP routes / other info without importing all the BGP routes
> into the VPN.
>
> The key is to allow label switching down to a CE router so you dont
> need all those "foreign" BGP routes within your internal MP-BGP - that
> can happen between the 2 (or more ) CE routers.
> Or if you are not comfortable providing labels to a customer (which
> AFAICT my company would not be) then you need to manage the CE routers
> - but that is the only place the customer BGP tables are needed.
>
> Basically you are pushing the customer BGP peering outside the MPLS PE
> domain of your network.
>

Point noted on focussing on the working mechanism. And Yes, we would
not like providing the labels to our customer as well. Full global
routing table needs to sent to the customer because they are
multihomed themselves to other providers and require all the routes
for visibility and traffic control. If this was not the case a default
route injected into the VRF would have worked in providing transit.

/Kana