from mt wiki regarding VRF, not sure why i cant make it to work: eoip,ipip,l2tp,gre,ovpn,sstp and l2tp-ether
e.g.
i have vrf1 existing
/interface ipip
add remote-address=192.168.1.1@vrf1
the error that im geting is not a valid dns name (6)
ipip support did not make into 7.6 release. The OVPN client, which you initially asked for, works.
@mrx
i can confirm that on sstp it does work well, please see the picture below.
since i got @vrf assigned on the sstp-client interface, i’m assuming that i can ping from that vrf, which is not the case.
may i get more detiles ?
It does not show the whole picture, is the added sstp client part of the vrf too? If not then it is the expected behavior because sstp interface is in the main table.
yes,if i’ll added in to the VRF table than i can ping , and i don’t need to specificate @vrf1,
but what is point of connect to=x.x.y.y@vrf-vl200@vrf? ?
The point is to get the ability to establish the connection from the vrf.
but wait, im able to do that if the interface is in the VRF and ping out from that VRF(route leaking)
connect to=x.x.y.y@vrf-vl200@vrf doesn’t need to be, correct me if im wrong
There are two things:
- SSTP session that sends/receives control packets and encapsulated packets
- Trafic that should be encapsulated
And each can be in its own VRF.
- By specifying connect-to ip@vrf you are telling SSTP to establish session from the specifed VRF
- by adding SSTP interface in the VRF you are telling to encapsulate/decapsulate traffic from/to selected vrf