From: Arun Arumuganainar (aarumuga@hotmail.com)
Date: Mon Apr 03 2006 - 10:52:12 GMT-3
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