Mailing List Archive

Hi,

First of all, juniper documentation (and also juniper support contacts
I've asked clarifications about this) really suck.. worthless.

Feasible is a superset of active path. For example, if you have BGP
session where you receive a route advertisement and you accept it (but it
is not active, because there's some other route with better preference),
that's considered a feasible path.

In other words, feasible path strict uRPF works in most cases also with
asymmetrical routing and multihomed scenarios. This is only implemented
by Juniper AFAIK.

Loose/strict RPF is more traditional. Loose means that a route exists in
the forwarding table in general, strict that it points toward the
interface in question.

HTH.

On Thu, 18 Sep 2003, Sonny Franslay wrote:
> What are the difference in the following configs:
>
> 1. [edit routing-options forwarding-table]
> unicast-reverse-path feasible-paths;
> and
> [edit interfaces fe-0/0/0]
> unit 0 {
> family inet {
> rpf-check;
> }
> }
>
> 2. [edit routing-options forwarding-table]
> unicast-reverse-path active-paths;
> and
> [edit interfaces fe-0/0/0]
> unit 0 {
> family inet {
> rpf-check;
> }
> }
>
> 3. [edit routing-options forwarding-table]
> unicast-reverse-path feasible-paths;
> and
> [edit interfaces fe-0/0/0]
> unit 0 {
> family inet {
> rpf-check; {
> mode loose;
> }
> }
> }
>
> 4. [edit routing-options forwarding-table]
> unicast-reverse-path active-paths;
> and
> [edit interfaces fe-0/0/0]
> unit 0 {
> family inet {
> rpf-check; {
> mode loose;
> }
> }
> }
>
> Which of these is for a loose-mode rpf in a border router deployment?
>
> I've searched through the archive but cannot find the info.
>
> thanks in advance,
>
> best regards,
> sonny
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Hi Pekka,

Thanks for the reply.

> In other words, feasible path strict uRPF works in most cases also with
> asymmetrical routing and multihomed scenarios. This is only implemented
> by Juniper AFAIK.

so what is the significant of "rpf-check mode loose" on the interface when
I use feasible path?

Also what would the be the effect when I have a default route configured?

As far as I can gather from the juniper.net/techpubs is this:
"Loose mode?All packets are automatically accepted. For this reason, we
recommend that you not configure unicast RPF loose mode on interfaces that
the default route uses."

BTW, I am using junos 5.6R2.4

thanks,
sonny

On Thu, 18 Sep 2003, Sonny Franslay wrote:
> > In other words, feasible path strict uRPF works in most cases also with
> > asymmetrical routing and multihomed scenarios. This is only implemented
> > by Juniper AFAIK.
>
> so what is the significant of "rpf-check mode loose" on the interface when
> I use feasible path?

No different when you're using active paths. Remember that with loose
mode, you allow any route anyway. If you only mean to use loose mode
though, I'd recommend use active paths -- fewer things to keep track of.
The difference between feasible and active paths in this context is just a
race condition, it seems.

By the definition, feasible paths just gives you "more" than just one
active path. The list of all paths is still the same.

> Also what would the be the effect when I have a default route configured?

For (strict) routes, it depends on where the default route points to. If
it's a real default route, I think the loose mode is useless -- but this
should be confirmed or tested -- there are some implementations which
ignore default routes when doing a loose RPF lookup.

What we've been unable to get a clear answer from is whether a _static
null default route_ will yield the same behaviour as a default route
pointing to some real interface.

I think our non-tested analysis was that null default routes and loose RPF
were compatible, but I wouldn't depend on that.

> As far as I can gather from the juniper.net/techpubs is this:
> "Loose mode?All packets are automatically accepted. For this reason, we
> recommend that you not configure unicast RPF loose mode on interfaces that
> the default route uses."

Right, but this doesn't really answer the question of these typically
necessary "null default routes"..

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Butting in...

The below is snarfed from the Juniper Networks Security Solutions class:

With a Default Route
If you configure a default route that uses an interface configured with
uRPF, uRPF behaves as follows:
Strict mode: If the router finds no corresponding route in the routing
table, it accepts the packet. The router does not accept the packet
when:
The packet has a source address that matches a prefix in the routing
table; or
The interface does not expect to receive a packet with this source
address prefix.
Loose mode: The router automatically accepts all packets. For this
reason, we recommend that you not configure uRPF loose mode on
interfaces that the default route uses.


With No Default Route
Unicast RPF without a default route behaves as follows:
Loose mode: The router does not accept the packet when the packet has a
source address that does not match a prefix in the routing table.
Strict mode: The router does not accept the packet when either of the
following is true:
The packet has a source address that does not match a prefix in the
routing table; or
The interface does not expect to receive a packet with this source
address prefix.

The key is that loose accepts the packet, regardless of the incoming
interface, as long as there is a route in the routing table to that
prefix. The issue with loose in combination with a default route is that
all packets will be accepted. Core routers should not rely on a default
route, IMO, but this is the reason for the caveat.

HTHs.





> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Pekka Savola
> Sent: Thursday, September 18, 2003 4:42 AM
> To: Sonny Franslay
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] uRPF config
>
>
> On Thu, 18 Sep 2003, Sonny Franslay wrote:
> > > In other words, feasible path strict uRPF works in most
> cases also
> > > with asymmetrical routing and multihomed scenarios. This is only
> > > implemented by Juniper AFAIK.
> >
> > so what is the significant of "rpf-check mode loose" on the
> interface
> > when I use feasible path?
>
> No different when you're using active paths. Remember that
> with loose mode, you allow any route anyway. If you only
> mean to use loose mode though, I'd recommend use active paths
> -- fewer things to keep track of.
> The difference between feasible and active paths in this
> context is just a race condition, it seems.
>
> By the definition, feasible paths just gives you "more" than
> just one active path. The list of all paths is still the same.
>
> > Also what would the be the effect when I have a default route
> > configured?
>
> For (strict) routes, it depends on where the default route
> points to. If it's a real default route, I think the loose
> mode is useless -- but this should be confirmed or tested --
> there are some implementations which ignore default routes
> when doing a loose RPF lookup.
>
> What we've been unable to get a clear answer from is whether
> a _static
> null default route_ will yield the same behaviour as a default route
> pointing to some real interface.
>
> I think our non-tested analysis was that null default routes
> and loose RPF
> were compatible, but I wouldn't depend on that.
>
> > As far as I can gather from the juniper.net/techpubs is
> this: "Loose
> > mode-All packets are automatically accepted. For this reason, we
> > recommend that you not configure unicast RPF loose mode on
> interfaces
> > that the default route uses."
>
> Right, but this doesn't really answer the question of these
> typically necessary "null default routes"..
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/junipe> r-nsp
>

Is the following stanza required for uRPF?

[edit interfaces fe-0/0/0]
unit 0 {
family inet {
rpf-check;
}
}

If [edit routing-options forwarding-table]
unicast-reverse-path feasible-paths;
is 'only' configured, are you actually doing uRpF checks?

Jack

-----Original Message-----
From: Pekka Savola [mailto:pekkas@netcore.fi]
Sent: Thursday, September 18, 2003 6:42 AM
To: Sonny Franslay
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] uRPF config


