[c-nsp] VRF question
mike butash
der.mikus at gmail.com
Sun Oct 10 00:53:43 EDT 2004
I'd implemented VRF's initially less for QoS purposes, and more for
the need to carry public and private internal traffic across the same
link between pop's, and VRF's do so wonderfully with little effort
between a pair of 7304's and a POS OC3.
MPLS VPN's seem fairly easy to manage until you get into managing RD
exchanges with external sources, then I can see things getting hairy
if you have a lot, but it's akin to managing bgp community exchanges,
filtering them appropriately for security reasons. Depending on
complexity of the environment and what services you offer your
*customers*, for TE you may end up having to manage quite a bit of
static routing for tunnel input of certain traffic or PBR maps across
the architecture, though most of the time autoroute suffices in
non-carrier, non-complex environments.
We're in the process now of building a metro ethernet backbone between
4 sites using 7304's, 6500's, sup720-3bxl's, and gige to implement TE
for bandwidth management and redundancy (fast re-route) in the PE/P's.
While a tad daunting to implement and scale properly, I believe it
will be worth it in the long run, but I can already see the need for a
real management platform just to keep track of bandwidth allocations
globally so as not to oversubscribe links. BTW, any suggestions for
_good_ management platforms for VPN's, TE, QoS? Cisco software scares
me anymore that it's generally so buggy and unaccommodating.
Other design issues to be aware of relate to QoS and managing numerous
class of service queue's properly with tunnels for differentiated
services, which when you start talking about interfaces that can now
do 1p3q8t on all gigs or 10g that does 1p7q8t. Again, defaults will
probably suffice for most, but eventually I can see this getting more
and more complex as we grow, but mostly for the LAN side. With MPLS,
you're down to 3 bits (ala ToS) to set the EV's for qos, so it's not
nearly as granular as DSCP's 6, but also you probably don't want to
manage the complexity of more than 8 queues if you're a carrier. You
just map *customer* ToS/DSCP to EV's and forward. So long as traffic
is colored/marked at the LAN edge and carried through, it's fairly
straight forward at the backbone PE's.
If you implement TE and MPLS where you act as the *carrier* and the
*customer*, do yourself a favor and define boundaries of where you
LAN's end (CE) and where the WAN's begin (PE). I'd tried to treat them
as one big backbone for end to end provisioning, but things got real
hairy fast doing so, and confused the hell out of me. Much better now
treating them as two entities.
-mb
On Fri, 08 Oct 2004 12:42:25 -0400, dave bernardi
<dave.bernardi at adelphia.net> wrote:
> So for those service providers running a (native?) MPLS backbone you'd likely carry your global internet routing table in a VRF where you could also set EXP bits to distinguish it from other services you provide, VoIP, L2/L3 VPN, etc., across the backbone. From what I can tell most IP features would still be available by the IP edge functionality of your router (7600 platform) even if it is also the PE, correct? Any thoughts on what features would be lost in this case as opposed to a separate PE and stand alone dedicated IP router for Internet service?
>
> Depending on what IP features are lost it might be a better approach to run a hybrid MPLS backbone where you might leave Internet traffic as IP switched (untagged) and label switch L2/L3-VPNs, for example.
>
> How many of you are running a native MPLS backbone and was the major determining factor VPN, QoS, or other?
>
> -DaveB
>
>
>
> At 09:38 AM 10/8/2004 -0400, Rodney Dunn wrote:
> >You can pretty much bet any feature that relies on
> >identifying traffic by ip address/port information
> >will not work.
> >
> >That is in a tag->tag path.
> >
> >If you get to the point where it's ip2tag or tag2ip then
> >some of the ip features can work depending on how and
> >where they are applied.
> >
> >If you want QOS that's why the precedence is copied to
> >the EXP bits at the place in the network where it's
> >ip2tag. You can then build your QOS policies matching
> >on EXP bits rather than trying to match on the precedence
> >bits of the underlying ip header.
> >
> >Rodney
> >
> >
> >On Fri, Oct 08, 2004 at 09:10:43AM +1000, Phil Pierotti wrote:
> > > "once you do MPLS you can't do a lot of other features that are done on IP
> > > packets"
> > >
> > > Anyone care to *briefly* outline these? (features excluded by using MPLS)
> > > Or quote an URL which does?
> > >
> > > Thanks,
> > > Phil Pierotti UnitedIP
> > > Unit 16 , 4a Foundry Road
> > > Network Operations Manager Seven Hills NSW 2147
> > > http://www.unitedip.net.au/
> > >
> > >
> > > >-----Original Message-----
> > > >From: cisco-nsp-bounces at puck.nether.net
> > > >[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rodney Dunn
> > > >Sent: Friday, 8 October 2004 3:24 AM
> > > >To: jcvaraillon at dolnet.gr
> > > >Cc: cisco-nsp at puck.nether.net
> > > >Subject: Re: [c-nsp] VRF question
> > > >
> > > >You can do MPLS without VRF's.
> > > >
> > > >You really don't buy yourself anything doing MPLS in your
> > > >scenario. It just adds another level of complexity to the mix
> > > >so I wouldn't do it.
> > > >
> > > >You would do MPLS when you need something like:
> > > >VPN's
> > > >To take BGP out of the core
> > > >TE
> > > >
> > > >You don't have either of those so you probably shouldn't mess with it.
> > > >
> > > >The raw switching improvement isn't that much at all anyway
> > > >and once you do MPLS you can't do a lot of other features that
> > > >are done on IP packets so you lose some functionality.
> > > >
> > > >Rodney
> > > >
> > > >
> > > >On Thu, Oct 07, 2004 at 07:35:43PM +0300, jcvaraillon at dolnet.gr wrote:
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Hi,
> > > >>
> > > >> I have a backbone of four routers:
> > > >>
> > > >> 2 Border routers connected to two differnet ISPs,
> > > >> 2 internal routers in the same LAN as the border routers.
> > > >> Each internal router is a route-reflector client of
> > > >one border router.
> > > >> There is an iBGP between the border router.
> > > >> OSPF is running amon the four routers, on that LAN.
> > > >>
> > > >> Would it be an improvment to set-up a VRF between each routers?
> > > >> Would this allow me to use the fast switching method of MPLS ?
> > > >>
> > > >> Any comment/suggestion are welcom.
> > > >>
> > > >> Thank you,
> > > >>
> > > >> Christophe
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > >> https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > >> archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >_______________________________________________
> > > >cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > >https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > >archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >
> > > >===============================================================
> > > >=========
> > > > This message has been scanned for spam & viruses by Mail Sleuth.
> > > > To report SPAM forward the message to: spam at mailsleuth.com.au
> > > > Mail Sleuth www.mailsleuth.com.au
> > > >===============================================================
> > > >=========
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >_______________________________________________
> >cisco-nsp mailing list cisco-nsp at puck.nether.net
> >https://puck.nether.net/mailman/listinfo/cisco-nsp
> >archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
--
-mb
More information about the cisco-nsp
mailing list