Happy Holidays To You All! Am I the only one seeing the 192.168.0.0 test net going somewhere? RFC 1918 mandates 192.168.0.0/255.255.0.0 [192.168/16] for private networks (testing), right? Inc.net seems to have some problems...
From 206.183.227.10, I can get to them via telnet...These are definately NOT my hosts, either... :)
====== zeus% telnet 192.168.1.2 Trying 192.168.1.2 ... Connected to 192.168.1.2. Escape character is '^]'. ComOS - Livingston PortMaster login: ====== And this one: ====== zeus% traceroute 192.168.1.2 1 gw0-core0-ser1-eth0.Hilliard.netset.com (206.183.227.1) 1 ms 1 ms 4 ms 2 core1-hssi1-NETSET.Columbus.fnsi.net (206.183.239.73) 5 ms 4 ms 4 ms 3 aads.nap.net (198.32.130.39) 17 ms 27 ms 19 ms 4 aads.atm.inc.net (198.32.130.68) 25 ms 39 ms 21 ms 5 baryon.atm.inc.net (207.67.1.3) 21 ms 21 ms 24 ms 6 border-233.noc.inc.net (204.95.160.233) 31 ms 24 ms 30 ms ====== Just wanted some other expertise and input.... Regards, -Matt. -- Matthew D. Lammers -- NetSet Internet Solutions, Inc. http://www.netset.com/
Yet another reason to put Andrews list of bogus routes on your systems. Invariably these announcements pop up from time to time. If we are lucky Andrew may post the latest set of filters to the list. ---> Phil Matthew D. Lammers supposedly said:
Happy Holidays To You All!
Am I the only one seeing the 192.168.0.0 test net going somewhere? RFC 1918 mandates 192.168.0.0/255.255.0.0 [192.168/16] for private networks (testing), right? Inc.net seems to have some problems...
From 206.183.227.10, I can get to them via telnet...These are definately NOT my hosts, either... :)
====== zeus% telnet 192.168.1.2
Trying 192.168.1.2 ... Connected to 192.168.1.2. Escape character is '^]'.
ComOS - Livingston PortMaster
login:
======
And this one:
====== zeus% traceroute 192.168.1.2
1 gw0-core0-ser1-eth0.Hilliard.netset.com (206.183.227.1) 1 ms 1 ms 4 ms 2 core1-hssi1-NETSET.Columbus.fnsi.net (206.183.239.73) 5 ms 4 ms 4 ms 3 aads.nap.net (198.32.130.39) 17 ms 27 ms 19 ms 4 aads.atm.inc.net (198.32.130.68) 25 ms 39 ms 21 ms 5 baryon.atm.inc.net (207.67.1.3) 21 ms 21 ms 24 ms 6 border-233.noc.inc.net (204.95.160.233) 31 ms 24 ms 30 ms
======
Just wanted some other expertise and input....
Regards, -Matt.
-- Matthew D. Lammers -- NetSet Internet Solutions, Inc. http://www.netset.com/
Am I the only one seeing the 192.168.0.0 test net going somewhere? RFC 1918 mandates 192.168.0.0/255.255.0.0 [192.168/16] for private networks (testing), right? Inc.net seems to have some problems...
While they should not be announcing, you should not be listening. Try this and call back in the morning if it does not work. access-list 181 deny ip host 0.0.0.0 any access-list 181 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 181 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 181 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255 access-list 181 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 181 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 181 deny ip 223.255.255.0 0.0.0.255 255.255.255.0 0.0.0.255 randy
Don't try this at home without checking (read: delete) the first line.....and, if you feel brave, or you'd like to keep your customers, add something to the bottom..... >;) -Steve
While they should not be announcing, you should not be listening. Try this and call back in the morning if it does not work.
access-list 181 deny ip host 0.0.0.0 any access-list 181 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 181 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 181 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255 access-list 181 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 181 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 181 deny ip 223.255.255.0 0.0.0.255 255.255.255.0 0.0.0.255
access-list 181 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255 'cept these are legal delegation points.
delegation point? in bgp? randy, heading back to the rfc and manuals
access-list 181 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255 'cept these are legal delegation points.
delegation point? in bgp?
randy, heading back to the rfc and manuals
Sorry... legal prefixes. They can be delegated and announced. Just like: access-list 182 permit ip 199.2.98.0 0.0.0.255 255.255.255.0 0.0.0.255 -- --bill
access-list 181 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 182 permit ip 199.2.98.0 0.0.0.255 255.255.255.0 0.0.0.255
the latter permits something which the former does not deny. i.e. noop.
randy
permits/denys what? (a retorical query) the point being that there is no practical difference btween 199.2.98.0/24 and 192.0.0.0/24 or 128.0.0.0/24 or 191.255.255.0/24 these prefixes (and delegation points) are valid or potentially valid in the routing system whereas 192.0.2.0/24 and 172.16.0.0/16 and 192.168.0.0/24 and 10.0.0.0/8 are not. --bill (off to re-read RFC 1519 and RFC 1918 just to make sure)
and 192.0.0.0/24 or 128.0.0.0/24 or 191.255.255.0/24
these prefixes (and delegation points) are valid or potentially valid in the routing system
and someday, with enough marketing thrust, pigs could fly. with as many large isps filering these prefixes as there seem to be, and for good historic reason, my advice would be to bet on the pigs. rosenantes is getting nackered. and once again, what the heck is a 'delegation point' in bgp/routing? rfc/document reference, please? randy
The issue from our side has been fixed...I have word that "default" has been killed off. Also, noteworthy, that since we weren't getting these routes via BGP, filters didn't do much. Thanks! -Matt. Randy Bush wrote a while back: < < > and 192.0.0.0/24 < > or 128.0.0.0/24 < > or 191.255.255.0/24 < > < > these prefixes (and delegation points) are valid or potentially valid < > in the routing system < < and someday, with enough marketing thrust, pigs could fly. with as many < large isps filering these prefixes as there seem to be, and for good < historic reason, my advice would be to bet on the pigs. rosenantes is < getting nackered. < < and once again, what the heck is a 'delegation point' in bgp/routing? < rfc/document reference, please? < < randy < < -- Matthew D. Lammers -- NetSet Internet Solutions, Inc. http://www.netset.com/
I also sent this particular route to the bit bucket (Null0) at NAP.NET having not hear back from inc.net..... -Steve. Matthew D. Lammers wrote:
The issue from our side has been fixed...I have word that "default" has been killed off. Also, noteworthy, that since we weren't getting these routes via BGP, filters didn't do much.
Thanks!
-Matt.
Randy Bush wrote a while back: < < > and 192.0.0.0/24 < > or 128.0.0.0/24 < > or 191.255.255.0/24 < > < > these prefixes (and delegation points) are valid or potentially valid < > in the routing system < < and someday, with enough marketing thrust, pigs could fly. with as many < large isps filering these prefixes as there seem to be, and for good < historic reason, my advice would be to bet on the pigs. rosenantes is < getting nackered. < < and once again, what the heck is a 'delegation point' in bgp/routing? < rfc/document reference, please? < < randy < <
-- Matthew D. Lammers -- NetSet Internet Solutions, Inc. http://www.netset.com/
permits/denys what? (a retorical query) the point being that there is no practical difference btween
199.2.98.0/24 and 192.0.0.0/24 or 128.0.0.0/24 or 191.255.255.0/24
these prefixes (and delegation points) are valid or potentially valid in the routing system whereas
192.0.2.0/24 and 172.16.0.0/16 and 192.168.0.0/24 and 10.0.0.0/8
are not.
--bill (off to re-read RFC 1519 and RFC 1918 just to make sure)
Bill, You remind me of something I've been hunting for, which I think is relevant to a lot of operationally related educational examples. Are there prefixes that are likely to stay unassigned for the moderate to long term, other than the RFC1918 group? If I'm showing how to use a NAT with private address space on one side and registered space on the other, I'd like to use some "safe" prefixes on the public side that are NOT from RFC1918. Is there some block likely to stay with IANA? Or possibly some space assigned to the military and likely to stay in a secure network? I really feel for the people who have 202.222.5.0, 131.108.0.0, and the other prefixes used in Cisco educational material for many years! How many clueless people have picked those as their network numbers? Howard
At 8:14 PM -0500 12/23/97, Howard C. Berkowitz wrote:
You remind me of something I've been hunting for, which I think is relevant to a lot of operationally related educational examples. Are there prefixes that are likely to stay unassigned for the moderate to long term, other than the RFC1918 group?
If I'm showing how to use a NAT with private address space on one side and registered space on the other, I'd like to use some "safe" prefixes on the public side that are NOT from RFC1918. Is there some block likely to stay with IANA? Or possibly some space assigned to the military and likely to stay in a secure network?
Egads. This is just like the old pre-configured sunos IP numbers. That was part of the reason for RFC1597 anyway. Here's what I do: use another RFC1918 net for demonstration (try a class A number so it looks different) and pretend its routed. It doesn't (shouldn't) matter to the NAT. If you aren't connected to the net, it doesn't matter anyway. If you are connected to the net, then use the actual assigned network number, and have a real demonstration. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Try this one instead: access-list 101 deny ip any 0.0.0.0 252.0.0.0 access-list 101 deny ip any 255.255.255.128 0.0.0.127 access-list 101 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 101 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 101 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 101 deny ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255 access-list 101 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 101 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 101 deny ip 223.255.255.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 224.0.0.0 31.255.255.255 224.0.0.0 31.255.255.255 access-list 101 deny ip 192.41.177.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 198.32.136.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 198.32.146.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 198.32.134.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 198.32.158.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 198.32.176.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 198.32.184.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 192.157.69.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 198.32.128.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 198.32.140.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 deny ip 198.32.130.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 101 permit ip any any -Steve -- +--------------------------------------------------------+ | Steve Carter scarter@genuity.net | | GENUITY Inc. Phone: (602) 308 2386 | +--------------------------------------------------------+ | "I used to think that the brain was the most wonderful | | organ in my body. Then I realized who was telling me | | this." -- Emo Phillips | +--------------------------------------------------------+
Ack! You don't have a permit statement in there. The last line should read something like: access-list 181 permit ip any any Also, I'd input the list before applying it to the apropriate interfaces. The slower ciscos seem to appreciate it more when it's done that way, though my 7206 just screams through it. Lord knows the kind of stress doing something like that could cause without a permit statement, especially if your offsite. Regards, Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services Fortune for today: "You're not drunk if you can lie on the floor without holding on." -- Dean Martin On Tue, 23 Dec 1997, Randy Bush wrote:
Am I the only one seeing the 192.168.0.0 test net going somewhere? RFC 1918 mandates 192.168.0.0/255.255.0.0 [192.168/16] for private networks (testing), right? Inc.net seems to have some problems...
While they should not be announcing, you should not be listening. Try this and call back in the morning if it does not work.
access-list 181 deny ip host 0.0.0.0 any access-list 181 deny ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 181 deny ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 181 deny ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255 access-list 181 deny ip 191.255.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 192.0.2.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 181 deny ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 181 deny ip 192.0.0.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 181 deny ip 223.255.255.0 0.0.0.255 255.255.255.0 0.0.0.255
randy
ghaque! sorry. it was an excerpt from the middle of our actual acl. one usually filters on more than just those martians. e.g. we drop meet-point meshes, some hijacked prefixes the nics have asked us to help stomp, ... and aside from the permit at the bottom, we also have a no access-list at the top. keeps from accumulating hair. randy
This has been repaired as of 12/24. We apologize for the confusion, and any time people may have spent debugging privately numbered applications, Ryan Brooks ryan@inc.net Matthew D. Lammers wrote:
Happy Holidays To You All!
Am I the only one seeing the 192.168.0.0 test net going somewhere? RFC 1918 mandates 192.168.0.0/255.255.0.0 [192.168/16] for private networks (testing), right? Inc.net seems to have some problems...
participants (9)
-
bmanning＠ISI.EDU -
Dean Anderson -
Howard C. Berkowitz -
Joe Shaw -
Matthew D. Lammers -
Philip J. Nesser II -
Randy Bush -
Ryan Brooks -
Steve Carter