[j-nsp] next hop behavior within between VRFs
Stacy W. Smith
stacy at acm.org
Tue Feb 14 16:27:17 EST 2012
Hi Ido,
Thanks to Harry Reynolds, I also figured out how to accomplish what you wanted even for traffic entering from a remote PE.
The trick is to apply the filter-based forwarding policy to the vrf-a forwarding table rather than to a specific interface.
This requires to firewall filters with the exact same content (fbf and fbf2 in my example). That's because the same firewall filter can not be applied to a forwarding table and an interface.
The links below have been updated with the new configs.
--Stacy
On Feb 14, 2012, at 2:09 PM, Stacy W. Smith wrote:
> Hi Ido,
>
> I have a setup that accomplishes most of what you were asking. Take a look at my topology and configs.
>
> Topology:
> http://dl.dropbox.com/u/13293084/j-nsp_topology/Topology.png
>
> pe1 config
> http://dl.dropbox.com/u/13293084/j-nsp_topology/pe1-config.txt
>
> pe2 config
> http://dl.dropbox.com/u/13293084/j-nsp_topology/pe2-config.txt
>
> In my topology, server, ce-a1, r1, ce-a2, and r2 are all virtual routers on pe2. (That's just because I only had two physical routers to set this up). ce-a1 in my topology would be equivalent to your BRAS device.
>
> In my topology, I use lt interfaces between vrf-b and inet.0, and I run a iBGP session across those lt interfaces from vrf-b to inet.0. The inet.0 side is configured as a route-reflector for the session to vrf-b. There are no lt interfaces between vrf-a and vrf-b. I use filter-based forwarding to force the traffic to the proxy server. My topology and configuration allows me to force the traffic from ce-a1 to the Internet through the proxy server, and also allows me to force the traffic from the Internet to ce-a1 back though the proxy server.
>
> The good news is this doesn't require any changes to the ce-a1 (BRAS) config. There's a single iBGP session from ce-a1 to vrf-a in pe1.
>
> The only thing that doesn't work in my topology is forcing traffic from ce-a2 to the Internet through the proxy server. The problem is that there's no interface on pe1 on which to apply filter-based forwarding for the traffic that comes in from a remote PE and is destined for the Internet. The return traffic from the Internet to ce-a2, however, does pass through the proxy server as desired.
>
> FYI, I used the following match conditions in my filter-based forwarding firewall filter:
>
> from {
> address {
> 172.16.255.1/32;
> 172.16.255.2/32;
> }
> }
>
> This allowed me to test with traceoute and sourcing the different traffic from different IPs.
>
> In your setup, you would probably want something like this instead:
>
> from {
> protocol tcp;
> port [ http https];
> }
>
> I hope this helps. Let me know if you have any questions about my setup.
>
> --Stacy
>
>
> On Feb 13, 2012, at 1:25 PM, Ido Szargel wrote:
>> On Feb 9, 2012, at 12:07 AM, Ido Szargel wrote:
>>
>>> Hi Stacy,
>>>
>>> Almost all the traffic must go through the servers, those are web
>>> filtering proxies and the base requirement of our customer, as this is
>>> the service they are selling.
>>> I'm using FBF as I do not want to maintain static routes to determine
>>> that IP x should go through the servers or not but I want this to be
>>> dynamic and updated via BGP from VRF A (which is where the LNS routers
>>> are) Once the traffic has entered into VRF B then I can use FBF to
>>> throw all traffic to the servers , they will do their magic and return
>>> it back to the MX which will forward it according to its routing table.
>>> Traffic in both direction should pass through the servers.
>>> Currently there is only one site, and only one VRF to catch but there
>>> might be more VRFs soon.
>>>
>>> Thanks,
>>> Ido
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Stacy W. Smith [mailto:stacy at acm.org]
>>> Sent: Thursday, February 09, 2012 7:42 AM
>>> To: Ido Szargel
>>> Subject: Re: [j-nsp] next hop behavior within between VRFs
>>>
>>> Even more questions...
>>>
>>> Are their remote sites that are members of the same VPN as VRF A?
>>>
>>> If so, is there a set of servers (VRF B) in each site, or a single "hub"
>>> site?
>>>
>>> If so, is there Internet access in each site, or a single "hub" site?
>>>
>>> --Stacy
>>>
>>> On Feb 8, 2012, at 7:16 PM, Stacy W. Smith wrote:
>>>
>>>> Ido,
>>>>
>>>> Sorry for the delay in getting back to this.
>>>>
>>>> I think I understand what you're trying to accomplish, but just a
>>>> couple more questions.
>>>>
>>>> I'm assuming this traffic has a source IP in vrf A and a destination
>>>> IP in
>>> inet.0, and that's why you're using FBF to detour the traffic through
>>> the servers in vrf B. Is that correct?
>>>>
>>>> Is there anything in vrf B besides the servers that need to "catch
>>>> the
>>> traffic"?
>>>>
>>>> Are the servers in vrf B being used to "catch traffic" for any other
>>>> vrfs,
>>> or only vrf A?
>>>>
>>>> Does traffic from inet.0 also need to pass through the servers in vrf
>>>> B on
>>> it's way to vrf A or is it only the traffic in the other direction
>>> vrfA->vrfB servers->inet.0 that passes through the servers?
>>>>
>>>> Thanks,
>>>> --Stacy
>>>>
>>>>
>>>> On Feb 5, 2012, at 3:16 AM, Ido Szargel wrote:
>>>>
>>>>> Hi Stacy,
>>>>>
>>>>> Our topology is
>>>>>
>>>>> LNS --- MX vrf A --- logical tunnel --- MX vrf B --- logical tunnel
>>>>> --- MX
>>>>> inet.0
>>>>>
>>>>> What we're trying to accomplish is pretty simple, due to special
>>>>> needs of our customer most traffic should be forwarded to servers in
>>>>> vrf B, In order to do that we advertise a default route from inet.0
>>>>> into vrf B and from vrf B into vrf A, we also advertise the
>>>>> customers routes the other way around (from vrf A to vrf B and from
>>>>> vrf B to
>>>>> inet.0) Then we need to catch the traffic as it enters vrf B to
>>>>> redirect it to the servers, this is what the lt is for.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Ido
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: juniper-nsp-bounces at puck.nether.net
>>>>> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Stacy W.
>>>>> Smith
>>>>> Sent: Saturday, February 04, 2012 11:28 PM
>>>>> To: Amos Rosenboim
>>>>> Cc: juniper-nsp at puck.nether.net
>>>>> Subject: Re: [j-nsp] next hop behavior within between VRFs
>>>>>
>>>>> Hi Amos,
>>>>>
>>>>> I'm not sure I completely understand what you're trying to
>>>>> accomplish. Could you give us an example topology diagram?
>>>>>
>>>>> Thanks,
>>>>> --Stacy
>>>>>
>>>>> On Feb 4, 2012, at 1:20 PM, Amos Rosenboim wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I have a router with two VRFs.
>>>>>> I need to apply FBF on traffic flowing between the two VRFs so I
>>>>>> created a
>>>>> logical tunnel that connects the two VRFs.
>>>>>> The problem is that when importing routes from one VRF to the other
>>>>>> the
>>>>> next hop is obviously not through the tunnel.
>>>>>> I am trying to apply an import map that will change the next-hop of
>>>>> imported routes to the tunnel interface, but it doesn't work
>>>>> (traffic still bypasses the tunnel).
>>>>>>
>>>>>> I can obviously skip the VRF import method and simply run BGP over
>>>>>> the
>>>>> tunnels but I would like to avoid this as it forces me to use route
>>>>> refection (the routes I need to announce are learnt via iBGP) and so on.
>>>>>> Any ideas how to achieve the goal of sharing routes between the
>>>>>> VRFs but
>>>>> controlling the next hop in each VRF differently ?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Amos
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
More information about the juniper-nsp
mailing list