[c-nsp] VRF-aware management

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Wed Jan 17 13:12:40 EST 2007


cisco-nsp-bounces at puck.nether.net <> wrote on Wednesday, January 17,
2007 4:37 PM:


> 	We're seeing a need to use a VRF on 6500s with Sup720 for
> management purposes, as we've got some IP conflicts between our
> management network and some customer networks.  All customer networks
> will reside in the global routing table, but our management
> functions - syslog, SNMPv3, SSH, and copying via SCP we'd like to put
in
> a VRF, with a single static VRF route covering the routing.  My
question is if
> simply configuring the 'source-interface' for 'logging',
> 'snmp-server', and 'ip ssh' is enough, since the source interface I
> was going to use is in the necessary VRF? 

Well, just putting the source-interface into the vrf and referencing
this in the application at hand only works for tftp, for snmp, syslog
and tacacs you have to configure the vrf in the application itself, i.e.

logging x.x.x.x vrf mgmt
snmp-server host x.x.x.x vrf mgmt community
aaa group server tacacs+ MGMT
 vrf mgmt
ntp server vrf mgmt x.x.x.x

> The copying via SCP puzzles me.  I
> didn't see any keywords in there for naming a VRF during a copy
command.  TFTP allows
> you to name a source interface.  Is there a trick to doing that?  Or
> does the SSH configured source-interface cover the SCP
> copying as well?

I don't think we have vrf-awareness for ssh/scp client.. Unless the CLI
has a /vrf keywoard or similar (i.e. like telnet), I fear you're out of
luck.

I guess doing the opposite (i.e. putting all customers into a vrf and
just keeping the global table for management and control plane) is not a
feasible option? :-} Or is this not an MPLS network and you're doing OOB
management by putting some OOB mgmt interface into the vrf?

	oli



More information about the cisco-nsp mailing list