On Thu, 18 Sep 2003, Sonny Franslay wrote:
> > In other words, feasible path strict uRPF works in most cases also
> > with asymmetrical routing and multihomed scenarios. This is only
> > implemented by Juniper AFAIK.
>
> so what is the significant of "rpf-check mode loose" on the interface
> when I use feasible path?

No different when you're using active paths. Remember that with loose
mode, you allow any route anyway. If you only mean to use loose mode
though, I'd recommend use active paths -- fewer things to keep track of.

The difference between feasible and active paths in this context is just
a race condition, it seems.

By the definition, feasible paths just gives you "more" than just one
active path. The list of all paths is still the same.

> Also what would the be the effect when I have a default route
> configured?

For (strict) routes, it depends on where the default route points to.
If it's a real default route, I think the loose mode is useless -- but
this should be confirmed or tested -- there are some implementations
which ignore default routes when doing a loose RPF lookup.

What we've been unable to get a clear answer from is whether a _static
null default route_ will yield the same behaviour as a default route
pointing to some real interface.

I think our non-tested analysis was that null default routes and loose
RPF
were compatible, but I wouldn't depend on that.

> As far as I can gather from the juniper.net/techpubs is this: "Loose
> mode-All packets are automatically accepted. For this reason, we
> recommend that you not configure unicast RPF loose mode on interfaces
> that the default route uses."

Right, but this doesn't really answer the question of these typically
necessary "null default routes"..

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

On Thu, 18 Sep 2003, harry wrote:
> With a Default Route
> If you configure a default route that uses an interface configured with
> uRPF, uRPF behaves as follows:

Right.. but you haven't defined what "uses an interface configured with
uRPF" means..

> Strict mode: If the router finds no corresponding route in the routing
> table, it accepts the packet. The router does not accept the packet
> when:
> The packet has a source address that matches a prefix in the routing
> table; or
> The interface does not expect to receive a packet with this source
> address prefix.
> Loose mode: The router automatically accepts all packets. For this
> reason, we recommend that you not configure uRPF loose mode on
> interfaces that the default route uses.

