The MPLS-OPS Archive

[Ajay Simha <asimha@cisco.com>]

On Sat, 27 Jul 2002, Rajiv Asati wrote:

>RA:Hi,
>RA:
>RA:Please see inline...
>RA:
>RA:At 01:54 PM 7/27/2002, M. ELK wrote:
>RA:>Hi
>RA:>
>RA:>Ref :
>RA:><http://www.cisco.com/warp/public/cc/pd/rt/2600/prodlit/1575_pp.htm>http://www.cisco.com/warp/public/cc/pd/rt/2600/prodlit/1575_pp.htm
>RA:>
>RA:>http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/vpnsc/mpls/2_2/prov_gd/
>RA:>
>RA:>
>RA:>AA- The first ref does not address clearly how to connect a Multi-VRF CE
>RA:>to a PE using eBGP .
>RA:
>RA:Well, configuring BGP in the Multi-VRF CE is nearly the same as configuring
>RA:it on the PE. :)
>RA:
>RA:>The 2nd Ref (page 11-9) provide a template .
>RA:
>RA:Yes.
>RA:
>RA:>Any doc which list a complete config for Multi-VRF CE using
>RA:>ebgp to connect to a PE router ??
>RA:
>RA:I am not sure if I understand you correctly.
>RA:The page11-9 indeed provides the necessary config needed to configure  the
>RA:CE router.
>RA:Are you asking about the both PE and CE config when eBGP is used as a PE-CE
>RA:protocol.
>RA:
>RA:>
>RA:>
>RA:>BB-from ref 2 : say for 5 VRF on the CE , is it mean a ebgp session per
>RA:>VRF between the CE and the PE ??
>RA:
>RA:Yes. So we will end up configuring "address-family ipv4 vrf <name>" for
>RA:each VRF in the BGP.
>RA:So the BGP config on the CE will look like as follows:
>RA:~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>RA:bgp <AS#1>
>RA:!
>RA:  address-family ipv4 vrf v1
>RA:  neighbor x1 remote-as <AS#2>
>RA:  neighbor x1 activate
>RA:  !
>RA:  address-family ipv4 vrf v2
>RA:  neighbor x2 remote-as <AS#2>
>RA:  neighbor x2 activate
>RA:  !
>RA:  address-family ipv4 vrf v3
>RA:  neighbor x3 remote-as <AS#2>
>RA:  neighbor x3 activate
>RA:  !
>RA:~~~~~~~~~~~~~~~~~~~~~~~
>RA:And the PE's config will look like this:
>RA:
>RA:bgp <AS#2>
>RA:!
>RA:  address-family ipv4 vrf v1
>RA:  neighbor x1 remote-as <AS#1>
>RA:  neighbor x1 activate
>RA:  !
>RA:  address-family ipv4 vrf v2
>RA:  neighbor x2 remote-as <AS#1>
>RA:  neighbor x2 activate
>RA:  !
>RA:  address-family ipv4 vrf v3
>RA:  neighbor x3 remote-as <AS#1>
>RA:  neighbor x3 activate
>RA:  !
>RA:
>RA:>
>RA:>Could be easier if the CE  and PE run a modified eBGP VPNV4 .
>RA:
>RA:Slight correction: PE-CE are not required to run eBGP VPNv4.. rather they
>RA:run the normal eBGP (ipv4) session. :)
>RA:As we know, eBGP VPNv4 could be interpreted as MP-eBGP which might be run
>RA:in the Inter-AS case.
>RA:
>RA:>  a modified in the sense :
>RA:>At the PE :
>RA:>Say the 5 VRF are VRf1 ...VRF5
>RA:>
>RA:>  interface s1
>RA:>  ip Vrf Forwarding Vrf1,Vrf2,Vrf3,Vrf4,Vrf5
>RA:>
>RA:>address-family VPNV4 VRF vrf1,Vrf2,Vrf3,Vrf4, Vrf5
>RA:>Nei CE remote-as XXX
>RA:>...
>RA:>...
>RA:>
>RA:>a VPNV4 context is configured per VRF(s) and an interface could be
>RA:>linked to several VRF's .
>RA:>
>RA:>For outgoing eBGP update : advertise route from those VRF routing table ,
>RA:>no RT ext-community will be exported .
>RA:>
>RA:>For incoming eBGP update : import the route to the correspending
>RA:>VRF based on the RD value .
>RA:>(Those recieved eBGP VPNV4 update are within the context of  the sepcified
>RA:>VRF (Vrf1 ...VRf5) which mean that they are not propagated to
>RA:>    other PE's ) .
>RA:
>RA:Well, what if the CE is connected to more than one PE in that VRF. :)

Well Rajiv beat me to it. Also the idea behind "vrf lite" is that the CE-PE
(CE router that is vrf-aware) should not be tasked with the ibgp peering. It
is only aware of the vrfs that it is connected to. Also there is no MPLS
running on the PE-CE link.

-ajay

>RA:
>RA:>
>RA:>at the CE :
>RA:>
>RA:>Addrres-family VPNV4 vrf vrf1,vrf2,vrf3,vrf4,vrf5
>RA:>nei PE remote-as YYY
>RA:>....
>RA:>
>RA:>  .
>RA:>
>RA:>In such case their is  no need to have a sub-interface for each VRF
>RA:>between the CE and the PE , Separation of VRF traffic is now based on the
>RA:>label .
>RA:
>RA:Well, I don't think that the above approach is viable in the current
>RA:implementation, so I will leave it for others to comment. But if the number
>RA:of subinterfaces is the concern, then GRE tunnel per VRF could be an
>RA:alternative.
>RA:
>RA:>
>RA:>(May be the above is something like Inter-AS RFC 2547 option "a" but
>RA:>  now is VRF's-to-VRF's  instead of VRF-to-VRF still it is not full fledge
>RA:>as option "c" or option "b" )
>RA:>
>RA:>CC- For a Multi-VRF over a CE where it is connected to PE using
>RA:>   eBGP (one eBGP session per VRF) ,it is not clear the benefit
>RA:>   (in term of mem and CPU ) of such setup versus the CE runing full
>RA:> PE-functionality . Pls clarify .
>RA:
>RA:Well, multi-VRF is for the CE that is not required to run MPLS.. and only
>RA:needs basic VRF configuration. Nothing fancy. So VRF concept gets used to
>RA:provide the isolation of routing information at the CE itself, without
>RA:involving MPLS.
>RA:We could certainly extend the PE functionality at the CE, but then you end
>RA:up with CsC architecture and then we don't need multiple interfaces on the
>RA:PE-CE. It really comes down to the requirement and type of box.
>RA:
>RA:Please let me know if I could be of further help.
>RA:
>RA:Cheers,
>RA:Rajiv
>RA:
>RA:>
>RA:>Brgds
>RA:>
>RA:>
>RA:>----------
>RA:>Join the world's largest e-mail service with MSN Hotmail. Click Here
>RA:>------- The MPLS-OPS Mailing List Subscribe/Unsubscribe:
>RA:>http://www.mplsrc.com/mplsops.shtml Archive:
>RA:>http://www.mplsrc.com/mpls-ops_archive.shtml
>RA:


-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml