Re: Who does source address validation? (was Re: what's that smel l?)
At 10:43 PM 09-10-02 -0700, Steve Francis wrote: [EMAIL PROTECTED] wrote: My personal pet peeve is the opposite - we'll try to use pMTU, some provider along the way sees fit to run it through a tunnel, so the MTU there is 1460 instead of 1500 - and the chuckleheads number the tunnel endpoints out of 1918 space - so the 'ICMP Frag Needed' gets tossed at our border routers, because we do both ingress and egress filtering. That's not terribly hard to overcome - allow icmp unreachables (from any source) in your acl, then deny all traffic from RFC 1918 addresses, then the rest of the ACL. Combined with CAR (or CatOS QoS rate limiting) on icmp's, you end up with all the functionality, and almost none of the bogus traffic. CAR should not be used to rate-limit but instead use the MQC police command which basically does the same thing. CAR is not going to be around much longer and is not being developed anymore: Have a look at: http://www.cisco.com/warp/public/105/cbpcar.html http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt8/qcfmcli2.htm for more information. -Hank
Re: per-packet load sharing in cef or dcef
I am not sure what is happening for you, but as a general rule of thumb I don't run per-packet load sharing on circuits that are not 'the same'. The need for packet re-ordering goes way up when you are running per-packet on two types of circuit. Are the circuits provisioned for the same speed at least? -jf On Thu, 10 Oct 2002, Adam Atkinson wrote: per-packet load sharing in cef / dcef just doesn't seem to want to work. I have two 7500s joined by a frame relay link and a fast ethernet. Traffic is coming in to one of the 7500s via a third link, and goes to a loopback on the second 7500. I have cef turned on I have ip load-sharing per-packet on every interface The FR and FE have the same ospf cost The routing tables and sh ip cef agree that there are two equal paths to the loopback. But all the traffic goes over one link. I've been through Cisco troubleshooting documents etc. and as far as I can see, everything is perfect. Also, a deja search reveals plenty of other people with similar problems, and no solutions I can see. Are we all missing something obvious? -- Adam Atkinson
Re: Who does source address validation? (was Re: what's that smell?)
On Thu, Oct 10, 2002 at 01:06:15AM -0400, [EMAIL PROTECTED] wrote: On Wed, 09 Oct 2002 23:05:59 BST, Stephen J. Wilcox said: On a related issue (pMTU) I recently discovered that using a link with MTU 1500 breaks a massive chunk of the net - specifically mail and webservers who block all inbound icmp.. the servers assume 1500, send out the packets with DF My personal pet peeve is the opposite - we'll try to use pMTU, some provider along the way sees fit to run it through a tunnel, so the MTU there is 1460 instead of 1500 - and the chuckleheads number the tunnel endpoints out of 1918 space - so the 'ICMP Frag Needed' gets tossed at our border routers, because we do both ingress and egress filtering. It's bad enough when all the interfaces on the offending unit are 1918-space, but it's really annoying when the critter has perfectly good non-1918 addresses it could use as the source... Argh... Ok, I know how this manages to rile people up, but might I suggest that you brought it upon yourself? There is a time and a place for messages sourced from addresses to which you cannot reply, and a time and place where those messages should not exist. Obviously, a dns *QUERY* is not the place for a message which cannot be returned. But what about an ICMP *RESPONSE*? Nothing depends upon the source address of the IP header for operation, the original headers which caused the problem are encoded in the ICMP message. And yet people are so busy concerning themselves with this mythical thing which might break from receiving ICMP overlapping existing internal 1918 space, the extra 0.4% of bandwidth which might be wasted, and the righteous feeling that they have done something useful, that they don't stop to realize *THEY* are the ones breaking PMTU-D. I'm sure we can all agree on at least the concept that sourcing packets from an address which cannot receive a reply is at least potentially useful, for example to avoid DoS against a critical piece of infrastructure. Would it make people feel better if there was a specific seperate non-routed address space reserved for router generated messages which don't want replies? Why? Even Windows 2000+ includes blackhole detection which will eventually remove the DF bit if packets aren't getting through and ICMP messages aren't coming back, something many unixes lack. But the heart of the problem is that people still push packets like every one must include the maximum data the MTU can support. Do we have any idea how much network suffering is being caused by that damn 1500 number right now? Aside from the fact that it is one of the worst numbers possible for the data, it throws a major monkey wrench in the use of tunnels, pppoe, etc. Eventually we will realize the way to go is something like 4096 data octets, plus some room for headers, on a 4470 MTU link. But if the best reason we can come up with is ISIS, the IEEE will just keep laughing. /rant -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: Who does source address validation? (was Re: what's that smell?)
On Thu, 10 Oct 2002, Richard A Steenbergen wrote: Even Windows 2000+ includes blackhole detection which will eventually remove the DF bit if packets aren't getting through and ICMP messages aren't coming back, something many unixes lack. Wow, now I'm impressed. And what about the 1999 other versions of Windows? This is hardly a new problem. Still, it's good that some people at least make progress, even if very slowly. But the heart of the problem is that people still push packets like every one must include the maximum data the MTU can support. And why not? Do we have any idea how much network suffering is being caused by that damn 1500 number right now? Aside from the fact that it is one of the worst numbers possible for the data, it throws a major monkey wrench in the use of tunnels, pppoe, etc. So don't use those. Eventually we will realize the way to go is something like 4096 data octets, plus some room for headers, on a 4470 MTU link. So what then if someone runs a secure tunnel over wireless over a PPPoE over ADSL using mobile IPv6 that runs over a tunnel or two ad nauseum until the headers get bigger than 374 bytes? Then you'll have your problem right back. Might as well really solve it the first try. One of the problems is that there is no generally agreed on and widely available set of rules for this stuff. Setting the DF bit on all packets isn't good, but it works. Using RFC1918 space to number your tunnel routers isn't good, but it works. Filtering validating source addresses on ingress is good, but hey, it doesn't work! Making a good list of best practices (and then have people widely implement them) might also go a long way towards showing concerned parties such as the US administration that the network community consists of responsible people that can work together for the common good. But if the best reason we can come up with is ISIS, the IEEE will just keep laughing. Why is the IEEE laughing?
Re: Who does source address validation? (was Re: what's that smell?)
On Thu, Oct 10, 2002 at 06:36:33PM +0200, Iljitsch van Beijnum wrote:
So what then if someone runs a secure tunnel over wireless over a PPPoE
over ADSL using mobile IPv6 that runs over a tunnel or two ad nauseum
until the headers get bigger than 374 bytes? Then you'll have your problem
right back. Might as well really solve it the first try.
This is a problem that would be solved by everyone being
responsible and doing pmtud properly.
One of the problems is that there is no generally agreed on and widely
available set of rules for this stuff. Setting the DF bit on all packets
isn't good, but it works. Using RFC1918 space to number your tunnel
routers isn't good, but it works. Filtering validating source addresses on
ingress is good, but hey, it doesn't work!
I think we're starting to get at the heart of the problem
but let me stick my neck out and say it:
Registries (APNIC, ARIN, RIPE, usw) charge for ip addresses.
be it via a lease/registration fee, it's a per-ip charge that ISPs must
get via some means out of their subscribers. (Unless people
don't care about money that is). Back in the days, one could
obtain ip addresses from Internic saying i will not connect
to internet, i intend to connect at some later date in a
year or two .. (or similar), i intend to connect now.
People number out of 1918 space primarily for a few
reasons, be them good or not:
1) Internal use
2) Cost involved.. nobody else needs to telnet to my p2p
links but me, and i don't want to pay {regional_rir} for my
internal use to reduce costs
3) security of not being a publicly accessible
network.
This can break many things, pmtu, multicast and various
streaming (multi)media applications.
With the past scare of we'll be out of ip addresses by 199x
still fresh in some peoples memories, they in their good consience decided
to also conserve ips via this method.
The problem is not everyone today that considers themselves
a network operator understands all the ramifications of their current
practices, be they good or bad.
Going into fantasy-land mode, if IPv6 addresses were instantly
used by everyone, people could once again obtain ips that could be
used for internal private use yet remain globally unique, therefore
allowing tracking back of who is leaking their own internal sources.
Making a good list of best practices (and then have people widely
implement them) might also go a long way towards showing concerned parties
such as the US administration that the network community consists of
responsible people that can work together for the common good.
I agree here, I personally think that numbering your internal
links out of 1918 space is not an acceptable solution unless it's
behind your natted network/firewall and does not leak out.
Perhaps some of those that are the better/brighter out there want
to start to write up a list of networking best practices.
Then test those book smart ccie/cne types with the information
to insure they understand the ramifications. a few good whitepapers
about these might be good to include or quiz folks on. i suspect
there's only a handful of people that actually understand the complete
end-to-end problem and all the ramifications involved as it is quite
complicated.
But if the best reason we can
come up with is ISIS, the IEEE will just keep laughing.
Why is the IEEE laughing?
The implication is that IEEE will not change the 802.x specs
to allow larger [default] link-local mtu due to legacy interop
issues. imagine your circa 1989 ne2000 card attempting to process
a 4400 byte frame on your local lan. a lot of the cheap ethernet
cards don't include enough buffering to handle such a large frame
let alone the legacy issues involved.. and remember the enterprise
networks have a far larger number of ethernet interfaces deployed
than the entire internet combined * 100 at least. any change
to the spec would obviously affect them also.
- jared
--
Jared Mauch | pgp key available via finger from [EMAIL PROTECTED]
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
[OT] Does AOL block IP Protocol #50 / UDP Port #500?
Greetings Does anyone know if AOL blocks the capability to use a VPN client over their DUI service? Sorry if this is off topic... GW
Anyone home at AOL?
Not the first time one of our clients has been impacted by AOL, nor the first time AOL has failed respond to requests/complaints. Though this isn't a DDOS like previous AOL-based network abuse, and probably isn't a dictionary attack, it is placing considerable strain on a couple of leased lines and mailexchangers. Any idea how a small network admin can get someone at AOL to deal with a problem like this? TIA, -- Roger Marquis Roble Systems Consulting http://www.roble.com/ PS. these logs illustrate only a small fraction of the SMTP activity from AOL's servers. Oct 9 10:57:06 PDT reject: RCPT from omr-d08.mx.aol.com[205.188.156.76]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:02:51 PDT reject: RCPT from omr-r01.mx.aol.com[152.163.225.129]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:03:19 PDT reject: RCPT from omr-d10.mx.aol.com[205.188.156.78]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:04:00 PDT reject: RCPT from omr-r04.mx.aol.com[152.163.225.132]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:07:24 PDT reject: RCPT from omr-m01.mx.aol.com[64.12.138.1]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:08:07 PDT reject: RCPT from omr-r03.mx.aol.com[152.163.225.131]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:08:23 PDT reject: RCPT from omr-d06.mx.aol.com[205.188.156.71]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:11:35 PDT reject: RCPT from omr-m01.mx.aol.com[64.12.138.1]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:11:54 PDT reject: RCPT from omr-r02.mx.aol.com[152.163.225.130]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:16:22 PDT reject: RCPT from omr-d08.mx.aol.com[205.188.156.76]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:24:39 PDT reject: RCPT from omr-r03.mx.aol.com[152.163.225.131]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:27:31 PDT reject: RCPT from omr-d07.mx.aol.com[205.188.159.13]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:29:59 PDT reject: RCPT from omr-d04.mx.aol.com[205.188.159.7]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:33:29 PDT reject: RCPT from omr-d05.mx.aol.com[205.188.156.66]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:35:59 PDT reject: RCPT from omr-d06.mx.aol.com[205.188.156.71]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:38:27 PDT reject: RCPT from omr-d05.mx.aol.com[205.188.156.66]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:42:03 PDT reject: RCPT from omr-r02.mx.aol.com[152.163.225.130]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:43:30 PDT reject: RCPT from omr-m01.mx.aol.com[64.12.138.1]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:48:58 PDT reject: RCPT from omr-d04.mx.aol.com[205.188.159.7]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:49:49 PDT reject: RCPT from omr-d10.mx.aol.com[205.188.156.78]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:50:44 PDT reject: RCPT from omr-m01.mx.aol.com[64.12.138.1]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:51:59 PDT reject: RCPT from omr-d10.mx.aol.com[205.188.156.78]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:54:40 PDT reject: RCPT from omr-m01.mx.aol.com[64.12.138.1]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:56:51 PDT reject: RCPT from omr-d09.mx.aol.com[205.188.156.77]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:56:57 PDT reject: RCPT from omr-d05.mx.aol.com[205.188.156.66]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:57:50 PDT reject: RCPT from omr-r03.mx.aol.com[152.163.225.131]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:06:01 PDT reject: RCPT from omr-d08.mx.aol.com[205.188.156.76]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:06:52 PDT reject: RCPT from omr-r08.mx.aol.com[152.163.225.153]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:11:59 PDT reject: RCPT from omr-r04.mx.aol.com[152.163.225.132]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:14:38 PDT reject: RCPT from omr-d06.mx.aol.com[205.188.156.71]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:14:51 PDT reject: RCPT from omr-r07.mx.aol.com[152.163.225.147]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:15:47 PDT reject: RCPT from omr-d05.mx.aol.com[205.188.156.66]: 550 [EMAIL PROTECTED]: User unknown; from=
Re: Broken PMTU (was: Who does source address validation? (was Re:what'sthat smell?))
On Thursday, 2002-10-10 at 00:55 ZE2, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: You can also get around this by making the first hop the one with the lowest MTU. This is no fun for ethernet-connected stuff, but for dial-up this is easy. Then this box will announce a smaller TCP MSS when the connection is established and there aren't any problems. Traffic consists of more than tcp; setting your mtu low might get your tcp traffic delivered but won't help inbound traffic using other protocols. Mtu discrepancies must be dealt with in at least one of the following ways if you don't want it to lead to fatally dropped packets: 1. Fragmentation must work. This applies to systems that don't use PMTUD or use blackhole detection. (Some folks think it a good security practice to drop fragments! Some nat boxes don't know what to do with fragments when they arrive out of order - especially a non-initial fragment before the first.) 2. PMTUD must work. 3. PMTUD blackhole detection must be used with operable fragmentation. (If you have to fallback to this you're likely to suffer significant performance hits.) Tony Rall
RE: per-packet load sharing in cef or dcef
sounds to me like a lab scenario. and while it may not be a good idea in a production network, it should still work. gonna try labbing it up as well. what code versions you running, Adam? Charles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Feger, James Sent: Thursday, October 10, 2002 6:18 AM To: Adam Atkinson Cc: [EMAIL PROTECTED] Subject: Re: per-packet load sharing in cef or dcef I am not sure what is happening for you, but as a general rule of thumb I don't run per-packet load sharing on circuits that are not 'the same'. The need for packet re-ordering goes way up when you are running per-packet on two types of circuit. Are the circuits provisioned for the same speed at least? -jf On Thu, 10 Oct 2002, Adam Atkinson wrote: per-packet load sharing in cef / dcef just doesn't seem to want to work. I have two 7500s joined by a frame relay link and a fast ethernet. Traffic is coming in to one of the 7500s via a third link, and goes to a loopback on the second 7500. I have cef turned on I have ip load-sharing per-packet on every interface The FR and FE have the same ospf cost The routing tables and sh ip cef agree that there are two equal paths to the loopback. But all the traffic goes over one link. I've been through Cisco troubleshooting documents etc. and as far as I can see, everything is perfect. Also, a deja search reveals plenty of other people with similar problems, and no solutions I can see. Are we all missing something obvious? -- Adam Atkinson
