[j-nsp] M-series IPSEC / SP interface and VRF

[Alex Arseniev]

And what happens if You ping a destination IP known via BGP across the 
tunnel but with different src.ip?

ping routing-instance VRFname <dst.ip> source <whatever>

This src.ip must be known by/reachable from far end.
HTH
Thanks
Alex

On 17/12/2013 20:40, Scott Harvanek wrote:
> BGP is running in the tunnel and the next hop is the far side of the 
> tunnel, everything looks correct. All the routes show the far end of 
> the tunnel and BGP is established inside the VRF but traffic will not 
> pass except of traffic directly between the two endpoints. E.g. 
> BGP/ICMP on the tunnel subnet.  I'm at a loss.
>
> I'll pull some info and post it back, maybe someone sees something I 
> don't.
>
> Scott H.
>
> On 12/17/13, 12:27 PM, Alex Arseniev wrote:
>> For the traffic to be encrypted, the BGP nexthop has to point into 
>> the tunnel which means one of the below:
>> 1/ BGP has to run inside the tunnel, or
>> 2/ You have to have a BGP import policy to change the nexthop to 
>> tunnel's remote address. If this is eBGP, then also add 
>> "accept-remote-nexthop" knob.
>> HTH
>> Thanks
>> Alex
>>
>> On 17/12/2013 16:08, Scott Harvanek wrote:
>>> So this works to establish the tunnels, the problem is, BGP received 
>>> routes over the tunnel do not function correctly.  The routes are 
>>> properly installed in the VRF but traffic to those destinations does 
>>> not pass correctly. Does anyone have any experience running BGP like 
>>> this on the m-series or does it just not work on next-hop-style?
>>>
>>> Thanks,
>>> -SH
>>>
>>> On 11/12/13, 1:34 PM, Scott Harvanek wrote:
>>>> Yep excellent, I'll give it a whirl, thanks!
>>>>
>>>> Scott H.
>>>>
>>>> On 11/12/13, 1:24 PM, Alex Arseniev wrote:
>>>>> So, if I understand Your requirement, You want sp-0/0/0.<unit> in 
>>>>> VRF, correct?
>>>>> And outgoing GE interface in inet.0?
>>>>> And where the decrypted packets should be placed, inet.0 or VRF?
>>>>> And where from the to-be-ecrypted packets should arrive, from 
>>>>> inet.0 or VRF?
>>>>> If the answer is "correct/inet.0/VRF/VRF" then migrate to 
>>>>> next-hop-style IPSec and place inside sp-* unit into the VRF 
>>>>> leaving outside sp-* unit in inet.0.
>>>>> HTH
>>>>> Thanks
>>>>> Alex
>>>>>
>>>>> On 12/11/2013 16:35, Scott Harvanek wrote:
>>>>>> Alex,
>>>>>>
>>>>>> Yea, tried this but it looks like you can't set it to the default 
>>>>>> inet.0 instance, only to things different... the local gw in my 
>>>>>> case is in the default instance and I want the service interface 
>>>>>> in another so unless I'm mistaken it's in default by default and 
>>>>>> this fails?
>>>>>>
>>>>>> Scott H.
>>>>>>
>>>>>> On 11/12/13, 11:22 AM, Alex Arseniev wrote:
>>>>>>> Yes
>>>>>>>
>>>>>>> [edit]
>>>>>>> aarseniev at m120# set services service-set SS1 ipsec-vpn-options 
>>>>>>> local-gateway ?
>>>>>>> Possible completions:
>>>>>>>   <address>            Local gateway address
>>>>>>>   routing-instance     Name of routing instance that hosts local 
>>>>>>> gateway <=====!!!! CHECK THIS OUT!!!
>>>>>>> aarseniev at m120> show version
>>>>>>> Hostname: m120
>>>>>>> Model: m120
>>>>>>> JUNOS Base OS boot [10.4S7.1]
>>>>>>>
>>>>>>> HTH
>>>>>>> Thanks
>>>>>>> Alex
>>>>>>>
>>>>>>> On 12/11/2013 16:05, Scott Harvanek wrote:
>>>>>>>> Anyone with any ideas on this?
>>>>>>>>
>>>>>>>> Scott H.
>>>>>>>>
>>>>>>>> On 11/9/13, 12:58 PM, Scott Harvanek wrote:
>>>>>>>>> Is there a way to build a IPSec tunnel / service interface 
>>>>>>>>> where the local gateway is NOT in the same routing-instance as 
>>>>>>>>> the service interface?
>>>>>>>>>
>>>>>>>>> Here's what I'm trying to do;
>>>>>>>>>
>>>>>>>>> [ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ]
>>>>>>>>> [ st0.0 / VRF ] ================= [ sp-0/0/0.0 / VRF ]
>>>>>>>>>
>>>>>>>>> The problem is, I want sp-0/0/0.0 on router B in a VRF but NOT 
>>>>>>>>> the outside interface on router B, I cannot commit unless the 
>>>>>>>>> outside/local-gateway on the IPSec tunnel is in the same 
>>>>>>>>> routing-instance as the service interface, is there a way 
>>>>>>>>> around this? The SRX devices can do this without issue.
>>>>>>>>>
>>>>>>>>> service-set XXXX {
>>>>>>>>>     interface-service {
>>>>>>>>>         service-interface sp-0/0/0.0; <-- want this in a VRF
>>>>>>>>>     }
>>>>>>>>>     ipsec-vpn-options {
>>>>>>>>>         local-gateway x.x.x.x; <-- default routing instance
>>>>>>>>>     }
>>>>>>>>>     ipsec-vpn-rules XXXX
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>>>
>>>>>> _______________________________________________
>>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>>
>>>>> _______________________________________________
>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>