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

[Scott Harvanek]

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
>