From: Jian Gu (guxiaojian@gmail.com)
Date: Tue Jul 25 2006 - 13:32:40 ART
With MPLS VPN, you configure vrf on R1, R2, R4 and R5, MP-BGP will allocate
a vpn lable for each FEC (prefix), this lable is not used for switching
decision on R3, so you don't need BGP running on R3. There are tons of
informaiton about MPLS VPN configuration on documentation CD.
On 7/25/06, Victor Cappuccio <cvictor@protokolgroup.com> wrote:
>
> Hmmmm So no simple solution :D
> How can you configure this scenario using MPLS?
> Thanks to both
> Victor.-
>
>
> -----Mensaje original-----
> De: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Enviado el: Martes, 25 de Julio de 2006 11:43 a.m.
> Para: Victor Cappuccio; Ivan; ccielab@groupstudy.com
> Asunto: RE: Transiting Non-BGP Speaking Devices
>
> Yes you would have to modify R3's IGP routing policy in order to
> reflect your desired BGP policy. Remember that the traffic flow of BGP
> traffic is always at the mercy of how IGP recourses to the next-hop
> value.
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Victor Cappuccio
> > Sent: Tuesday, July 25, 2006 10:25 AM
> > To: 'Ivan'; ccielab@groupstudy.com
> > Subject: RE: Transiting Non-BGP Speaking Devices
> >
> > Ivan, I know that R3 is having that problem.
> >
> > The thing here is that you need to apply your Redistribution in a Way
> to
> > guarantee that Any BGP Local Policy is reflected also in the BGP-> IGP
> > redistribution
> >
> > If you do normal redistribution (BGP -> IGP), R3 would load balance
> > between
> > the BGP routes, if running the same routing Protocols with R1 and R2.
> > But Say that R1 - R3 is running a different Routing Protocol that R3 -
> R2
> > That makes things harder right?
> >
> > I hope a Routing Guru could chip in here.
> >
> > Thanks
> > Victor.
> >
> >
> > -----Mensaje original-----
> > De: Ivan [mailto:ivan@iip.net]
> > Enviado el: Martes, 25 de Julio de 2006 11:13 a.m.
> > Para: ccielab@groupstudy.com; Victor Cappuccio
> > Asunto: Re: Transiting Non-BGP Speaking Devices
> >
> > This issue appears because R3 don't know about external BGP routes. To
> > force
> >
> > R3 learn BGP routes you can redistribute to IGP or set static route to
> > some
> > gateway.
> >
> > Also synchronisation may guarantee that all routers have consistent
> FIB.
> > If choose synchronisation, there must be a match for prefixes in IP-
> > routing
> > table to iBGP path consider as valid. Usually this prefixes extend
> with
> > IGP
> > therefore all routers on path "know" about originating this prefixes.
> In
> > this
> > case need to note about OSPF RID and BGP RID. I think in this case
> > redistribution must take place.
> >
> > > Hi Brian, thanks for your reply
> > >
> > > What I'm trying to do here, is to obtain global rechability, but R3
> in
> > this
> > > case is not running BGP.
> > >
> > > I know that I can peer the loopback of the remote-neighbor, but if I
> > ping
> > > from R5 to any BB attached to R1 or R2; R3 would drop all Packets,
> sat
> > that
> > > R1 and R2 peer to BB1 and BB3 and this 2 routers belongs to AS 54
> > > (something similar to your WB topology, but with BB1 also connected
> to
> > Sw2
> > > in port f0/23)
> > >
> > > Yes: R1,R2,R4,R5 are in the same AS; and they peer to each other in
> a
> > full
> > > mesh fashion using their loopbacks.
> > >
> > >
> > > for example lets say that R2 -- BB3 is setting the local Preference
> 200
> > for
> > > all BGP routes and a weight of 1000; and R1 -- BB1 is setting the
> Local
> > > Preference for all BGP route to 100 and a Weight of 1000.
> > >
> > > If you see the BGP Routing Table at R4 or R5, if would prefer R2 to
> exit
> > > the AS, but if you trace the BGP route it would be droped at R3,
> another
> > > point here is that when you redistribute BGP routes into IGP, it
> would
> > not
> > > respect the Local AS Policies, so simple redistribution could not be
> > > accomplished (I think).
> > >
> > > I know this is disparate, but it would be nice to have something
> like a
> > > Multipoint Tunnel at each router.
> > >
> > > Please let me know if you need some more information
> > > Saludos and Thanks
> > > Victor.-
> > >
> > >
> > >
> > > -----Mensaje original-----
> > > De: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> > > Enviado el: Martes, 25 de Julio de 2006 10:04 a.m.
> > > Para: Victor Cappuccio; ccielab
> > > Asunto: RE: Transiting Non-BGP Speaking Devices
> > >
> > > Victor,
> > >
> > > What exactly are you trying to accomplish, IP reachability
> > > between R1, R2, R4, and R5? Are they all in the same AS? Where are
> the
> > > prefixes coming from?
> > >
> > >
> > > Brian McGahan, CCIE #8593
> > > bmcgahan@internetworkexpert.com
> > >
> > > Internetwork Expert, Inc.
> > > http://www.InternetworkExpert.com
> > > Toll Free: 877-224-8987 x 705
> > > Outside US: 775-826-4344 x 705
> > > 24/7 Support: http://forum.internetworkexpert.com
> > > Live Chat: http://www.internetworkexpert.com/chat/
> > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> Behalf
> > >
> > > Of
> > >
> > > > Victor Cappuccio
> > > > Sent: Monday, July 24, 2006 10:00 PM
> > > > To: 'ccielab'
> > > > Subject: Transiting Non-BGP Speaking Devices
> > > >
> > > > Hi Guys, I know this is a very newbie question, but it keeps
> spinning
> > >
> > > in
> > >
> > > > my
> > > > head.
> > > >
> > > > Ok this is the dilemma
> > > >
> > > > R1 --- R3 ---- R2
> > > >
> > > > R1-R2-R3 runs any IGP.
> > > >
> > > > R1 and R2 are running BGP in AS 12 and they peer via each other
> > >
> > > Loopback
> > >
> > > > Address (/32 BTW).
> > > >
> > > > So, I need to solve the Non-BGP Transitive Device Problem, I know
> that
> > >
> > > I
> > >
> > > > can
> > > > use tunnels or maybe redistribute BGP routes at R2 and R1.
> > > >
> > > > But the question is more difficult (for me at least); say that I
> add
> > > > another
> > > > 2 BGP Devices connected to R3
> > > >
> > > > R5
> > > > .
> > > > .
> > > > R1 ------ R3 ------ R2
> > > > .
> > > > .
> > > > R4
> > > >
> > > > I need to create a full mesh BGP Session between R1; R2; R5; R4
> using
> > > > their
> > > > loopbacks Address (/32 BTW).
> > > >
> > > > So creating tunnels here is out of the game, because you can not
> add
> > >
> > > extra
> > >
> > > > Ip addressing.
> > > >
> > > > Now redistributing the BGP Routes to the current IGP, would NOT
> help
> > >
> > > me if
> > >
> > > > I
> > > > need to create some AS Policies. - Like Local Preference.
> > > >
> > > > Maybe MPLS would solve the problem (do not know how to configure,
> and
> > >
> > > I
> > >
> > > > think that would be out of the scope of the CCIE Lab for now)
> > > >
> > > > Any recommendations for this particular problem?
> > > >
> > > > Thanks
> > > > Victor.-
> > >
> > >
> _______________________________________________________________________
> > >
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> >
> ************************************************************************
> **
> > *
> >
> >***********************************************************************
> **
> > **
> > *
> > >********************** REGULACISN DEL USO DEL CORREO ELECTRSNICO -
> > Protokol,
> > > Grupo de Informatica y Telecomunicaciones, C.A. La informacisn
> contenida
> > en
> > > este correo electrsnico y cualquier anexo puede ser de caracter
> > > confidencial y es propiedad de Protokol Grupo de Informatica y
> > > Telecomunicaciones, C.A. Sslo esta permitido su uso, copia,
> transmisisn,
> > > recepcisn o distribucisn a personas debidamente autorizadas. Si
> usted
> > > recibis este correo por error por favor destrzyalo y/o elimine
> cualquier
> > > copia guardada en su sistema y notifique inmediatamente al remitente
> o a
> > la
> > > direccisn de correo electrsnica soporte@protokolgroup.com. Usted no
> debe
> > > utilizar la informacisn contenida para ningzn propssito ni
> compartirla
> > con
> > > otras personas.
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> > --
> > Ivan
> >
> ************************************************************************
> **
> >
> ************************************************************************
> **
> > *************************
> > REGULACISN DEL USO DEL CORREO ELECTRSNICO - Protokol, Grupo de
> Informatica
> > y Telecomunicaciones, C.A.
> > La informacisn contenida en este correo electrsnico y cualquier anexo
> > puede ser de caracter confidencial y es propiedad de Protokol Grupo de
> > Informatica y Telecomunicaciones, C.A. Sslo esta permitido su uso,
> copia,
> > transmisisn, recepcisn o distribucisn a personas debidamente
> autorizadas.
> > Si usted recibis este correo por error por favor destrzyalo y/o
> elimine
> > cualquier copia guardada en su sistema y notifique inmediatamente al
> > remitente o a la direccisn de correo electrsnica
> > soporte@protokolgroup.com. Usted no debe utilizar la informacisn
> contenida
> > para ningzn propssito ni compartirla con otras personas.
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> *****************************************************************************************************************************************************************************
> REGULACISN DEL USO DEL CORREO ELECTRSNICO - Protokol, Grupo de Informatica
> y Telecomunicaciones, C.A.
> La informacisn contenida en este correo electrsnico y cualquier anexo
> puede ser de caracter confidencial y es propiedad de Protokol Grupo de
> Informatica y Telecomunicaciones, C.A. Sslo esta permitido su uso, copia,
> transmisisn, recepcisn o distribucisn a personas debidamente autorizadas. Si
> usted recibis este correo por error por favor destrzyalo y/o elimine
> cualquier copia guardada en su sistema y notifique inmediatamente al
> remitente o a la direccisn de correo electrsnica soporte@protokolgroup.com.
> Usted no debe utilizar la informacisn contenida para ningzn propssito ni
> compartirla con otras personas.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:48 ART