[c-nsp] VRF-aware management

[Church, Chuck]

Phil,

	I'm starting to feel your pain.  How about if you set the source
interface to a physical or VLAN interface, rather than a loopback?  Will
it still follow the root VRF?  I'm unable to lab it up right now.

Thanks,

Chuck 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Phil Mayers
Sent: Wednesday, January 17, 2007 8:28 PM
To: Church, Chuck
Cc: nsp
Subject: Re: [c-nsp] VRF-aware management

The 6500 SXF VRF management support is weak. The only way to get per-VRF

routing tables via SNMP for example is the MPLS-VPN mib (which happens 
to be awesomely slow). The info on CCO about using SNMP contexts to do 
that does not work on 6500s.

Similarly as you've discovered (see below) lots of control plane 
functions are not VRF aware. One you haven't mentioned is the DNS client

- that's not VRF-aware either, and packets always leave the root vrf.

For the protocols which aren't VRF-aware, setting the "source-interface"

statement to e.g. a VRF loopback seems to just make IOS emit packets 
from that IP, inside the root VRF, about the wrongest it could get it...

Sigh.


> 
> We're currently using 12.2(18)SX6 on our Sup720s.  From what the CLI
is
> telling me, specifying a VRF isn't allowed for syslog.  It is for the

Correct. No vrf syslog.

> traps like you mentioned.  The aaa group command doesn't support vrf.

Again correct. No vrf AAA.

> The ntp server command did though.  So specifying which interface
syslog
> or TACACS packets should leave won't guarantee they use that
interface,
> and hence use the VRF routing table that's associated with that

It doesn't "won't guarantee". It simply doesn't work.

> interface?  Would SNMP responses to 'gets' act the same way? 

You can SNMP query to an IP inside a VRF and the response comes out
fine.

> 
> 
>> 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.
> 
> We only intend on using SSH as a server, for remote management of this

Ditto, you can SSH to a router inside a VRF and it works fine.

> Sup720.  Not looking for client support.  We are looking for client
> functionality of SCP though.

This doesn't work and is not available. You can SCP *to* a router, which

may serve as a substitute.

> 
>> 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
> 
> It's an option, but we've tried to standardize our configurations on
> this kind of device across the board.  Putting all the customer stuff
> (involving ACLs, PBR, NAT, etc) into a VRF would be a huge
undertaking,
> and probably confuse our support staff in a really bad way.  You're
> correct, this is not an MPLS network.  We'd like to put the mgmt
> interface in a VRF to get around some duplicate addressing issues,
which
> aren't easy to fix on either the customer nor the NMS side.

We did this, but didn't have to worry about overlapping address space so

we get syslog and snmp traps from the "real" IPs. We also used a private

10.x/16, broken into /22s but with the routing kit giving proxy arp to 
the managed routers (making it look like a flat /16).

Unless you put management in the root VRF (which has its own problems) 
this is an irritating problem, no doubt.

Can you not use some kind of proxy solution from your management vrf 
into the root vrf; e.g. lots of TCP port 22/23 forwarders from 
mgt->root, a syslog-ng/dns/tftp/ssh/scp forwarder from root->mgt, etc.
_______________________________________________
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/