Viptela vpn 512

[cisco8887]

hi 

how do you configure a cedge where there is no oob?

can you configure vpn 512 on say subnet 10.0.0.0/24 with ip of .1 and configure same subnet in vpn 10( service vpn) and have ip of .254 there so in essence loop management through vpn 10?

can you do away without 512 all together?

thanks

[Torbjørn]

You can access a VPN 512 interface by making it routable through a service VPN. You can also enable the required services(SSH, NETCONF etc.) on tunnel-interfaces to manage your device. The console port is also available for performing manual bootstrapping regardless of VPN 512.

You should assess your specific situation to figure out what makes the most sense.

I don't believe you can remove VPN 512 on cEdges, but you can "shut" the Gi0 interface if you don't with to use it.

[cisco8887]

You can configure another interface as vpn 512 for instace ge 0/3 

what I am trying to figure is how the config would look like if von 512 is routed via service vpn.  Would you have same subnet in both and loop a physical cable or run through a switch which can trunk it up to the cedge?

[MHM Cisco World]

it direct connect not pass via service VPN. 
MHM

[MHM Cisco World]

there service VPN is range from 1 to 511 and from 513 to 65530 
so you can not use 512 for the service VPN
the VPN 512 connect to OOB (private network from there you can access to cedge/vedge)
MHM

[MHM Cisco World]

if you have VPN 0 you can access via it 
or 
using VPN 512 
so no need to access VPN 512 via service or transport VPN, you can directly access the cedge via VPN 0
MHM

[Kanan Huseynli]

Hi,

yes, you can take that approach. Interface in VPN512 with IP and gateway, but gateway is VPN10 interface. Of course, you need intermediate device to "loop" that traffic. VPN512 interface (=its IP) will be just regular host in VPN10 VPN where that subnet can be advertised via VPN10 service VPN for remote reachibility.

In one of the production I use this method:

                                        Core_Switch--(VPN1_service_vpn_interface)Branch Router(VPN0_transport interface)--SDWAN Overlay
(VPN512gateway_no VRF on core side)||____________________________||(VPN512interface)

Sorry for RFC style diagram

[Torbjørn]

This is the way to do it. AFAIK there is no reasonable way to achieve this within the cEdge itself.

[Kanan Huseynli]

What do you mean by "there is no reasonable way to achieve this "?

Basically, if there is management subnet in branch (without management switch) and this is only allowed option via firewall/ remote-access VPN to connect devices remotely, then you need to put cEdge in this subnet using Mgmt-intf VRF (VPN512).

Otherwise, you should allow transit network for remote reachibility

[Torbjørn]

My mistake @Kanan Huseynli, I worded my comment poorly.

What I meant is that you should "loop" the traffic through a neighboring box as you described. There is no good way to achieve reachability to the VPN512 interface from a service VPN using only the cEdge, as there is no way to leak routes between VPN512 and service VPNs.

On another note: Congrats on achieving VIP!

[Kanan Huseynli]

Yes, I understand and totally agree in this case.

This configuration - model is not true "OOB" connectivity in branch locations, you can just use to fulfill generic design requirement (having mgmt subnet/vlan and access devices through it). Even without this you can use vmanage to do SSH to device through overlay using SSH tool.

In this setup, if something happens and overlay is down, you will still have problem to access to the device. Better to have LTE based additional transport if model allows to have LTE module and branch site is critical.

Thank you for congratulations! Wish you too in next year!

[dijix1990]

In my environment I just use Loopback512 as mngt with system IP address (it's only for devices without OOB). My mngt for these devices placed in  especial service vpn

Sdwan-system-intf      10.80.253.102   YES unset  up                    up
vmanage_system         unassigned      YES unset  up                    up
Loopback512            10.80.253.102   YES other  up                    up
Loopback65528          192.168.1.1     YES other  up                    up
Loopback65529          11.1.253.102    YES other  up                    up


Current configuration : 166 bytes

interface Loopback512
 description -MNGT- ### management sdwan
 vrf forwarding Mgmt-intf
 ip address 10.80.253.102 255.255.255.0
 no ip redirects
 ip mtu 1500
end