[...]
>
> The key is that loose accepts the packet, regardless of the incoming
> interface, as long as there is a route in the routing table to that
> prefix. The issue with loose in combination with a default route is that
> all packets will be accepted. Core routers should not rely on a default
> route, IMO, but this is the reason for the caveat.

.. that is, if you have a static discard default route in your core
routers, is your uRPF config hosed. Note that discard default routes do
not belong to any interface, so it is not clear whether your first
statement applies.


> > From: juniper-nsp-bounces@puck.nether.net
> > [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Pekka Savola
> > Sent: Thursday, September 18, 2003 4:42 AM
> > To: Sonny Franslay
> > Cc: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] uRPF config
> >
> >
> > On Thu, 18 Sep 2003, Sonny Franslay wrote:
> > > > In other words, feasible path strict uRPF works in most
> > cases also
> > > > with asymmetrical routing and multihomed scenarios. This is only
> > > > implemented by Juniper AFAIK.
> > >
> > > so what is the significant of "rpf-check mode loose" on the
> > interface
> > > when I use feasible path?
> >
> > No different when you're using active paths. Remember that
> > with loose mode, you allow any route anyway. If you only
> > mean to use loose mode though, I'd recommend use active paths
> > -- fewer things to keep track of.
> > The difference between feasible and active paths in this
> > context is just a race condition, it seems.
> >
> > By the definition, feasible paths just gives you "more" than
> > just one active path. The list of all paths is still the same.
> >
> > > Also what would the be the effect when I have a default route
> > > configured?
> >
> > For (strict) routes, it depends on where the default route
> > points to. If it's a real default route, I think the loose
> > mode is useless -- but this should be confirmed or tested --
> > there are some implementations which ignore default routes
> > when doing a loose RPF lookup.
> >
> > What we've been unable to get a clear answer from is whether
> > a _static
> > null default route_ will yield the same behaviour as a default route
> > pointing to some real interface.
> >
> > I think our non-tested analysis was that null default routes
> > and loose RPF
> > were compatible, but I wouldn't depend on that.
> >
> > > As far as I can gather from the juniper.net/techpubs is
> > this: "Loose
> > > mode-All packets are automatically accepted. For this reason, we
> > > recommend that you not configure unicast RPF loose mode on
> > interfaces
> > > that the default route uses."
> >
> > Right, but this doesn't really answer the question of these
> > typically necessary "null default routes"..
> >
> > --
> > Pekka Savola "You each name yourselves king, yet the
> > Netcore Oy kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/junipe> r-nsp
> >
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Thu, 18 Sep 2003 Jack.W.Parks@alltel.com wrote:
> Is the following stanza required for uRPF?
>
> [edit interfaces fe-0/0/0]
> unit 0 {
> family inet {
> rpf-check;
> }
> }

Yes.

> If [edit routing-options forwarding-table]
> unicast-reverse-path feasible-paths;
> is 'only' configured, are you actually doing uRpF checks?


you don't have to set routing-options-forwarding-table
unicast-reverse-path; it defaults to active-paths. If you want to change
the behaviour to cater for feasible paths also, you can set up the
additional toggle, switching on additional features in the interfaces
where you've configured rpf-check.


> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Thursday, September 18, 2003 6:42 AM
> To: Sonny Franslay
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] uRPF config
>
>
> On Thu, 18 Sep 2003, Sonny Franslay wrote:
> > > In other words, feasible path strict uRPF works in most cases also
> > > with asymmetrical routing and multihomed scenarios. This is only
> > > implemented by Juniper AFAIK.
> >
> > so what is the significant of "rpf-check mode loose" on the interface
> > when I use feasible path?
>
> No different when you're using active paths. Remember that with loose
> mode, you allow any route anyway. If you only mean to use loose mode
> though, I'd recommend use active paths -- fewer things to keep track of.
>
> The difference between feasible and active paths in this context is just
> a race condition, it seems.
>
> By the definition, feasible paths just gives you "more" than just one
> active path. The list of all paths is still the same.
>
> > Also what would the be the effect when I have a default route
> > configured?
>
> For (strict) routes, it depends on where the default route points to.
> If it's a real default route, I think the loose mode is useless -- but
> this should be confirmed or tested -- there are some implementations
> which ignore default routes when doing a loose RPF lookup.
>
> What we've been unable to get a clear answer from is whether a _static
> null default route_ will yield the same behaviour as a default route
> pointing to some real interface.
>
> I think our non-tested analysis was that null default routes and loose
> RPF
> were compatible, but I wouldn't depend on that.
>
> > As far as I can gather from the juniper.net/techpubs is this: "Loose
> > mode-All packets are automatically accepted. For this reason, we
> > recommend that you not configure unicast RPF loose mode on interfaces
> > that the default route uses."
>
> Right, but this doesn't really answer the question of these typically
> necessary "null default routes"..
>
>

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Friday, September 19, 2003, 8:27:29 AM, you wrote:
> On Thu, 18 Sep 2003, harry wrote:
>> With a Default Route
>> If you configure a default route that uses an interface configured with
>> uRPF, uRPF behaves as follows:

