[j-nsp] IPv6

Kevin Oberman oberman at es.net
Sun Jan 24 23:14:22 EST 2010


> Date: Sun, 24 Jan 2010 21:26:43 -0600
> From: Richard A Steenbergen <ras at e-gerbil.net>
> 
> On Sun, Jan 24, 2010 at 04:56:47PM -0800, Kevin Oberman wrote:
> > We just define our own policy to fake nexthop self:
> > policy-statement set-nexthop-self {
> >     term IPv4 {
> >         from family inet;
> >         then {
> >             next-hop self;
> >         }
> >     }
> >     term IPv6 {
> >         from family inet6;
> >         then {
> >             next-hop (IPv6 loopback address);
> >         }
> >     }
> > }
> > 
> > We've had no problems with doing this in our iBGP mesh which is
> > dual-stack over IPv4.
> 
> That works too, except now you have a hardcoded loopback v6 address
> which is unique per router stuck in a policy-statement somewhere, just
> begging to be forgotten about some day. It's a commit scriptable fix,
> but for every great "well that solved my problem without having to wait
> for Juniper to fix it properly" moment there is a "man I just slowed
> down my commit by another second each and every time I make a change,
> all for a feature that that really should have been there in the first
> place" moment. The proper fix would be either a "next-hop interface
> lo0.0" option in the policy-statement, and/or a "neighbor x.x.x.x
> update-source lo0.0" command to set what "self" means for a particular
> neighbor (which is the way Cisco does it).

Sure I would prefer if Juniper did it 'right' (not often I have to say
that about Juniper) but the way we do it works our configuration
generator does it right and the configuration checking scripts that run
right after RANCiD saves our configs will let us know if someone still
manages to mess it up.

Yes, it's a hack and a commit script could do it, but we are really
enjoying the fast commits on MX boxes and we really prefer to avoid
commit scripts, too. The use of the configuration generator and the
configuration testing do most of what we would use commit scripts for.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


More information about the juniper-nsp mailing list