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:st...@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-boun...@puck.nether.net >>>>> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Stacy W. >>>>> Smith >>>>> Sent: Saturday, February 04, 2012 11:28 PM >>>>> To: Amos Rosenboim >>>>> Cc: juniper-nsp@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@puck.nether.net >>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>> >>>>> >>>>> _______________________________________________ >>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>> >>>> >>>> _______________________________________________ >>>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >> > > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp