On Tue, 16 Sep 2008 12:01:58 +0700, Constantine A. Murenin <[EMAIL PROTECTED]> wrote:

2008/9/16 Insan Praja SW <[EMAIL PROTECTED]>:
On Tue, 16 Sep 2008 04:27:00 +0700, Peter N. M. Hansteen <[EMAIL PROTECTED]>
wrote:

"Insan Praja SW" <[EMAIL PROTECTED]> writes:

My company recently bought 202[dot]90[dot]194[dot]0/23 IPs, and since
we  start using this IPs, I can't access www.bsdly.net and several
others site  on the net.

Thanks for reporting this.  I hope it's a temporary routing problem
that will just disappear soon.  By way of debugging, traceroute from
here seems to try to take a scenic route to your subnet before ending
up disallowed:

[EMAIL PROTECTED]:~$ traceroute -I 202.90.194.1
traceroute to 202.90.194.1 (202.90.194.1), 64 hops max, 60 byte packets
 1  10.168.103.1 (10.168.103.1)  17.277 ms  0.960 ms  1.41 ms
2 213-187-179-197.dd.nextgentel.com (213.187.179.197) 19.26 ms 98.506
ms  99.858 ms
 3  1.80-202-103.nextgentel.com (80.202.103.1)  15.629 ms  15.913 ms
 15.874 ms
 4  217-13-1-194.dd.nextgentel.com (217.13.1.194)  32.901 ms  23.91 ms
 22.110 ms
 5  80-202-2-74.dd.nextgentel.com (80.202.2.74)  22.41 ms  30.594 ms
 22.997 ms
 6  * * *
7 oso-b2-link.telia.net (213.248.92.57) 39.839 ms 32.912 ms 49.572 ms 8 kbn-bb2-link.telia.net (80.91.250.117) 42.493 ms 47.849 ms 30.725
ms
 9  hbg-bb2-pos5-0-0.telia.net (213.248.65.125)  42.64 ms  34.820 ms
 52.735 ms
10  ffm-bb2-pos7-0-0.telia.net (213.248.65.121)  44.386 ms
ffm-bb2-link.telia.net (80.91.248.85) 54.624 ms ffm-bb2-pos7-0-0.telia.net
(213.248.65.121)  51.565 ms
11 ffm-b3-link.telia.net (80.91.249.141) 49.492 ms 53.717 ms 45.759 ms
12  france-telecom-119877-ffm-b3.telia.net (213.248.77.206)  55.374 ms
 46.38 ms  56.170 ms
13  * * *
14  * * *
15  * * *
16 202.188.139.165 (202.188.139.165) 360.863 ms 343.342 ms 343.545 ms
17  219.93.174.81 (219.93.174.81)  344.32 ms  361.180 ms  344.423 ms
18  58.27.124.57 (58.27.124.57)  337.910 ms  339.586 ms  337.497 ms
19  58.27.113.4 (58.27.113.4)  353.673 ms  353.621 ms  353.515 ms
20  219.94.12.141 (219.94.12.141)  364.484 ms  471.982 ms  354.163 ms
21  210.187.143.1 (210.187.143.1)  344.819 ms  343.707 ms  343.652 ms
22 202.188.224.118 (202.188.224.118) 353.726 ms 359.527 ms 354.379 ms 23 brf-backbone02-ether0-0.tm.net.my (202.188.0.8) 339.18 ms 337.942 ms
 337.610 ms
24  58.26.88.6 (58.26.88.6)  636.253 ms  379.711 ms  381.87 ms
25  * * *
26  host67-123.cust.sat.net.id (202.149.67.123)  390.556 ms  382.394 ms
 385.217 ms
27  * * *
28  * * *
29 * host67-123.cust.sat.net.id (202.149.67.123) 429.645 ms !H 394.636
ms !H

A traceroute from your end would likely be useful at this point.
bsdly.net unfortunately is not alone in our local /24, and it wouldn't
surprise me overmuch if a "we-blacklist-/24s-and-/16s-because-we-can"
operation is part of the problem.  If it doesn't blow over
automagically, I likely need to spend some time on this.

Thanks,
Peter

Hi Peter,
$ traceroute www.bsdly.net
traceroute to www.bsdly.net (213.187.179.198), 64 hops max, 40 byte packets
 1  core1-router (202.90.194.2)  3.408 ms  0.896 ms  2.939 ms
 2  202.149.95.69 (202.149.95.69)  6.388 ms  7.522 ms  6.905 ms
 3  bb-1.nx.satata.net (202.149.94.232)  5.890 ms  7.859 ms  7.434 ms
 4  58.26.88.5 (58.26.88.5)  38.867 ms  35.405 ms  33.918 ms
 5  219.93.151.211 (219.93.151.211)  33.849 ms 219.93.151.227
(219.93.151.227) 35.520 ms
219.93.151.211 (219.93.151.211)  35.670 ms
 6  if-7-3.mcore4.LAA-LosAngeles.as6453.net (216.6.85.37)  227.272 ms
 226.752 m                                              s  224.802 ms
 7  Vlan77.icore1.LAA-LosAngeles.as6453.net (216.6.85.46)  224.232 ms
 232.287 m                                              s  233.779 ms
 8  las-bb1-pos2-3-3.telia.net (213.248.94.49)  280.720 ms  274.574 ms
 257.230                                               ms
9 nyk-bb1-link.telia.net (80.91.252.226) 318.744 ms 318.127 ms 318.268
ms
10  kbn-bb1-pos1-3-0.telia.net (213.248.64.21)  340.139 ms  339.660 ms
 339.716                                               ms
11 oso-b2-link.telia.net (80.91.254.234) 333.682 ms 334.749 ms 333.725
ms
12 * nextgentel-ic-118934-oso-b3.c.telia.net (80.239.193.94) 338.705 ms
 338.5 ms
13 217-13-1-193.dd.nextgentel.com (217.13.1.193) 349.121 ms 348.724 ms
 348.225 ms
14 213-187-179-197.dd.nextgentel.com (213.187.179.197) 451.616 ms 399.687
ms  400.194 ms
15 skapet.bsdly.net (213.187.179.198) 363.203 ms 362.121 ms 363.217 ms

I got 2 upstreams, when I start prepending my ASNumber to my one of my
upstream, I can magically access www.bsdly.net :D, even without prepending, in/out to your net is only using 1 upstream. So, it must be something on the other side. All my routers are openbsd 4.4-current, armed with BGPd and PF enabled. This may got something todo with stateful nature of PF, which I'm

I think you might find PF's 'sloppy' states useful if the problem is
only when using more than one upstream.

C.

Hi,
I read man [5] pf.conf, and currently in process of trying PF 'sloppy' states. I'd really hope it could work. Right know, I tried to put it on each rule. I'll get back with the result. If anyone had any example of using sloppy states, I'd love to hear it. This is my filter rules.

pass in quick on {$back_if0 $upstream_if0} inet to <gl_public> keep state (sloppy source-track global) tag GL_ASYMM_IN pass in quick on $core_if inet from <gl_public> keep state (sloppy source-track global) tag GL_ASYMM_OUT

pass out quick on $upstream_if0 inet tagged GL_ASYMM_OUT keep state (sloppy source-track global) pass out quick on $core_if inet tagged GL_ASYMM_IN keep state (sloppy source-track global)

--
insandotpraja(at)gmaildotcom

Reply via email to