168.0.0.0/6

route-views.oregon-ix.net>sh ip bgp 169.223.0.0
BGP routing table entry for 168.0.0.0/6, version 7688303
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  3277 13062 20485 20485 20485 8437 3303
    194.85.4.249 from 194.85.4.249 (194.85.4.249)
      Origin IGP, localpref 100, valid, external, best

ripe is being overgenerous to the swiss!

Not so. They are pretending to be over-endowed to some peers
only.

Isn't that something to notify AS3303 aka SWISSCOM about rather than NANOG?
Especially since it does not look like it is spreading very widely.

Daniel

OK, any bets on how much improperly ingress/egress filtered traffic
to 169.254/16 this is going to attract? :wink:

Hi Randy,
Actually you only discovered the emerged part of the iceberg ...

Cheers,
Andr�

*> 24.0.0.0 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 60.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 62.0.0.0 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 63.0.0.0 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 64.0.0.0/6 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 68.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 70.0.0.0 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 80.0.0.0/6 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 84.0.0.0 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 128.0.0.0/3 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 160.0.0.0/5 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 168.0.0.0/6 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 199.0.0.0/8 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 200.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 202.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 204.0.0.0/6 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 208.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 210.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 212.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 216.0.0.0/8 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 217.0.0.0/8 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 218.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 220.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 222.0.0.0/8 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i

Not so, as has been re-re-re-hashed, 3303 is sending bogon
feeds to some parties [presumably their customers] and those
are getting regurgitated to route-views. route-views is a
varied slice of different kinds of announcement sets (full
tables, partial, internal deaggs, ect etc); looking-glass
comparison shopping is the only way to get meaningful data.

route-views.oregon-ix.net>sh ip bgp 169.223.0.0
BGP routing table entry for 168.0.0.0/6, version 7688303
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  3277 13062 20485 20485 20485 8437 3303
    194.85.4.249 from 194.85.4.249 (194.85.4.249)
      Origin IGP, localpref 100, valid, external, best

*> 24.0.0.0 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 60.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 62.0.0.0 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 63.0.0.0 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 64.0.0.0/6 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 68.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 70.0.0.0 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 80.0.0.0/6 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 84.0.0.0 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 128.0.0.0/3 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 160.0.0.0/5 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 168.0.0.0/6 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 199.0.0.0/8 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 200.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 202.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 204.0.0.0/6 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 208.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 210.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 212.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 216.0.0.0/8 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 217.0.0.0/8 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 218.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 220.0.0.0/7 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i
*> 222.0.0.0/8 194.85.4.249 0 3277 13062 20485 20485 20485 8437 3303 i

this seems to cause some strangeness when one's block is having various
announcement problems and falls within swisscom's imperialistic reach. is
cousin george doing their routing policy? :slight_smile:

randy

BGP routing table entry for 168.0.0.0/6, version 7688303
...
  3277 13062 20485 20485 20485 8437 3303
    194.85.4.249 from 194.85.4.249 (194.85.4.249)
      Origin IGP, localpref 100, valid, external, best

ripe is being overgenerous to the swiss!

Not so. They are pretending to be over-endowed to some peers
only.

Not so, as has been re-re-re-hashed, 3303 is sending bogon
feeds to some parties [presumably their customers] and those
are getting regurgitated to route-views. route-views is a
varied slice of different kinds of announcement sets (full
tables, partial, internal deaggs, ect etc); looking-glass
comparison shopping is the only way to get meaningful data.

the problem is that those getting the over-reaching data have
a view of the internet which can cause them and some destinations
problems. this is very analogous to seeing 0/0 with a six hop
path in route-views, as you say, we don't really know the reach
of the bad data.

randy

Isn't that something to notify AS3303 aka SWISSCOM about rather
than NANOG?

perhaps because this path has been taken in the past and failed?

Especially since it does not look like it is spreading very
widely.

hard to tell, isn't it. and hard to say the effect on the places
to which it has spread.

randy

This has been mentioned on nanog maillist before, it appears several months
after notification swisscom still has not fixed this problem (when similar
leak came from he, I think they fixed it in 48 hours!). Here are pointers
to previous thread:
http://www.merit.edu/mail.archives/nanog/2003-11/msg00626.html
http://www.merit.edu/mail.archives/nanog/2003-11/msg00636.html

-----BEGIN PGP SIGNED MESSAGE-----

william(at)elan.net wrote:

This has been mentioned on nanog maillist before, it appears several months
after notification swisscom still has not fixed this problem(when similar
leak came from he, I think they fixed it in 48 hours!). Here are pointers
to previous thread:
http://www.merit.edu/mail.archives/nanog/2003-11/msg00626.html
http://www.merit.edu/mail.archives/nanog/2003-11/msg00636.html

I guess SWISSCOM (AS3303) has a nice trackrecord to uphold:
http://mailman.isi.edu/pipermail/6bone/2002-December/006924.html

Added the persons who where able to fix that problem that time,
maybe it helps this time too :wink:

Greets,
Jeroen

> Isn't that something to notify AS3303 aka SWISSCOM about rather
> than NANOG?

perhaps because this path has been taken in the past and failed?

> Especially since it does not look like it is spreading very
> widely.

hard to tell, isn't it. and hard to say the effect on the places
to which it has spread.

I have previously contacted Swisscom about it back in 9/2003 and received the following response:

we are filtering on RIR minimal allocation boundaries. This creates some routing holes which we fill by these semi-default routes (towards our upstreams) for our customers' perusal.

Fixedorbit had to special case Swisscom since they came out in their IP table as the #1 IP holder. That honor is now held by DISO.

-Hank

I have previously contacted Swisscom about it back in 9/2003 and
received the following response:

we are filtering on RIR minimal allocation boundaries. This
creates some routing holes which we fill by these semi-default
routes (towards our upstreams) for our customers' perusal.

luckily, things like this are never leaked into the open internet
by multi-homed customers and weak filtering policies.
</sarcasm>

randy