[c-nsp] VRF-aware management

[Phil Mayers]

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.