> Right.. but you haven't defined what "uses an interface configured with
> uRPF" means..

is it this what it not clear in our documentation ? Once you have
configured rpf-check under the interface stanza rpf is configured for this
interface and this is what it tried to say with "uses an interface
configured with uRPF" ...

[edit interfaces fe-0/0/0]
unit 0 {
family inet {
rpf-check;

>> Strict mode: If the router finds no corresponding route in the routing
>> table, it accepts the packet. The router does not accept the packet
>> when:
>> The packet has a source address that matches a prefix in the routing
>> table; or
>> The interface does not expect to receive a packet with this source
>> address prefix.
>> Loose mode: The router automatically accepts all packets. For this
>> reason, we recommend that you not configure uRPF loose mode on
>> interfaces that the default route uses.

> [...]
>>
>> The key is that loose accepts the packet, regardless of the incoming
>> interface, as long as there is a route in the routing table to that
>> prefix. The issue with loose in combination with a default route is that
>> all packets will be accepted. Core routers should not rely on a default
>> route, IMO, but this is the reason for the caveat.

> .. that is, if you have a static discard default route in your core
> routers, is your uRPF config hosed. Note that discard default routes do
> not belong to any interface, so it is not clear whether your first
> statement applies.

this is correct since it does not point to an interface it will get
discarded.

thanks
Josef


>> > From: juniper-nsp-bounces@puck.nether.net
>> > [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Pekka Savola
>> > Sent: Thursday, September 18, 2003 4:42 AM
>> > To: Sonny Franslay
>> > Cc: juniper-nsp@puck.nether.net
>> > Subject: Re: [j-nsp] uRPF config
>> >
>> >
>> > On Thu, 18 Sep 2003, Sonny Franslay wrote:
>> > > > In other words, feasible path strict uRPF works in most
>> > cases also
>> > > > with asymmetrical routing and multihomed scenarios. This is only
>> > > > implemented by Juniper AFAIK.
>> > >
>> > > so what is the significant of "rpf-check mode loose" on the
>> > interface
>> > > when I use feasible path?
>> >
>> > No different when you're using active paths. Remember that
>> > with loose mode, you allow any route anyway. If you only
>> > mean to use loose mode though, I'd recommend use active paths
>> > -- fewer things to keep track of.
>> > The difference between feasible and active paths in this
>> > context is just a race condition, it seems.
>> >
>> > By the definition, feasible paths just gives you "more" than
>> > just one active path. The list of all paths is still the same.
>> >
>> > > Also what would the be the effect when I have a default route
>> > > configured?
>> >
>> > For (strict) routes, it depends on where the default route
>> > points to. If it's a real default route, I think the loose
>> > mode is useless -- but this should be confirmed or tested --
>> > there are some implementations which ignore default routes
>> > when doing a loose RPF lookup.
>> >
>> > What we've been unable to get a clear answer from is whether
>> > a _static
>> > null default route_ will yield the same behaviour as a default route
>> > pointing to some real interface.
>> >
>> > I think our non-tested analysis was that null default routes
>> > and loose RPF
>> > were compatible, but I wouldn't depend on that.
>> >
>> > > As far as I can gather from the juniper.net/techpubs is
>> > this: "Loose
>> > > mode-All packets are automatically accepted. For this reason, we
>> > > recommend that you not configure unicast RPF loose mode on
>> > interfaces
>> > > that the default route uses."
>> >
>> > Right, but this doesn't really answer the question of these
>> > typically necessary "null default routes"..
>> >
>> > --
>> > Pekka Savola "You each name yourselves king, yet the
>> > Netcore Oy kingdom bleeds."
>> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>> >
>> > _______________________________________________
>> > juniper-nsp mailing list juniper-nsp@puck.nether.net
>> > http://puck.nether.net/mailman/listinfo/junipe> r-nsp
>> >
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>