[c-nsp] VRF-aware management

[Phil Mayers]

Church, Chuck wrote:
> 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.

Executive summary: "ip tftp source-int" seems to cooperate with VRFs 
correctly, "ip ssh source-int" does not. I know that "ip domain-lookup 
source-int" doesn't. Physical, logical or loopback does not seem to matter.

The only 6500 I have in testing at the moment is running 12.2(33)SRA, 
not SXF (back in the days before it became clear cisco were going to 
fork the 65/7600 platform). So take this with a pinch of salt. Also 
note, that my "OOB" network is a flat /16 private lan - no routing - so 
no guarantees it works with a routed network, but I can't see how that 
would change things.

***

core-spare#sh ip vrf
   Name                             Default RD          Interfaces
   OOB                              10.2.0.0:1          Vl1

core-spare#copy start tftp
Address or name of remote host []? 10.2.1.1
Destination filename [core-spare-confg]? core-spare
.....
%Error opening tftp://10.2.1.1/core-spare (Timed out)

core-spare#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
core-spare(config)#ip tftp source-interface vl1
core-spare(config)#^Z

core-spare#copy start tftp
Address or name of remote host []? 10.2.1.1
Destination filename [core-spare-confg]? core-spare
!!
7356 bytes copied in 0.276 secs (26652 bytes/sec)

***

So "ip tftp source-interface" *DOES* work for putting traffic into a VRF 
at least under SRA, and I guess it's likely to do so under SXF.

***

core-spare#copy start scp:
Address or name of remote host []? 10.2.1.1
Destination username [admin]? admin
Destination filename [core-spare-confg]?
Writing core-spare-confg Destination unreachable; gateway or host down

%Error opening scp://nsg@10.2.1.1/core-spare-confg (Transfer aborted)

core-spare#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
core-spare(config)#ip ssh source-interface vl1
core-spare(config)#^Z

core-spare#copy start scp:
Address or name of remote host []? 10.2.1.1
Destination username [admin]? nsg
Destination filename [core-spare-confg]?
Writing core-spare-confg Destination unreachable; gateway or host down

%Error opening scp://nsg@10.2.1.1/core-spare-confg (Transfer aborted)

***

SSH/SCP client does not seem to work. I know the DNS client doesn't. 
telnet we know already has a /vrf CLI argument.

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