Re: The use of .0/.255 addresses.
> This is what happens when your educational system continues to teach > classful routing as anything other than a HISTORICAL FOOTNOTE > *coughCiscocough*. Yes, it sure would be nice if Cisco would revise some of their CCNA course material and exams. Plenty of classful stuff still left there, I'm afraid. It's kind of stupid when you have to tell fellow workers trying to get a certification "This isn't real life, you just have to learn it for the exam. In real life we use CIDR." Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: The use of .0/.255 addresses.
[EMAIL PROTECTED] wrote: It's kind of stupid when you have to tell fellow workers trying to get a certification "This isn't real life, you just have to learn it for the exam. In real life we use CIDR." You don´t have to take the CCNA stuff if you go for CCIE directly. Pete
Re: The use of .0/.255 addresses.
On Sat, Jun 26, 2004 at 07:41:17PM -0400, Chris Ranch wrote: > I see traffic from this last IP address octet all the time from > prefixes of length less than /24. Use of these host id's when the > prefix length is greater than or equal to /24 is illegal. So if > that's your case, I'd suggest not doing it. It's from a /24 assignment, but is actually being used for tunnel endpoints, so there seemed to be no reason not to use the .0 address. > If that's not the case, look for over-zealous or incorrect filters in > the path. I saw this situation once before. There was a border > ingress filter with a typo in it... I spent a long time looking for each filters, and watching traffic leave our network but not receiving any replies, while traceroutes would work just fine. As Peter points out, it's from what would have been Class C space, so it looks like I'm getting bitten by the Windows stuff. All 3 sites I mentioned as not being accessible are running under Windows according to Netcraft. J. -- Revd. Jonathan McDowell, ULC | I don't know. I'm a dog.
Re: The use of .0/.255 addresses.
On Sun, Jun 27, 2004 at 12:32:40AM +0100, Jonathan McDowell wrote: > Various people I've asked about this have said they wouldn't use the .0 > or .255 addresses themselves, though couldn't present any concrete info > about why not; my experience above would seem to suggest a reason not to > use them. This comes up every year or two on nanog; it's discouraging that operators and/or vendors are still screwing this up over a decade after RFC 1519. Thus spake "Richard A Steenbergen" <[EMAIL PROTECTED]> > This is what happens when your educational system continues to teach > classful routing as anything other than a HISTORICAL FOOTNOTE > *coughCiscocough*. This is also how you end up with 76k /24s in the global > routing table. "Those who can, do. Those who can't, teach." > Do you part to help control the ignorant population: whenever you hear > someone say "class [ABC]" in reference to anything other than a historical > allocation, smack them. Hard. It seems to be pretty common usage now to refer to a /24 as a "Class C", regardless of the first octet. Certainly incorrect, but half as many syllables... S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
Re: The use of .0/.255 addresses.
On Sat, 26 Jun 2004, Jon Lewis wrote: > > On Sat, 26 Jun 2004, Tony Li wrote: > > > The .255 address is very likely to be a broadcast address from a > > netblock of /24 or longer. I would suspect that folks are wary of > > accepting packets from a broadcast address as that could easily be a > > smurf. The .0 address was used as a broadcast address long ago and then > > was deprecated, so the same rationale probably applies. > > I have a case where this is currently biting me. I've got a few small > blocks of address space that I've chopped up into /32's for router > loopback IPs. These are in /24's which have been subnetted with various > sized customer subnets and then a /27 or so worth of router loopback > /32's. One in particular is: > > interface Loopback0 > ip address 209.208.6.255 255.255.255.255 Hi Jon, I currently have a few .255/32s with Cisco and Foundry products and have various windows/linux/OSX machines that access them without problems.. > I found some time ago that my home DSL connected network could not reach > (telnet, ping, etc.) that router's loopback. Our monitoring system could, > and several iBGP peers could, so I didn't notice the issue until one night > when trying to do some work from home. I could see the problem with DSL's where the provider may be interfering.. surprised about your monitoring tho... > What I've found is that one of our routers (7206 doing T1/DSL aggregation > running 12.1T) has .255 issues. Yes, it does have ip subnet-zero & ip > classless in the config. What's really odd is, from that 7206, I can > traceroute to 209.208.6.255, but if I ping 209.208.6.255 from it, I get > replies from another 209.208.6.x address on a connected T1 customer's CPE, > as if the ping was sent out as a broadcast ping. that looks really interesting. be curious as to how it gets forwarded across to CPE box to get the reply at all (even if it confuses the broadcast, surely you have directed broadcast disabled on 7206 + CPE)? Steve > > #sh ip ro 209.208.6.255 > Routing entry for 209.208.6.255/32 > Known via "ospf 1", distance 110, metric 20, type extern 2, forward > metric 4 > Last update from 209.208.16.29 on FastEthernet0/0.1, 00:46:47 ago > Routing Descriptor Blocks: > * 209.208.16.29, from 209.208.6.255, 00:46:47 ago, via FastEthernet0/0.1 > Route metric is 20, traffic share count is 1 > > #ping 209.208.6.255 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 209.208.6.255, timeout is 2 seconds: > > Reply to request 0 from XX (209.208.6.xyz), 68 ms > Reply to request 1 from XX (209.208.6.xyz), 68 ms > Reply to request 2 from XX (209.208.6.xyz), 68 ms > Reply to request 3 from XX (209.208.6.xyz), 68 ms > Reply to request 4 from XX (209.208.6.xyz), 68 ms > > I suppose I'll give up on using the .255 IP, but I've not been looking > forward to changing that as it means redoing half a dozen BGP peerings. > > -- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net| > _ http://www.lewis.org/~jlewis/pgp for PGP public key_ >
Re: The use of .0/.255 addresses.
Stephen J. Wilcox <[EMAIL PROTECTED]> wrote: [...] > I currently have a few .255/32s with Cisco and Foundry products and > have various windows/linux/OSX machines that access them without > problems.. Well, I'd expect Linux and OSX to do the right thing. It just seems to be Windows that makes a complete sow's ear of it. As to the IP addresses ending in 255 that are working from Windows boxes, would I be right in guessing that the first octet of the IP addresses in question is between 1 and 191? -- PGP key ID E85DC776 - finger [EMAIL PROTECTED] for full key
Re: The use of .0/.255 addresses.
On Sun, 27 Jun 2004, Peter Corlett wrote: > > Stephen J. Wilcox <[EMAIL PROTECTED]> wrote: > [...] > > I currently have a few .255/32s with Cisco and Foundry products and > > have various windows/linux/OSX machines that access them without > > problems.. > > Well, I'd expect Linux and OSX to do the right thing. It just seems to > be Windows that makes a complete sow's ear of it. > > As to the IP addresses ending in 255 that are working from Windows > boxes, would I be right in guessing that the first octet of the IP > addresses in question is between 1 and 191? Hi Peter, actually no.. I just did a test right now, I'm at a friends and using an XP machine connected via a cable modem.. my results arent entirely in agreement with my initial post I tested to both a "Class A" .255 we have and also to a "Class C" .255 we have Class A: works on everything..trace, ping, ssh Class C: spooky, traces up to the interface before the device. wont ping. connections fail with Network error: Cannot assign requested address. But, this same test works when tried from linux - possibly different behaviour between icmp and udp on cisco?? >From the hop-before-last (cisco 7206 12.2(14)S3) if i ping it seems to be broadcasting out of the interface towards the .255 rather than unicasting, i confirm this with a packet capture: 16:03:47.614187 Class-C.x.x.x > 255.255.255.255: icmp: echo request the cisco reports correct routing of the Class-C /32 Steve
BGP list of phishing sites?
Happy Sunday nanogers... I was doing some follow up reading on the "js.scob.trojan", the latest "hole big enough to drive a truck through" exploit for Internet Explorer. On the the things the article mentioned is that ISP/NSPs are shutting off access to the web site in russia where the malware is being downloaded from. Now we've done this in the past when a known target of a DDOS was upcoming or a known website hosted part of a malware package, and it is fairly effective in stopping the problems. So what I was curious about is would there be interest in a BGP feed (like the DNSBLs used to be) to null route known malicious sites like that? Obviously, both operational guidelines, and trust of the operator would have to be established, but I was thinking it might be useful for a few purposes: 1> IP addresses of well known sources of malicious code (like in the example above) 2> DDOS mitigation (ISP/NSP can request a null route of a prefix which will save the "Internet at large" as well as the NSP from the traffic flood 3> etc Since the purpose of this list would be to identify and mitigate large scale threats, things like spammers, etc would be outside of it's charter. If anyone things this is a good (or bad) idea, please let me know. Obviously it's not fully cooked yet, but I wanted to throw it out there. Thanks -Scott
Re: BGP list of phishing sites?
On Sun, 27 Jun 2004, Scott Call wrote: > > Happy Sunday nanogers... > > I was doing some follow up reading on the "js.scob.trojan", the latest > "hole big enough to drive a truck through" exploit for Internet Explorer. > > On the the things the article mentioned is that ISP/NSPs are shutting off > access to the web site in russia where the malware is being downloaded > from. > > Now we've done this in the past when a known target of a DDOS was upcoming > or a known website hosted part of a malware package, and it is fairly > effective in stopping the problems. > > So what I was curious about is would there be interest in a BGP feed (like > the DNSBLs used to be) to null route known malicious sites like that? > don't reinvent the wheel: www.cymru.com has a project already under way for this, with many operators participating at this time.
Re: The use of .0/.255 addresses.
On Sun, 27 Jun 2004, Stephen J. Wilcox wrote:
> Hi Jon,
> I currently have a few .255/32s with Cisco and Foundry products and have
> various windows/linux/OSX machines that access them without problems..
I'm pretty confident this is a classful/classless bug in 12.1T. I just
got into the customer's router that was sending what looked like replies
to a broadcast ping, and that's just what it was. Here's the output from
debug ip packet on the CPE that was replying when I pinged 209.208.6.255
from the 7206.
IP: s=209.208.6.xyz (Serial0.2), d=255.255.255.255, len 100, rcvd 2
IP: s=209.208.6.xyz (Serial0.2), d=255.255.255.255, len 100, rcvd 2
IP: s=209.208.6.xyz (Serial0.2), d=255.255.255.255, len 100, rcvd 2
Checked with an ACL on the input side of the CPE's serial subint,
*Mar 3 08:40:19: %SEC-6-IPACCESSLOGDP: list test permitted icmp
209.208.6.xyZ (Serial0.2 DLCI 100) -> 255.255.255.255 (0/0), 1 packet
where 209.208.6.xyz is the customer's serial IP, and 209.208.6.xyZ is the
7206's serial IP.
Both ends to have no ip directed-broadcast.
> > I found some time ago that my home DSL connected network could not reach
> > (telnet, ping, etc.) that router's loopback. Our monitoring system could,
> > and several iBGP peers could, so I didn't notice the issue until one night
> > when trying to do some work from home.
>
> I could see the problem with DSL's where the provider may be interfering..
> surprised about your monitoring tho...
No...I said the monitoring system didn't have a problem with it. It
fortunately doesn't have to transit the affected router which only handles
T1 & DSL aggregation (including my home DSL).
> > #sh ip ro 209.208.6.255
> > Routing entry for 209.208.6.255/32
> > Known via "ospf 1", distance 110, metric 20, type extern 2, forward
> > metric 4
> > Last update from 209.208.16.29 on FastEthernet0/0.1, 00:46:47 ago
> > Routing Descriptor Blocks:
> > * 209.208.16.29, from 209.208.6.255, 00:46:47 ago, via FastEthernet0/0.1
> > Route metric is 20, traffic share count is 1
#sh ip cef 209.208.6.255
209.208.6.255/32, version 12215105, cached adjacency 209.208.16.29
0 packets, 0 bytes
tag information set, shared
local tag: 398
fast tag rewrite with Fa0/0.1, 209.208.16.29, tags imposed: {114}
via 209.208.16.29, FastEthernet0/0.1, 0 dependencies
next hop 209.208.16.29, FastEthernet0/0.1
valid cached adjacency
tag rewrite with Fa0/0.1, 209.208.16.29, tags imposed: {114}
#sh tag-switching forwarding-table 209.208.6.255 detail
Local OutgoingPrefixBytes tag Outgoing Next Hop
tagtag or VC or Tunnel Id switched interface
398114 209.208.6.255/32 0 Fa0/0.1209.208.16.29
MAC/Encaps=18/22, MTU=1520, Tag Stack{114}
0001638B9005DC49340081018847 00072000
No output feature configured
Per-packet load-sharing
It knows the next hop is another 7206 with connections to the rest of our
network. Why is it sending this out as a broadcast ping instead of
routing (tag switching) it? I know...wrong list. I'll ask on cisco-nsp,
but the operational lesson here is that it's not just the junk from
Redmond that may have classful/classless IP routing issues. Even your
core routers might, depending on IOS versions.
--
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: BGP list of phishing sites?
On 27-jun-04, at 20:17, Scott Call wrote: On the the things the article mentioned is that ISP/NSPs are shutting off access to the web site in russia where the malware is being downloaded from. Now we've done this in the past when a known target of a DDOS was upcoming or a known website hosted part of a malware package, and it is fairly effective in stopping the problems. So what I was curious about is would there be interest in a BGP feed (like the DNSBLs used to be) to null route known malicious sites like that? I'm sure there is; but I'm slightly worried that transit networks may be tempted to subscribe to such a feed and in essence start censoring their customer's access to the net. Also, an "easy fix" like this may lower the pressure on the parties who are really responsible for allowing this to happen: the makers of insecure software / insecure operational procedures (banks!) and gullible users. Fixing layer 7+ problems at layer 3 just doesn't work and leads to significant collateral damage in the long run.
Re: The use of .0/.255 addresses.
On 27-jun-04, at 16:12, Peter Corlett wrote: I currently have a few .255/32s with Cisco and Foundry products and have various windows/linux/OSX machines that access them without problems.. Well, I'd expect Linux and OSX to do the right thing. It just seems to be Windows that makes a complete sow's ear of it. If you want to have some real fun, try configuring some class E addresses. Windows of course won't have it, and Cisco also doesn't want anything to do with it, even to the point of rejecting routes within 240.0.0.0/4 when they come in over BGP. (Which an MacOSX box running Zebra will happily provide.)
Re: The use of .0/.255 addresses.
On Sun, 27 Jun 2004, Iljitsch van Beijnum wrote:
If you want to have some real fun, try configuring some class E
addresses. Windows of course won't have it, and Cisco also doesn't
want anything to do with it, even to the point of rejecting routes
within 240.0.0.0/4 when they come in over BGP. (Which an MacOSX box
running Zebra will happily provide.)
Class D you mean surely?
Note that while GNU Zebra might be configurable to provide such
updates, it too rejects such updates if received on unicast IPv4
address family sessions bgp_route.c::bgp_nlri_parse():
/* Check address. */
if (packet->afi == AFI_IP && packet->safi == SAFI_UNICAST)
{
if (IN_CLASSD (ntohl (p.u.prefix4.s_addr)))
{
zlog (peer->log, LOG_ERR,
"IPv4 unicast NLRI is multicast address %s",
inet_ntoa (p.u.prefix4));
bgp_notify_send (peer,
BGP_NOTIFY_UPDATE_ERR,
BGP_NOTIFY_UPDATE_INVAL_NETWORK);
return -1;
}
}
and has done since GNU Zebra 0.91.
regards,
--
Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A
warning: do not ever send email to [EMAIL PROTECTED]
Fortune:
Many receive advice, few profit by it.
-- Publilius Syrus
Re: BGP list of phishing sites? Website behind Net attack offline
http://www.news.com.au/common/story_page/0,4057,9975753%255E1702,00.html -Henry --- Scott Call <[EMAIL PROTECTED]> wrote: > > Happy Sunday nanogers... > > I was doing some follow up reading on the > "js.scob.trojan", the latest > "hole big enough to drive a truck through" exploit > for Internet Explorer. > > On the the things the article mentioned is that > ISP/NSPs are shutting off > access to the web site in russia where the malware > is being downloaded > from. > > Now we've done this in the past when a known target > of a DDOS was upcoming > or a known website hosted part of a malware package, > and it is fairly > effective in stopping the problems. > > So what I was curious about is would there be > interest in a BGP feed (like > the DNSBLs used to be) to null route known malicious > sites like that? > > Obviously, both operational guidelines, and trust of > the operator would > have to be established, but I was thinking it might > be useful for a few > purposes: > > 1> IP addresses of well known sources of malicious > code (like in the > example above) > 2> DDOS mitigation (ISP/NSP can request a null route > of a prefix which > will save the "Internet at large" as well as the NSP > from the traffic > flood > 3> etc > > Since the purpose of this list would be to identify > and mitigate large > scale threats, things like spammers, etc would be > outside of it's charter. > > If anyone things this is a good (or bad) idea, > please let me know. > Obviously it's not fully cooked yet, but I wanted to > throw it out there. > > Thanks > -Scott >
Re: The use of .0/.255 addresses.
On Sun, 27 Jun 2004, Paul Jakma wrote: On Sun, 27 Jun 2004, Iljitsch van Beijnum wrote: do with it, even to the point of rejecting routes within 240.0.0.0/4 when they come in over BGP. (Which an MacOSX box running Zebra will happily provide.) Class D you mean surely? sigh, i cant read, you did mean class E ;) regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A warning: do not ever send email to [EMAIL PROTECTED] Fortune: "Die? I should say not, dear fellow. No Barrymore would allow such a conventional thing to happen to him." -- John Barrymore's dying words
Re: Attn MCI/UUNet - Massive abuse from your network
On Sat, 26 Jun 2004, Richard Welty wrote: > On Sat, 26 Jun 2004 10:50:12 -0700 (PDT) "Tom (UnitedLayer)" <[EMAIL PROTECTED]> > wrote: > > The big deal is that spam complaining/etc is not operational content, and > > there are several other lists to handle that sort of thing. > > but then, individuals get 1 free shot at saying things that are in > some cases not true about spamhaus, and Steve is prohibited from > attempting to correct them. Steve can correct whomever he wants off list. If he wants to do it on list, it better be for a good reason, no? If the person posting the untrue information is not posting with operational content, they should be censured as well... A simple "these statements are untrue, please contact me off list for the truth" is hardly unreasonable.
Re: BGP list of phishing sites?
> > So what I was curious about is would there be interest in a BGP feed > > (like the DNSBLs used to be) to null route known malicious sites like > > that? i dunno much about this new-fangled "DNSBL" thing you speak of, but the original MAPS RBL is still alive and well and available by BGP. the fine folks now running MAPS include Dave Rand (my co-founder) and if you visit their web site (www.mail-abuse.org) you can probably figure out how to sign up for it. there's a fee involved, but there are lawyers involved, and those two things seem to come in pairs. > I'm sure there is; but I'm slightly worried that transit networks may > be tempted to subscribe to such a feed and in essence start censoring > their customer's access to the net. we (speaking for the original MAPS which i still had a hand in operating) faced that from most bgp-subscribing customers. there are easy workarounds. > Also, an "easy fix" like this may lower the pressure on the parties who > are really responsible for allowing this to happen: the makers of > insecure software / insecure operational procedures (banks!) and gullible > users. actually, a bgp feed of this kind tends to supply the "missing causal vector" whereby someone who does something sloppy or bad ends up suffering for it. > Fixing layer 7+ problems at layer 3 just doesn't work and leads to > significant collateral damage in the long run. that's what everybody always said about MAPS but it didn't happen. the internet is very survivable and the necessary traffic always finds a way to get through. fixing layer >7 problems by denying layer 3 service has indeed proven to be the only way to get remote CEO's to care (or notice). -- Paul Vixie
Re: Attn MCI/UUNet - Massive abuse from your network
: : A simple "these statements are untrue, please contact me off list for the : truth" is hardly unreasonable. : : : Unfortunately a restriction such as that on this list defeats the atmosphere of openness and education for those who may be reading, but not necessarily posting to the list. Educating users, even if some of the subscribers are the choir should be our collective goal. In my case not all the conversations (threads) on this list are pertinent to my operations but I still read them all, and am educated from time to time as well, which makes it worth the effort. IMHO. What I don't like to read are personal attacks or arrogance to the extreme. Doug
