Possible approach for small.net - ok, you know that big.net will drop
any packets sourced from x.x.x.x if there's no route there (loose uRPF
for downstream ISPs like small.net, strict uRPF for end-users.) So
give them a route. Either give them a route on one of your direct
interfaces to them,
On Tue, Sep 26, 2006 at 12:17:27AM -0700, Tony Rall wrote:
On Monday, 2006-09-25 at 10:09 MST, Mark Kent [EMAIL PROTECTED]
wrote:
Mark Smith replied with two paragraphs, but it's not 100% clear to me
that he got the reason why I asked. I asked because his initial
statement
boiled
On Monday, 2006-09-25 at 10:09 MST, Mark Kent [EMAIL PROTECTED]
wrote:
Mark Smith replied with two paragraphs, but it's not 100% clear to me
that he got the reason why I asked. I asked because his initial
statement
boiled down to numbering on un-announced space breaks PMTUD...
but it
At 10:06 25/09/2006, Ian Mason wrote:
One of the largest North American network providers filters/drops
ICMP messages so that they only pass those with a source IP
address that appears in their routing table.
This is clearly reasonable as part of an effort to mitigate ICMP
based network
I asked:
Who among AS1239, AS701, AS3356, AS7018, AS209 does loose RPF
(not just strict RPF on single-homed customers)?
and Patrick answered:
I'm wondering why that is relevant.
It's relevant because it was suggested that loose RPF should be a
best common practice so I was curious which of
On Sep 26, 2006, at 11:57 AM, Mark Kent wrote:
I asked:
Who among AS1239, AS701, AS3356, AS7018, AS209 does loose RPF
(not just strict RPF on single-homed customers)?
and Patrick answered:
I'm wondering why that is relevant.
It's relevant because it was suggested that loose RPF should be
On Tue, Sep 26, 2006 at 01:41:52PM -0400, Patrick W. Gilmore wrote:
For instance, how many networks are in full compliance with BCP38?
I've been working towards this on our network for some time
but have been hindered by vendor.. uhm, features^Wbugs. eg:
halving the TCAM with rpf
Hi Mark,
On Sun, 24 Sep 2006 16:33:30 -0700 (PDT)
Mark Kent [EMAIL PROTECTED] wrote:
Mark Smith wrote:
The non-announcers, because they're also breaking PMTUD.
Really? How? Remember, we're not talking about RFC1918 space,
where there is a BCP that says we should filter it at the
The non-announcers, because they're also breaking PMTUD.
If you're not sure what benefits PMTUD gives,
you might want to review this page:
http://www.psc.edu/~mathis/MTU/index.html
--Michael Dillon
[ Quotations have been reordered for clarity in the reply ]
On 24 Sep 2006, at 22:59, Mark Kent wrote:
If so, which of these two nets is unreasonable in their actions/
policies?
I don't think either are *unreasonable* in what they've done. Both
actions are prima facie reasonable but
On Mon, Sep 25, 2006, Ian Mason wrote:
Filtering ICMP is always dangerous. If you are going to do it you
*must* understand the consequences both to yourself and to others,
and also understand the consequences in both normal situations and
all possible failure modes. (If I had a penny
On Sun, Sep 24, 2006 at 02:59:50PM -0700, Mark Kent wrote:
A smaller North American network provider, with a modest North
American backbone, numbers their internal routers on public IP space
that they do not announce to the world.
One of the largest North American network providers
On Sep 25, 2006, at 9:06 AM, Ian Mason wrote:
ICMP packets will, by design, originate from the incoming interface
used by the packet that triggers the ICMP packet. Thus giving an
interface an address is implicitly giving that interface the
ability to source packets with that address to
Patrick W. Gilmore wrote:
On Sep 25, 2006, at 9:06 AM, Ian Mason wrote:
ICMP packets will, by design, originate from the incoming interface
used by the packet that triggers the ICMP packet. Thus giving an
interface an address is implicitly giving that interface the ability
to source
Jared Mauch wrote:
I would hope they're doing it for more than just ICMP packets.
yes, loose RPF, but I just care about ICMP.
I would argue should be, or is a current best practice.
OK, so I must have missed the memo :-)
Who among AS1239, AS701, AS3356, AS7018, AS209 does loose RPF
(not
In response to this:
Mark Smith wrote:
The non-announcers, because they're also breaking PMTUD.
Really? How?
Mark Smith replied with two paragraphs, but it's not 100% clear to me
that he got the reason why I asked. I asked because his initial statement
boiled down to numbering on
Once upon a time, Mark Kent [EMAIL PROTECTED] said:
I think this is an important point to make because of my interaction
with small.net. When I pointed out the timeouts they said that it was
because they don't announce the router IP addresses, which is true but
not the whole story. I
On Mon, 25 Sep 2006, Chris Adams wrote:
Once upon a time, Mark Kent [EMAIL PROTECTED] said:
I think this is an important point to make because of my interaction
with small.net. When I pointed out the timeouts they said that it was
because they don't announce the router IP addresses, which
On Sep 25, 2006, at 12:22 PM, Mark Kent wrote:
Jared Mauch wrote:
I would hope they're doing it for more than just ICMP packets.
yes, loose RPF, but I just care about ICMP.
I would argue should be, or is a current best practice.
OK, so I must have missed the memo :-)
It's been all the
On Mon, 25 Sep 2006 09:22:34 -0400
Patrick W. Gilmore [EMAIL PROTECTED] wrote:
On Sep 25, 2006, at 9:06 AM, Ian Mason wrote:
ICMP packets will, by design, originate from the incoming interface
used by the packet that triggers the ICMP packet. Thus giving an
interface an address is
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Patrick W. Gilmore
Sent: Monday, September 25, 2006 9:23 AM
To: nanog@merit.edu
Cc: Patrick W. Gilmore
Subject: New router feature - icmp error source-interface [was: icmp
rpf]
On Sep 25, 2006, at 9:06 AM, Ian Mason wrote:
ICMP packets
Subject: New router feature - icmp error source-interface [was: icmp
rpf]
On Sep 25, 2006, at 9:06 AM, Ian Mason wrote:
ICMP packets will, by design, originate from the incoming interface
used by the packet that triggers the ICMP packet. Thus giving an
interface an address is implicitly giving
On Mon, Sep 25, 2006 at 09:22:34AM -0400, Patrick W. Gilmore wrote:
On Sep 25, 2006, at 9:06 AM, Ian Mason wrote:
ICMP packets will, by design, originate from the incoming interface
used by the packet that triggers the ICMP packet. Thus giving an
interface an address is implicitly
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Patrick W. Gilmore
Sent: Monday, September 25, 2006 5:31 PM
To: nanog@merit.edu
Cc: Patrick W. Gilmore
Subject: Re: New router feature - icmp error source-interface
[was: icmp rpf]
On Sep
On Sep 25, 2006, at 5:40 PM, Richard A Steenbergen wrote:
On Mon, Sep 25, 2006 at 09:22:34AM -0400, Patrick W. Gilmore wrote:
On Sep 25, 2006, at 9:06 AM, Ian Mason wrote:
ICMP packets will, by design, originate from the incoming interface
used by the packet that triggers the ICMP packet.
On Mon, Sep 25, 2006 at 04:33:18PM -0700, David Temkin wrote:
C and J both already have a similar feature, however I'm not sure
whether or not they apply to ICMP. They both support PBR for locally
originated packets - which, should include if the thought process is
correct, ICMP. Perhaps
At 9:22 AM -0400 9/25/06, Patrick W. Gilmore wrote:
Who thinks it would be a good idea to have a knob such that ICMP error
messages are always source from a certain IP address on a router?
It certainly would beat the alternative of no response at all,
but one would hope it wouldn't become
On Mon, Sep 25, 2006 at 08:45:49PM -0400, John Curran wrote:
At 9:22 AM -0400 9/25/06, Patrick W. Gilmore wrote:
Who thinks it would be a good idea to have a knob such that ICMP error
messages are always source from a certain IP address on a router?
It certainly would beat the
On Mon, Sep 25, 2006 at 09:22:34AM -0400, Patrick W. Gilmore wrote:
...
Who thinks it would be a good idea to have a knob such that ICMP
error messages are always source from a certain IP address on a router?
...
I've sometimes thought it would be useful when I wanted to hide a route.
But
On Mon, 25 Sep 2006, Joseph S D Yao wrote:
On Mon, Sep 25, 2006 at 09:22:34AM -0400, Patrick W. Gilmore wrote:
...
Who thinks it would be a good idea to have a knob such that ICMP
error messages are always source from a certain IP address on a router?
...
I've sometimes thought it
Chris,
So, I'm wondering: What happens when you have a traceroute tool
that shows you MPLS-lableled hops, too? :-)
http://momo.lcs.mit.edu/traceroute/index.php
The best (?) of both worls, but I digress...
- ferg
-- Chris L. Morrow [EMAIL PROTECTED] wrote:
[snip]
What's interesting is
On Tue, 26 Sep 2006, Fergie wrote:
Chris,
So, I'm wondering: What happens when you have a traceroute tool
that shows you MPLS-lableled hops, too? :-)
:) depends on the network I guess... I'm not sure it's going to tell you
anything about hops hidden by mpls lsp's that don't decrement ttl
Ah, but there's the rub...
ISPs who are discreet in how they wish their infrastructure to
be viewed will continue to engineer methods in which portions
are not visible to the public at-large.
Somehow, I don't think that will ever go away, so trying to tilt
at windmils w.r.t. (paraphrased)
At 10:29 PM 9/25/2006, Chris L. Morrow wrote:
On Mon, 25 Sep 2006, Joseph S D Yao wrote:
On Mon, Sep 25, 2006 at 09:22:34AM -0400, Patrick W. Gilmore wrote:
...
Who thinks it would be a good idea to have a knob such that ICMP
error messages are always source from a certain IP address
On Tue, Sep 26, 2006 at 02:51:21AM +, Fergie wrote:
So, I'm wondering: What happens when you have a traceroute tool
that shows you MPLS-lableled hops, too? :-)
http://momo.lcs.mit.edu/traceroute/index.php
The best (?) of both worls, but I digress...
That doesn't show any more or
Joseph S D Yao wrote:
On Mon, Sep 25, 2006 at 09:22:34AM -0400, Patrick W. Gilmore wrote:
...
Who thinks it would be a good idea to have a knob such that ICMP
error messages are always source from a certain IP address on a router?
...
I've sometimes thought it would be useful when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Kent wrote:
A smaller North American network provider, with a modest North
American backbone, numbers their internal routers on public IP space
that they do not announce to the world.
One of the largest North American network providers
virendra rode wrote:
This is yet another reason one shouldn't rely on pings traceroutes to
perform reachability analysis.
So, you're in the traceroute is not important camp?
(you'll note that in my email I did ask whether we think
traceroute is important)
Mark Smith wrote:
The
On Sep 24, 2006, at 4:33 PM, Mark Kent wrote:
Remember, we're not talking about RFC1918 space,
where there is a BCP that says we should filter it at the edge.
We're talking about public IP space, that just doesn't happen to be
announced outside of a particular AS.
If the intent is to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Kent wrote:
virendra rode wrote:
This is yet another reason one shouldn't rely on pings traceroutes to
perform reachability analysis.
So, you're in the traceroute is not important camp?
(you'll note that in my email I did ask whether we
[Can we all have a moment of silence for a useful, interesting, and
on-topic post?]
On Sep 24, 2006, at 5:59 PM, Mark Kent wrote:
A smaller North American network provider, with a modest North
American backbone, numbers their internal routers on public IP space
that they do not announce to
41 matches
Mail list logo
