[c-nsp] Information on "simple" VRF

[nealr]

     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/
>
>