[c-nsp] Information on "simple" VRF

[Ray Burkholder]

I've done a bit of research into VRF-Lite for another project.  I've written
up an example at http://www.oneunified.net/blog/Cisco/index.blog which
incorporates a bunch of things I've found at a diverse sources.  Perhaps
this brings a bunch of things together in one cohesive example regarding
VRF-lite.  

I'm lead to understand that ASA's and IOS now know how to make use contexts
with VRF in order to maintain segregation of traffic types as well.

Ray.
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of nealr
> Sent: Friday, December 22, 2006 10:48
> To: Jeff Kell
> Cc: 'NSP List'
> Subject: Re: [c-nsp] Information on "simple" VRF
> 
> 
> 
>      You can partition a Cisco device such that it has one or 
> more routing tables beyond the default first instance.
> 
> ! Set up a separate VRF
> ip vrf PUBLIC
>  description public side of the switching plant ! rd has to 
> do with MPLS+BGP - pull one from your bottom if you just want 
> to partition a device  rd 1:504
> 
> 
> ! Interfaces must be associated with a VRF
> interface GigabitEthernet1/0/21
>  no switchport
>  ip vrf forwarding PUBLIC
>  ip address 209.52.52.52 255.255.255.0
> 
> ! routes are added on a per VRF basis
> ip route vrf PUBLIC 0.0.0.0 0.0.0.0 209.52.52.1
> 
> 
>        This is enough to get you started playing with it ... 
> you'll see 
> lots of use of the 'vrf' qualifier in commands you already know.
> 
> 
> 
> 
> Jeff Kell wrote:
> > I have a routing "scenario" that seems to beg VRF as a solution, but
> > being an old dinosaur with no previous need for VRF, have 
> never done the
> > specifics.  I've tried to RTFM but it seems all the 
> examples I'm pulling
> > up are convoluted bags of VPN, MPLS, and other things that are more
> > confusing than clarifying.  I would appreciate some 
> pointers, even if
> > they head off in a completely different direction :)
> >
> > We have several distinct "customers" on our network, such as:
> >
> > * dorms/ResNet - default deny-in, bandwidth shaped, 
> restricted paths to
> > the outside world,
> > * main campus - default deny-in, open paths to the outside world,
> > * server farm - dedicated firewall/IPS/etc,
> > * partnership/research entities - we're essentially an ISP 
> but want them
> > isolated from internal networks
> >
> > Currently we have a 2-3-2 network (layer 2 core, layer 3 
> distribution,
> > layer 2 access) and do policy routing at the core to 
> manipulate next-hop
> > to control their connectivity to the outside world, but it's getting
> > ugly.  The different "customers" are at best on their own 
> vlans at the
> > access layer (sharing the same access switches in some cases), but
> > routing them back to the core we need to alter their 
> default to point to
> > the proper outside path(s).  Each group has a dedicated ASA 
> "context"
> > with configurations tailored for their access requirements 
> (ASAs running
> > active/active, multiple context mode).
> >
> > It would seem that VRF would let me setup an "instance" for 
> each outside
> > path (firewall/IPS/shaping/whever grooming as appropriate) at the
> > distribution layer and allow it to pass through the core to the
> > appropriate outside path (ASA instance) without the need to 
> policy route.
> >
> > Is this a reasonable approach?
> > _______________________________________________
> > 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/
> 
> -- 
> Scanned for viruses and dangerous content at 
> http://www.oneunified.net and is believed to be clean.
> 
> 


-- 
Scanned for viruses and dangerous content at 
http://www.oneunified.net and is believed to be clean.