[j-nsp] My strained affection for fxp0

[Clarke Morledge]

I know we had a thread on this a month ago:

http://www.mail-archive.com/juniper-nsp@puck.nether.net/msg09804.html

but I wanted to explore an idea on how to  handle the troubles behind 
managing fxp0.   I was able to determine that even though fxp0 is supposed 
to only handle out-of-band traffic to/from the RE, it will in fact forward 
transit traffic through fxp0 if a particular route exists both on the fxp0 
side of the world and everywhere else, as in the following example:

192.168.1.0/24     *[Static/5] 3d 03:27:05
                     > to 192.168.0.1 via fxp0.0
                     [Static/6] 3d 03:55:58
                     > to 192.168.2.5 via xe-10/0/0.0


Add my name to the list for wanting the ability to put fxp0 in a separate 
VR!!   In the meantime....

My solution to the problem was just not to use the same route on both the 
in-band and out-of-band sides, and simply do a NAT trick on a different 
router on the out-of-band side of the network.  It works, but it just 
seems unnecessarily complex and ugly to me.

I was wondering if there was any way to do some sort of policy-based 
routing such that any packet generated from the RE towards a particular 
route could get forwarded out a different interface than what is in the 
routing table.  For example, your route normally lives in the in-band 
world, but a packet to that route from RE would go out of fxp0. 
Unfortunately, I haven't figured out a way that this can be done within 
the Junos architecture (at least on the MX platform).

Has anyone been able to come up with such a PBR-type solution?

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187