From: Olopade Olorunloba (lolopade@ipnxnigeria.net)
Date: Mon Apr 03 2006 - 14:48:47 GMT-3
Hello Arun,
Thanks for the email, and I will like to say that I quite agree with a
number of the things you said, but not all.
First, like you said both solutions can work. So anyone can actually decide
to use either.
With respect to the two discussions.
1) CCIE Lab Requirement. I will like to agree with you on this point. Unless
we are specifically allowed to configure extra loopbacks, the solution will
not be permitted in the CCIE lab.
2) Best Practice. I will almost agree with you on the best practice except
for the following points.
a) Key to the solution is not the TE tunnel, but the ability to change
advertised BGP next-hop address. Check my former mail where I gave an
example of how to configure without use TE tunnels.
b) I tried to configure the VPNV4 across physical interfaces, but I did
not get any host routes. I therefore see this as a potential failure point.
And if we have a potential failure point, can we talk about best practices
(I'm interested in how you got the host route, if you have documentation on
this I will appreciate it). Other than configuring an host route and
redistributing it into the IGP, I'm not sure how else. Configuring a static
route will however not be permitted in CCIE labs also.
c) If the backup link transverses more than one router, then the whole
solution breaks down. Hence the solution is not scalable because it does not
allow for the introduction of an additional hop.
d) I'm not sure about your point with reference to ASBR and Inter-AS
setup.
I will like to say again that the solution does not depend on TE. It is just
that TE tunnels are the best way to manipulate traffic paths on a network.
If the two PEs are directly connected, then the TE is really not needed, as
there is no manipulation to be done on intermediate routers. However, if
there are multiple intermediate routers on the backup link, then TE will be
recommended, as against 2 static routes on each intermediate router.
Like has been said, both solutions could work, but one solution (to me) has
more failure points and also less scalable. In real life, I will go for a
solution that works and is scalable. For the CCIE exam, I will read
in-between the exam questions to know what they want me to configure.
Hope you agree with some of these as well, and I will still appreciate your
input with respect to the host route.
Thanks
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Arun
Arumuganainar
Sent: 03 April 2006 14:52
To: Olopade Olorunloba; jbrentfoster@yahoo.com; ccielab@groupstudy.com;
comserv@groupstudy.com
Subject: Re: OT: how to filter out several VPNs from a MPLS backbone backup
path
Hi Olopde ,
Pls. Note :To begin with , I tend to belive both solutions will work . But
question is what suits us the best .
Let us split this in two discussion . 1) Does it solve CCIE Lab requirement
2) Does this design inline with Cisco's best practices . I would like to
discuss this one-by-one .
CCIE Lan requirement :-
~~~~~~~~~~~~~~~~
One of the important rule in CCIE Lab : DO not create any addtional
interface and/or do not configure any additional address on any of the
address unless you are asked to do this explicitely .
If the question does not talk about additional loopback interface and
associated ip-address ...you are assured of loosing the marks for this
question ( Pls. do let me know if you have differing opinion ) .
Cisco Best Practices- A discussion :-
~~~~~~~~~~~~~~~~~~~~~~~~
As a matter of fact , TE is higly resource consuming . This is do for the
following reason .
1 ) It maintains TE Topology database ( Needs more Memory )
2) It send out query through the path before it can bring up the tunnel (
Takes time to get established )
3) It need to send RSVP refresh information and need to maintain RSVP states
( Requires Valuable processor resource and bandwidth) .
Due to these factors ,this solution is very much undesirable in service
provider environment . It is especialy so when you can easily do the same
via other means that is simple and more elagant .
Whats wrong with BGP Solution ( Problems with Physical address that use for
peering ) .
~~~~~~~~~~~~~~~~~~~~~
Yes you prefectly right !!! This problem does exists when you peer with
physical address . However workaround does exists .
When ever you create a bgp peering with physical interface and activate it
for send-label ( Note : When you activate a peering for VPNV4 address family
send-label is enabled by default ) ...then a connected /32 bit route is
added to routing table for remote side peer address automatically . This is
sample o/p that I have taken in my setup !!!
Router1#sh ip route | i 172.16.16.
C 172.16.16.6/32 is directly connected, Ethernet0/0.16
C 172.16.16.0/24 is directly connected, Ethernet0/0.16
Pls. Note : You can find that in addition to /24 you can also a find a
connected /32 route added to the routing table .
Our job is to simply redistribute this in to our IGP . Once this is done
connectivity will not be a problem .
Pls. note : You can refer to Inter-as VPN option 2 with out Next-hop-self on
the ASBR !!!
Hope you will agree with my conclusions .
Thanks and Regards
Arun
----- Original Message -----
From: "Olopade Olorunloba" <lolopade@ipnxnigeria.net>
To: "'Arun Kumar Arumuganainar'" <aarumuga@hotmail.com>;
<jbrentfoster@yahoo.com>; <ccielab@groupstudy.com>; <comserv@groupstudy.com>
Sent: Saturday, April 01, 2006 2:45 AM
Subject: RE: OT: how to filter out several VPNs from a MPLS backbone backup
path
> Hello Arun,
>
>
>
> I will like to disagree with you. First, the introduction of TE tunnels
does
> not add many problems to the MPLS VPN setup, if properly configured. After
> configuring an MPLS TE tunnel and ensuring that it is not advertised to
IGP,
> via the autoroute announce command, the setup and operation of the MPLS
VPN
> has in wise changed. The TE tunnel will not carry any traffic and
> complexities has been added.
>
>
>
> With respect to peering on physical addresses for iBGP sessions, this is
> strongly not recommended for MPLS VPN. Allow me to explain. MPLS VPN
traffic
> are tagged with a two label stack, the topmost being the label for the BGP
> next-hop and second being the VPN label assigned by the egress PE router.
> For MPLS VPN to operate properly, the VPN label must never be exposed
until
> the label packet reaches the egress PE router. When the iBGP peerings are
> across loopbacks addresses, the egress PE advertises a POP label for the
> loopback to all her LDP peers. Hence, VPN traffic reaches the router with
> just the VPN label (one label stack). The situation is not too different,
if
> the peering is done with physical addresses, as those addresses are
> advertised with POP labels as well. However, there is an exception. In the
> case of the loopback, the interface exists only on the egress PE router,
so
> it is the only router on the network that advertises the POP label.
However,
> when using the physical address for peering, at least two routers will
> advertise the POP labels, the egress PE router and the other router at the
> end of the link. If the path of the VPN traffic passes through the other
> router, then the VPN label will be exposed before getting to egress PE
> router, breaking the VPN.
>
>
>
> It would seem that if the backup link is a direct connection between the 2
> PE routers that the solution might work, but then it will not scale. And
> considering the Inter-AS possibilities, you would definitely have more
> problems with the broken LSPs.
>
>
>
> Let me describe the other solution, because I think it is simple (can even
> be achieved without TE tunnels).
>
>
>
>
>
> Using TE Tunnels
>
> Step 1.
>
> Establish the simple VPN.
>
>
>
> Step 2.
>
> Assign one additional loopback each on the PEs where the VPNs are located
> that you need.
>
> interface Loopback1
>
> ip address a.b.c.d 255.255.255.255
>
> end
>
>
>
> Step 3
>
> Create an MPLS TE tunnel from the PEs ensuring that autoroute announce is
> not used i.e. it is not advertised into IGP. Also, the path option should
be
> through the backup link. You can use any means to achieve this like
explicit
> path, affinity bits etc.
>
> interface Tunnel0
>
> ip unnumbered Loopback1
>
> tunnel destination
>
> tunnel mode mpls traffic-eng
>
> tunnel mpls traffic-eng path-option 1 explicit name VDT
>
> end
>
>
>
>
>
> At this stage, everything still works normal and the operation of the
> network has not changed.
>
>
>
> Step 4
>
> Use a static route to route the remote loopback address down the TE
tunnel,
> on both PEs
>
> ip route a.b.c.d 255.255.255.255 Tunnel0
>
>
>
> Step 5
>
> Change the bgp next-hop on the VPNs by using the bgp next-hop command on
the
> vrf configuration. This will now make the traffic to go down the TE tunnel
> and which is through the backup link.
>
> ip vrf VPN
>
> bgp next-hop Loopback1
>
>
>
>
>
> Without TE tunnels
>
> Step 1.
>
> Establish the simple VPN.
>
>
>
> Step 2.
>
> Assign one additional loopback each on the PEs where the VPNs are located
> that you need.
>
> interface Loopback1
>
> ip address a.b.c.d 255.255.255.255
>
> end
>
>
>
>
>
> Step 3
>
> Create static routes for the remote PEs along the path between the two
PEs.
> Ensure that the mask of the static routes are the same along the path, and
> the same with the mask of the loopback address.
>
>
>
> At this stage, everything still works normal and the operation of the
> network has not changed.
>
>
>
> Step 4
>
> Change the bgp next-hop on the VPNs by using the bgp next-hop command on
the
> vrf configuration. This will now make the traffic to go down the path of
the
> static routes you have created, which is through the backup link.
>
>
>
> The disadvantage of using the static route option is that the traffic can
> not failover.
>
>
>
>
>
> I do not see any problems also with Inter-AS solutions. Note that you will
> not create a TE across ASes.
>
>
>
> I hope this helps.
>
>
>
>
>
>
>
>
>
> _____
>
> From: Arun Kumar Arumuganainar [mailto:aarumuga@hotmail.com]
> Sent: 31 March 2006 19:54
> To: lolopade@ipnxnigeria.net; jbrentfoster@yahoo.com;
> ccielab@groupstudy.com; comserv@groupstudy.com
> Subject: RE: OT: how to filter out several VPNs from a MPLS backbone
backup
> path
>
>
>
> Hi all ,
>
> I would think brent has hit the nail on its head . The real solution to
the
> problem has been hijacked by our discussion over TE and its related
solution
> . I think we should think out of the boxhere . I would think , the
> introduction of TE in MPLS VPN set up adds up many problems than it is
> intended to solve .
>
> First of all TE solution will not be scable . TE has serious limitation
when
> it comes to inter-as setup. Hence scalability of the solution is big
> question mark . On the other hand we do have a simple and elegant solution
> Let me describe this .
>
> Pls. Note : First build a simple VPN ( with out configuring the backup
link
> ) . Over that setup perform the following step
>
> Step 1 : Create a BGP Peering ( Either iBGP or eBGP ) using physical
> interface of the back up link as the peering address .
>
> Discussion on the configuration :- There is no need to configure addtional
> loopback even when your setup is a simple single AS setup . Pls. Note :
Loop
> Back peering is not a requirement of iBGP it is just an option . It just
> gives us a more reliability to the BGP peering during the events of
internal
> topology changes . In our case there is no need to protect backup peering
> and hence we need not use any loopback.
>
> step 2 :- Activate vpnv4 address family for this peering on both sides .
>
> step 3 :- Filter out vpnv4 prefixes so that only the routes belongs to VRF
> that are eligible for BACKUP link usage gets advertised . This can be done
> in the following ways .
>
> Let us say allowed VRF are has got export RT set to say 100:100 100:101
> 100:1002 then skeleton configuration will look like this .
>
> router bgp 100
>
> no bgp default ipv4 unicast
>
> neighbor 10.10.10.1 remote-as 100
>
> address-family vpnv4
>
> neighbor 10.10.10.1 activate
>
> neighbor 10.10.10.1 route-map rt-based-filter out
>
> route-map rt-based-filter permit 10
>
> match extcomm 10
>
> ip ext-community 10 permit rt 100:100 100:101 100:102
>
> step 4: use an incoming prefix list and set a very low admin wight for
this
> peering . This in effect will prevent the backup link to be use when
primary
> is up .
>
> Pls. Note : This design is very elegant in the sense existing MPLS VPN
> setup is not touched at all . Only thing you add is bgp peering for vpnv4
> address family. It is also scalable and will work just fine even for
> inter-as-vpn .
>
> Thanks and Regards
>
> ARun
>
>
> _____
>
>
> From: "Olopade Olorunloba" <lolopade@ipnxnigeria.net>
> Reply-To: "Olopade Olorunloba" <lolopade@ipnxnigeria.net>
> To: "'Brent Foster'" <jbrentfoster@yahoo.com>, "'Cisco certification'"
> <ccielab@groupstudy.com>, <comserv@groupstudy.com>
> Subject: RE: OT: how to filter out several VPNs from a MPLS backbone
backup
> path
> Date: Thu, 30 Mar 2006 21:54:14 +0100
> I do not think that you can use this feature.
>
> The ip extcommunity-list is helpful in import and export route-map
> configuration. It can help to give a tighter control on which routes are
> imported into which VPN or not.
>
> You could also consider applying the filtering on a per-link basis.
However,
> iBGP is often established over loopback addresses, and the actual link
over
> which the connection is established is determined by the IGP. Also, you
> would need to have two connections active between the routers, implying
that
> both routers would need to have 2 loopbacks addresses. This is necessary,
> since on one connection the desired vpn routes will be filtered out, and
on
> the other, they will be the only one permitted.
>
> Asides all these, you will still need to ensure via your IGP, that one
> loopback is reachable across a link, the other loopback across the other
> link. This almost reduces the solution to the previous one. This scheme
> sounds more troublesome to me.
>
> One thing to note is that for a BGP learnt route, the actual forwarding
path
> depends on the forwarding path for the BGP next-hop according to the IGP.
> Also, MPLS VPN routes are learnt via BGP, hence to modify the forwarding
> path for the VPN, it is the forwarding path of the BGP next-hop in the IGP
> that needs to be modified.
>
> The use of the BGP next-hop command in the Vrf and the TE tunnel (unless,
> you want to configure static routes all the way from the ingress to the
> egress) seems to me a very good solution.
>
> By the way, I have this solution working on my network.
>
> Regards.
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Brent Foster
> Sent: 30 March 2006 16:31
> To: Cisco certification; comserv@groupstudy.com
> Subject: Re: OT: how to filter out several VPNs from a MPLS backbone
backup
> path
>
> So, I think I answered my own question here. See this
> link...
>
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hirp_r
> /rte_bgh1.htm#wp1074763
>
> "The ip extcommunity-list command is used to configure
> named or numbered extended community lists. Extended
> community attributes are used to filter routes for VPN
> routing and forwarding instances (VRFs) and
> Multiprotocol Label Switching (MPLS) Virtual Private
> Networks (VPNs)."
>
> I'll test this, but I believe this may be a better
> solution to the problem.
>
> --Brent
>
> --- Brent Foster <jbrentfoster@yahoo.com> wrote:
>
> > I went back and looked at the original problem
> > statement on this thread. We want to restrict
> > certain
> > VPN traffic from the backup link, right? It might
> > even be desirable to have the backup link carry this
> > VPN traffic if there is a failure on the primary
> > links
> > right?
> >
> > Could there be a different approach using BGP
> > filtering techniques since VPNs are simply carried
> > as
> > MP-BGP routes with route-targets carried as extended
> > BGP communities? Could we somehow filter on those
> > communities and even use advertise-map/non-exist-map
> > techniques to allow the backup link to carry these
> > VPNs if there is a failure?
> >
> > Just thinking out of the box for a different
> > solution
> > to this problem. It is an interesting one!
> >
> > --Brent
> >
> > --- Reinhold Fischer <Reinhold.Fischer@gmx.net>
> > wrote:
> >
> > > On Fri, Mar 24, 2006 at 12:50:28PM +0200,
> > > sheherezada@gmail.com wrote:
> > > > Hi all,
> > > >
> > > > I have four routers linked in a row, let's say
> > > A-B-C-D, and a lower
> > > > bandwidth backup link between A and D. I have
> > just
> > > added MPLS and set
> > > > up several VPNs, but I don't want all VPNs to
> > > generate traffic on the
> > > > backup link when it comes up. Any idea of how to
> > > do it?
> > > >
> > > > Thanks,
> > > >
> > > > Mihai
> > > >
> > >
> > > Hi Mihai,
> > >
> > > here is a possible solution. I have put also the
> > > CCIE SP list on CC
> > > since this is more a topic for there...
> > >
> > > - create a second loopback interface on the
> > > pe-routers.
> > >
> > > - add your second loopback interface into your igp
> > > so it is reachable
> > >
> > > - filter your LDP so it is not assigning and
> > > distributing any labels
> > > for this second loopback
> > >
> > > - change the next-hop ip-address that bgp will
> > > advertise for the
> > > VPN that you do not want to have on the
> > > low-bandwidth backup link
> > >
> > > Example> Assuming Lo1 is the Loopback where you
> > > are not distributing labels
> > > for:
> > > !
> > > ip vrf TWO
> > > rd 2:1
> > > route-target export 2:1
> > > route-target import 2:1
> > > bgp next-hop Loopback1
> > > !
> > >
> > > - at this point this VPN will not work anymore,
> > > because you have no
> > > LSP to the new Loopbacks
> > >
> > > - enable MPLS Traffic Engineering, use the new
> > > loopback ip as router-id
> > > for mpls traffic engineering
> > >
> > > - build mpls-te tunnels between the new loopback
> > > addresses. Use an
> > > explicit path that excludes the ip addresses of
> > > the low-bandwidth
> > > backup link.
> > >
> > > - at this point the VPN will work again. LSPs are
> > > provided through
> > > MPLS-TE. As soon as the main link between your
> > PE
> > > routers goes
> > > down the MPLS-TE Tunnel will also go down
> > because
> > > they are not
> > > allowed to signal a path through your
> > > low-bandwidth link.
> > >
> > > hope the explanation is not too confusing.
> > >
> > > regards
> > >
> > > reinhold
> > >
> > >
> >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> >
> _____________________________________________________________________
> > > Subscription information:
> > > http://www.groupstudy.com/list/comserv.html
> > >
> >
> >
> > Brent Foster
> > jbrentfoster@yahoo.com
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > http://mail.yahoo.com
> >
> >
> _____________________________________________________________________
> > Subscription information:
> > http://www.groupstudy.com/list/comserv.html
> >
>
>
> Brent Foster
> jbrentfoster@yahoo.com
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _____________________________________________________________________
> Subscription information: http://www.groupstudy.com/list/comserv.html
>
> _____________________________________________________________________
> Subscription information: http://www.groupstudy.com/list/comserv.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon May 01 2006 - 11:41:56 GMT-3