Re: it was damp in belleview
On (2007-06-23 08:22 -1000), Randy Bush wrote: for those wishing historical perspective on route flap damping, document ripe-378 (may 2006) says i.e., it's time to turn it off. you are damaging your customers and others' customers. I've always thought that damping as an idea is a good one, but implementation is done horribly wrong. I want my customers to get best of the stable paths, i.e. I'd like to see method to dynamically worsen routes in path selection that are unstable, local-pref would be the obvious choice for me. -- ++ytti
Re: Thoughts on increasing MTUs on the internet
On (2007-04-12 11:20 +0200), Iljitsch van Beijnum wrote: What do you guys think about a mechanism that allows hosts and routers on a subnet to automatically discover the MTU they can use towards other systems on the same subnet, so that: 1. It's no longer necessary to limit the subnet MTU to that of the least capable system 2. It's no longer necessary to manage 1500 byte+ MTUs manually To me this sounds adding complexity for rather small pay-off. And then we'd have to ask IXP people, would the enable this feature if it was available? If so, why don't they offer high MTU VLAN today? And in the end, pay-off of larger MTU is quite small, perhaps some interrupts are saved but not sure how relevant that is in poll() based NIC drivers. Of course bigger pay-off would be that users could use tunneling and still offer 1500 to LAN. IXP peeps, why are you not offering high MTU VLAN option? From my point of view, this is biggest reason why we today generally don't have higher end-to-end MTU. I know that some IXPs do, eg. NetNOD but generally it's not offered even though many users would opt to use it. Thanks, -- ++ytti
Re: Thoughts on increasing MTUs on the internet
On (2007-04-12 16:28 +0200), Iljitsch van Beijnum wrote: On 12-apr-2007, at 16:04, Gian Constantine wrote: I agree. The throughput gains are small. You're talking about a difference between a 4% header overhead versus a 1% header overhead (for TCP). 6% including ethernet overhead and assuming the very common TCP timestamp option. Out of curiosity how is this calculated? [EMAIL PROTECTED] ~]% echo 1450/(1+7+6+6+2+1500+4+12)*100|bc -l 94.27828348504551365400 [EMAIL PROTECTED] ~]% echo 8950/(1+7+6+6+2+9000+4+12)*100|bc -l 99.02633325957070148200 [EMAIL PROTECTED] ~]% I calculated less than 5% from 1500 to 9000, with ethernet and adding TCP timestamp. What did I miss? Or compared without tcp timestamp and 1500 to 4470. [EMAIL PROTECTED] ~]% echo 1460/(1+7+6+6+2+1500+4+12)*100|bc -l 94.92847854356306892000 [EMAIL PROTECTED] ~]% echo 4410/(1+7+6+6+2+4470+4+12)*100|bc -l 97.82608695652173913000 Less than 3%. However, I don't think it's relevant if it's 1% or 10%, bigger benefit would be to give 1500 end-to-end, even with eg. ipsec to the office. -- ++ytti
Re: Thoughts on increasing MTUs on the internet
Or compared without tcp timestamp and 1500 to 4470. [EMAIL PROTECTED] ~]% echo 1460/(1+7+6+6+2+1500+4+12)*100|bc -l 94.92847854356306892000 [EMAIL PROTECTED] ~]% echo 4410/(1+7+6+6+2+4470+4+12)*100|bc -l 97.82608695652173913000 Apparently 70-40 is too hard for me. [EMAIL PROTECTED] ~]% echo 4430/(1+7+6+6+2+4470+4+12)*100|bc -l 98.26974267968056787900 so ~3.3% -- ++ytti
Re: Thoughts on increasing MTUs on the internet
On (2007-04-12 19:51 +0200), Iljitsch van Beijnum wrote: 8 bytes preamble 14 bytes ethernet II header 20 bytes IP header 20 bytes TCP header 12 bytes timestamp option 4 bytes FCS/CRC 12 bytes equivalent inter frame gap 90 bytes total overhead, 52 deducted from the ethernet payload, 38 added to it. 90 / (1500 - 52 = 1448) * 100 = 6.21 90 / (9000 - 52 = 8948) * 100 = 1 Also note that the real overhead is much bigger because for every two full size TCP packets an ACK is sent so that adds 90 bytes per 2 data packets, or increases the overhead to 9% / 1.5%. Aren't you double penalizing? Should it be: [EMAIL PROTECTED] ~]% echo 90 / (1500+38) * 100|bc -l 5.85175552665799739900 Or other way to say it: [EMAIL PROTECTED] ~]% echo 100-(1448/(1+7+6+6+2+1500+4+12)*100)|bc -l 5.8517555266579974 -- ++ytti
Re: Thoughts on increasing MTUs on the internet
On (2007-04-13 00:17 +0100), Will Hargrave wrote: At LONAP a jumbo frames peering vlan is on the 'to investigate' list. I am not sure if there is that much interest though. Another vlan, another SVI, another peering session... Why another? For neighbours that are willing to peer over eg. VLAN MTU 9k, peer with them only over that VLAN. I don't see much point peering over both VLANs. What I remember discussing with unnamed european IXP staff was that they were worried about loosing 'frame too big' counters. Since of course then the switch environment would accept bigger frames even on the 1500 MTU VLAN. And if member misconfigures the small MTU VLAN, and calls to IXP complaining how IXP is dropping their frames (due to sending over 1500bytes) IXP staff can't quickly diagnose the problem from interface counters. I argued that it's mostly irrelevant, since IXP staff can ping from IXP 'small mtu VLAN' the customer they're suspecting sending too large frames, and confirm this if router replies to a ping over 1500 bytes. But then again, I have 0 operational experience running IXP and it's easy for me to oversimplify the issue. The fabric itself is enabled to 9216 bytes; we have several members exchanging L2TP DSL traffic at higher MTUs but this is currently done over private (i.e. member addressed) vlans. This I believe to be biggest gain, tunneling, eg. ability to run IPSec site-to-site while providing full 1500bytes to LAN. There are some other possible IX applications... MPLS springs to mind as another network technology which requires at least baby giants; what would providers use this for? Handoff of multiprovider l2/l3 VPNs? The other technology which sees people deploying jumbos out there is storage. Selling storage as well as transit over the IX? It could happen :-) -- Will Hargrave [EMAIL PROTECTED] Technical Director LONAP Ltd -- ++ytti
Re: Thoughts on increasing MTUs on the internet
On (2007-04-12 20:00 -0700), Stephen Satchell wrote: From a practical side, the cost of developing, qualifying, and selling new chipsets to handle jumbo packets would jack up the cost of inside equipment. What is the payback? How much money do you save going to jumbo packets? It's rather hard to find ethernet gear operators could imagine using in peering or core that do not support +9k MTU's. -- ++ytti
Re: Google wants to be your Internet
On (2007-01-23 12:25 -0500), Jamie Bowden wrote: Virginia Power replaced our meter over the summer with a new one that has wireless on it. The meter reader just drives a truck past the houses and grabs the data without him/her ever leaving the truck. I have no idea what protocol they're using, or if it's even remotely secure. We have it here too, few times there has been articles in the newspaper about car alarms going off along the street, when the meters are read :). -- ++ytti
Re: Lucent GBE (4 x VC4) clues needed
Consider this topology GSR - 3750 --(GE over 4xVC4) - NSE100 - NSE100 --(GE over 4xVC4) -- 3550 - GSR This should have been Nortel GBE, not Lucent my bad. My first best guess was right, it was lucent system after all. We've now solved the issue, problem is in GBE card in Lucent in hardware revision S1:7, which is broken by design. S1:3, S1:6 work and we should be able to test S1:8 soon, but we expect it to work also. Symptoms were that it flipped bits (but not randomly, just couldn't figure out why certain places saw bit flips) and calculated new, correct CRC to the ethernet frame, after it had flipped bit. -- ++ytti
Re: Lucent GBE (4 x VC4) clues needed
On (2007-09-21 16:12 +0300), Saku Ytti wrote: (oops technical question in nanog, wearing my asbestos suit) Consider this topology GSR - 3750 --(GE over 4xVC4) - NSE100 - NSE100 --(GE over 4xVC4) -- 3550 - GSR This should have been Nortel GBE, not Lucent my bad. Anyhow, just wanted for sake of archive report that it's the Nortel 4xVC4 that corrupts packets, it mostly seems to corrupt source MAC and always same bits, that is, any L2 will learn mostly same MAC with few different vendor codes, we can also see this in wireshark on fibresplitter. (It's not limited strictly to source MAC, but it's not random by any means) It's not broken hardware (unless by design), as it can be seen in both of the production legs and we've recreated the same problem in lab. Most likely software issue in Nortel. -- ++ytti
Lucent GBE (4 x VC4) clues needed
(oops technical question in nanog, wearing my asbestos suit) Consider this topology GSR - 3750 --(GE over 4xVC4) - NSE100 - NSE100 --(GE over 4xVC4) -- 3550 - GSR All other fibres are dark fibres, except marked. When we ping either NSE100 - GSR leg, when there is no background traffic there is no packet loss. If there is even few Mbps, lets say 10Mbps of background traffic we get 1-5% packet loss on 1500 bytes, and bit less packet loss on small packets. As background traffic increases packet loss quickly increases. We tried to replace (GSR-3750) with 7600, but same issue persisted. We've measured both Lucent GBE legs with having loop in other end and pushing tests from EXFO and Smartbits gear through the loop, no errors can be detected in RFC tests. There isn't very much that can be configured in the Lucent, and we've tried pretty much every setting. We've tried to set autonego on and off in every gear in the path, without any changes to observed behaviour. We've also tried to use use 1xVC4, without any changes to the behaviour. All VC4's in given leg are using same path. Even though we test the packet loss pinging from router link to router link, same packet loss is experienced for transit traffic also. We've tried to turn PXF off in NSE100. Packets between NSE100 - NSE100 over dark fibre are not lost. We're pretty much utterly without clues. All I can think off is some obscure IFG issue, that is, NSE100 would have less than perfect timing for IFG which would confuse Lucent regarding what is part of which frame. Does stuff like this really happen? NSE100 drops bad IP packets in PXF and there is only shared counter, so I can't tell if I get CRC for IP, I just loose the packets. But IS-IS is not handled in PXF, and I get %CLNS-4-LSPCKSUM and %CLNS-3-BADPACKET messages over both Lucent legs, but not between the NSE100's. So I assume the packets are not dropped, but broken. I swear next time I'll complain about some political issue, thanks, -- ++ytti
Re: Lucent GBE (4 x VC4) clues needed
On (2006-09-21 06:32 -0700), David Temkin wrote: traffic also. We've tried to turn PXF off in NSE100. Packets Silly question (considering that you stated that IS-IS is borked also, which is not handled by PXF - but did you try disabling PXF? Not silly question at all, it was just longer mail that many people care to read (including me). There's a reason why Cisco discontinued every product that features it. It's broken. It's not broken, it's just ciscos name for NPU, two PXF's doesn't mean they have anything in common, apart being NPU. In essence, CRS-1 uses NPU's afaik, of course cisco doesn't call them PXF, due to bad publicity. Cooler word for NPU style design is probably cell processor, makes me feel warm already about my NSE100's. Yes, you can design broken NPU, NSE-1 was good example of that :). Thanks, -- ++ytti
Re: Lucent GBE (4 x VC4) clues needed
On (2006-09-21 18:49 +0100), Sam Stickland wrote: Did you try power cycling the Lucents after changing the auto-neg settings? I've seen some broken autoneg implementations in the past on managed media converters that didn't change settings immediately. It's worth a shot as you seem to be all out of other ideas ;) I brought the adjacent ports in IP gear down and up. We could verify from management interface to the lucent that autonegotiation wasn't performed after down/up, while we could observe before down/up that autonegotiation was marked being done even though we had configure cisoc interfaces as 'force-up'. So clearly it needed to see link down/up. We didn't powercycle lucent, as it would mean bringing down tens of 10G waves. But taking the GBE module out/in would have been option (three countries are involved, so bit inconvenient, but possible). Country A - Country B is one lucent leg. Country B - Country C is another lucent leg. Anyhow thanks for the thoughts, any help I can get is much appreciated :). Of course we have full support agreement to both vendors, which we probably have to try sooner or later, but it'll be long battle on who's problem it really is. -- ++ytti
Re: Market Share of broadband provider in Scandidavia
On (2006-09-08 18:03 +0200), Mikael Abrahamsson wrote: Could anyone point me to a market-share by-country overview of broadband provider in Scandinavia (Denmark, Sweden, Norway, Finland, Iceland). Any help would be appreciated. For Sweden, you can go to www.pts.se, more exactly http://www.pts.se/Sidor/sida.asp?Sectionid=1341Itemid=Languageid=EN. For Finland, from ~same govertment body: http://www.ficora.fi/englanti/tele/marketreview.htm Or direct URL to the PDF itself: http://www.ficora.fi/englanti/document/Markkinakatsaus_2_2006_EN.pdf Page 9 should answer your question. -- ++ytti
Re: Deaggregation Disease
On (2006-07-21 10:48 -0400), Joe Abley wrote: As it happens, Tony Li, Rex Fernando and I wrote up a proposal for a new attribute which might help in some of these situations. (It's a crude mechanism, but not as crude as NO_EXPORT). http://www.ietf.org/internet-drafts/draft-ietf-idr-as- pathlimit-02.txt I'm sure I'm not first one to to think about 'TTL' to AS hops (http://www.merit.edu/mail.archives/nanog/2002-10/msg00394.html), of course different reason at that time :). Other thing I was thinking about was ability to have include/exclude AS#'s community/attribute. -- ++ytti
Re: Deaggregation Disease
On (2006-07-21 11:38 -0400), Joe Abley wrote: That seems to me like another perfectly valid approach, and one that already exists to some extent (e.g. by pre-poisoning AS_PATH attributes with AS numbers of remote networks that you don't want to accept particular routes). I'm told that IDRP has inclusion and exclusion lists which provide more exhaustive implementation of this kind of idea, too. Oh, cool idea, indeed 'as exclude' mechanism is there, but I'm sure I'd be frowned upon advertising such routes today. 'as include' otoh. is not there. However, for some applications those mechanisms rely on knowing the topology one or more AS hops away from your network; AS_PATHLIMIT doesn't. To my eye the two approaches seem complementary. Absolutely complementary. The 'original' problem I was thinking, really needed both, as point was to find how 'deep' in Internet your DoS sources are, then as you've indentified the depth, you have smaller subset of AS#'s that you could iterate with include/exclude to pinpoint source of certain traffic, even if they were spoofing. But that idea has several problems that might make it unfeasible, nevertheless the traffic engineering applications remain. [To be clear, incidentally, Tomy, Rex and I made no claim to be the original authors of the idea we were documenting in this draft: ACK, I did notice that, I'm sure most people have thought about it at one point or another in their networking career :). I hope it'll be implemented. Thanks, -- ++ytti
Re: Cisco 3550 replacement
On (2006-02-20 21:54 -0600), [EMAIL PROTECTED] wrote: Reality Check: 32Gbps Backplane (Counted packet-in, packet-out, each direction, with all packets the same size, multicast?) and 52 GE interfaces. Not exactly non-blocking. Gotsta do the CiscoMath. And no hierarchial QoS, which was requirement of the original poster, of course 3550 offer no such either. ;-) On Mon, 20 Feb 2006, Jean-Francois Vaillancourt wrote: Check out the Cisco 3560 with IP Services software: http://www.cisco.com/en/US/products/hw/switches/ps5528/index.html it's basically a less expensive version of the 3750, without the external 32 Gbps stack connection. Anything the 3550 did it does, faster. ...and with 52 GigE ports, instead of 4. -Bill -- ++ytti
Re: Leap second reminder
On (2005-12-31 17:18 -0500), Deepak Jain wrote: Linux seemed to survive happily too [EMAIL PROTECTED] ~]% dmesg|tail -n1 Clock: inserting leap second 23:59:60 UTC Curious though that not so many people who've I asked got these messages, only explanation I can think of is that their NTP peers weren't telling it. Without much NTP clues, could someone explain what steps NTP takes to protect itself from attackers spoofing packets and forcing you to leap? Probably sane implementation would restrict leaping to happen only at 23:59:59, so you'd drift maximum of 1s/d? But crappy implementation might allow you to leap every second. This http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN2950 just tells Most users of NTP do not need authentication as the protocol contains several filters against bad time. So I guess it's pretty implementation spesific how the input is sanitized. Cisco seems happy as well. (adding leap second, leap second occurs at), etc. sh ntp status Clock is synchronized (adding leap second), stratum 2, reference is xxx.xxx.xxx.xxx nominal freq is 250. Hz, actual freq is 249.9975 Hz, precision is 2**18 reference time is C7617E39.3A0B3D8C (17:01:29.226 EST Sat Dec 31 2005) clock offset is 0.5332 msec, root delay is 5.11 msec root dispersion is 7.72 msec, peer dispersion is 7.14 msec Leap second occurs at C7619A00. (19:00:00.000 EST Sat Dec 31 2005) Happy New Year! Deepak Gerry Boudreaux wrote: On Dec 31, 2005, at 11:58 AM, Kevin Day wrote: Just a reminder, at midnight UTC there's a leap second added to most time systems. Some time systems will stop the clock at 23:59:59.99 for 1 second, some will display 23:59:60 for a second. Since the last leap second (1998), leap second aware time keeping systems(NTP, GPS, etc) have become much more prevalent, so it's much more likely this time that applications and NTP sync'ed devices will see a leap second happen(rather than have them manually corrected later, or not corrected at all). But, I'm not too sure how well everyone has tested applications and devices for how they handle the clock stopping for a second OR an invalid time of 23:59:60. If anyone sees anything die at 00:00:00UTC I'd be interested to know. -- Kevin My Juniper seems to be aware: [EMAIL PROTECTED] show ntp status status=4694 leap_add_sec, sync_ntp, 9 events, event_peer/strat_chg, version=ntpd 4.1.0-a Thu Jul 14 23:46:40 GMT 2005 (1), processor=i386, system=JUNOS7.3R1.5, leap=01, stratum=3, precision=-30, rootdelay=40.669, rootdispersion=49.522, peer=35302, refid=ntpx.xxx.xxx, reftime=c7615c1c.65f78359 Sat, Dec 31 2005 13:35:56.398, poll=10, clock=c7615d8e.d66d698f Sat, Dec 31 2005 13:42:06.837, state=4, offset=-2.649, frequency=73.810, jitter=5.194, stability=0.024 note the leap=01 and leap_add_sec -- ++ytti
Box with (H)VPLS hub+spoke (martini EoMPLS) support in the market?
Hey, Could someone please point me out if there is already boxes that support acting as (H)VLPS HUB's for Martini EoMPLS spokes, with VLAN rewrite? Hopefully this helps more than hurts: L2_cust--L2--PE1---EoMPLS-+ | L2_cust--L2--PE2---EoMPLSPE4-L2-L3_Cust_Router | L2_cust--L2--PE3---EoMPLS-+ PE4 would be running (H)VPLS aggregating the EoMPLS + native L2 to single broadcast domain. L2_custs would need to take round-trip via L3_Cust_Router to reach each other (so local-proxy-arp). PE1-PE3 would be running plain old martini EoMPLS without any MAC knownledge, they could be running on different VLAN, which PE4 would then rewrite. Is there any box in market doing this yet? My top runners would be Timetra (now alcatel) and Riverstone 15[12]00. Thanks, -- ++ytti
Re: zotob - blocking tcp/445
On (2005-08-15 09:28 -1000), Randy Bush wrote: There are real solutions to the problem, which include monitoring the end-user traffic and do traffic steering for infected hosts to a web page thats helps solving their problem. for we who are under-clued, do you have a url for suggested tools and procedures? www.rommon.com, I'm confident there are others. And some people are using home-baked solutions. Probably plethora (and money) will be one of the bigger problems when deciding to implement this kind of solution. -- ++ytti
Re: IOS new architechture will be more vulnerable?
On (2005-08-03 06:24 -0400), Joe Maimon wrote: But at the same time, now that I think they already are, I will say it's not as bad as you probably think it is. Not yet ... because the version that makes this an unstoppable critical problem is not out yet. What exactly does this mean? You might want to read lynn-cisco.pdf. This means that today to exploit heap overflows you need to know the offsets per release, supposedly tomorrow the offsets will be static per releasese in new (in some terms better) architecture, which will make exploiting heap overflows much more feasible. -- ++ytti
Re: OT: Cisco.com password reset.
On (2005-08-03 09:02 -0500), Church, Chuck wrote: I eventually got an email stating it couldn't associate my email address with an active CCO ID. I'm guessing their system is getting backed up because it's affecting lots of people. Next step: Send three times from mutt, and got same complainment about non-existing account, tried fourth time with mail and that worked, perhaps coincidence. Might be that the backend is just highly loaded, and the account poller script doesn't cope too well with error message or zero answer from backend. Please email [EMAIL PROTECTED] to have your correct email address associated with your User ID. To ensure you receive prompt attention, please provide all of the following details: 1 Maintenance contract or Account number you used in your registration 2 The user ID your believe you have 3 Full name 4 Company name Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design Implementation 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x4371A48D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Tancsa Sent: Wednesday, August 03, 2005 9:52 AM To: Dan Armstrong Cc: nanog@merit.edu Subject: Re: OT: Cisco.com password reset. Same here. I didnt get a notice that it was reset, but I cannot login ---Mike At 09:30 AM 03/08/2005, Dan Armstrong wrote: My PW to CCO did not work this morning either. I am on hold with the TAC right now Joe Blanchard wrote: FYI I got an email that my CCO account's password was reset last night. Not sure how widespread this issue was, but I called my account contact and verified that this is a valid email, and that my password needed to be reset. Just a heads up. -Joe Blanchard -- ++ytti
Re: eWeek: Cisco Comes Clean on Extent of IOS Flaw
http://www.eweek.com/article2/0,1759,1841669,00.asp Cisco still seems to be spinning it, though. The important part of Lynn's presentation wasn't the IPv6 exploit, but how future exploits can be used to execute arbitrary code on Cisco equipment. By making a big deal about the IPv6 exploit they are in effect trying to reassure people that run IPv4-only networks that this is not a big problem, and that it doesn't effect them. Important part of Lynn's presentation is that there will be buffer overflows and they can be exploited, this is vendor independent. And the threat was there 10 years ago and the threat will be there 10 years from now. Some people were also surprised by the 'late' ICMP 'vulnerabilities' and some even found time to bash $vendor about it. I guess someone has to yell wolf every now and then to interest people in maintaining their systems. -- ++ytti
Re: BCP regarding TOS transparancy for internet traffic
On (2005-05-25 11:49 -0400), [EMAIL PROTECTED] wrote: Out of curiosity, what did you hope to accomplish by zeroing that field? IMHO only reason not to zero TOS byte on AS ingress border is that you explicitly agreed with your neighbour how it is used (what traffic it can contain, what is the absolute limit they will send that traffic in, etc.) I personally don't want to see DoS traffic taking eg. VoIP priority. I've been also thinking about possibility to differentiate in MPLS EX/TOS AS internal and AS external traffic and under congestion start to drop AS external traffic first. (If you're planning to zero it on ingress to your network, use it for your own nefairious traffic-engineering purposes, and then re-zero on egress, *and* your contracts with your customers say it's OK to do it, then it might be defensible. Maybe. ;) -- ++ytti
Re: BCP regarding TOS transparancy for internet traffic
On (2005-05-25 14:15 -0400), [EMAIL PROTECTED] wrote: If you're seeing enough DoS traffic that an incorrect TOS is causing an issue for you, you probably need to find better ways to mitigate that traffic. Remember that at the *source* end, the DoS traffic is pretty minimal, and at the target end, I doubt that the TOS labelling will matter in the slightest We have lot of 256k, 512k, 1024k and 2048k customer. And we're taking multiple gigabits of traffic in our AS. How would you pick 256kbps of offending prec5 stream from that traffic and pick it immediately since the first packet, so that voice calls are not disturbed? The 256kbps can be even legal FTP transfer some clever kid decided to tag with prec5 since he noticed that he can get whole capacity with it. I'd recommend making sure that either the AS-external traffic isn't revenue-generating, or the AS-internal traffic generates more revenue than the external, or that the people who are generating the dropped traffic are a set of captive customers. ;) AS-internal is eg. MPLS-VPN and SIP to PSTN-GW, things that corporate business rely on, I don't care about dropping Internet in favor of keeping those services running. Congestion should not happen in our network, if it happens it's most probably intended network disturbance, -- ++ytti
Re: BCP regarding TOS transparancy for internet traffic
On (2005-05-25 14:44 -0400), Eric A. Hall wrote: 4) The default of no-modify should also apply to non-payinng customers since they may be flagging their packets for special processing on their own networks (and they don't want the flags to poof away when the traffic crosses your hop). Beatiful idea, how in practice do you suggest this is done, how will my router know if it should just ignore the TOS bytes or do expedited forwarding as configured for given value of TOS byte? In sum, premium packages are for expedited processing, which is what they are buying. Rewriting any packets without consent/request is not needed and unrelated, and is bad mojo in general. -- ++ytti
Re: BCP regarding TOS transparancy for internet traffic
On (2005-05-25 15:06 -0400), Eric A. Hall wrote: Beatiful idea, how in practice do you suggest this is done, how will my router know if it should just ignore the TOS bytes or do expedited forwarding as configured for given value of TOS byte? VLANs? Different route paths? Any of a dozen other ways to limit special processing to the networks that have paid for it and dump everybody else into the best-effort pool? Sorry I fail to understand this. Could you elaborate with an example? Let's assume I'm AS1 and 2.0.0.0/16 from AS2 is sending me DSCP CS5, which I don't want to honor. And 2.1.0.0/16 from AS2 is sending me DSCP CS5, which I want to honor. How in practice should I honour 2.0.0.0/16 to every destination in my network and never honor from 2.1.0.0/16 to any of destinations in my network? My margins unfortunately don't permit building two paths to each directions. -- ++ytti
Re: BCP regarding TOS transparancy for internet traffic
On (2005-05-25 11:16 -0700), Fred Baker wrote: I guess the question is why, just because you don't want to offer a specific service, you want to prevent other ISPs from offering a stated service to a user? There are some fairly good-sized ISPs offering services based on the TOS octet. Are you trying to drive users to them? Any customer that is setting EF on VoIP service is certainly expecting that to go end to end. The problem is opposite, because I want to offer differentiated services I want to rewrite the TOS byte. If I don't want to offer differentiated services myself I can leave it untouched. -- ++ytti
Re: snmp vuln
On (2004-04-21 23:24 -0700), Alexei Roudnev wrote: If you ever read SNMP specs, you can realize, that there is not any C or C++ SNMP implementation without such problem. So, rule number 1 is _never expose SNMP to Internet, and be careful to filter out any inbound packets, forwarded to your SNMP ports. Which makes me wonder, why in most implementations services listen in each configured address. Provider might have lot of link networks, even from customers demand from his link network. This makes filtering in borders little less feasible. And for this particular attack two way comminication is not needed, so SNMP with ACL is not enought to mitigate this. With explicitly defined listen addresses, filtering in border would be easy. JunOS allows to set interfaces to SNMP, but according to netstat it still listens in *.161. -- ++ytti
Re: attacking DDOS using BGP communities?
On (2002-10-18 00:15 -0400), John Fraizer wrote: 2) 'TTL' community. -just think about the amount of route-maps : Whoa. Decrementing a single community integer value while leaving others unchanged would seem to be a bit tricky. This would require much more work on the part of others than the first suggestion and I think it would attract far fewer participants for that matter. Actually would it matter if it wouldn't be additive change? Since it would be diagnostic/special case. But of course it would be trivial for the vendors to add support for changing the communities this way, if this could be performed as a additive change you could offer your customers automaticly partial visiblity under DOS attack until it's resolved rather than 0 visibility. Not to mention how much it would ease pinpointing faulty/aggressive parties thus in long run it could have very positive effect for things like proper anti-spoofing configurations. -- ++ytti
Re: attacking DDOS using BGP communities?
On (2002-10-18 04:13 -0400), John Fraizer wrote: You receive a prefix with the communities :1 :2 :3 and TTL-COMM:2. You need to decrement the TTL-COMM value while leaving the other 3 communities unchanged. Yes this would need change in IOS/JunOS but it wouldn't actually be hard to code this feature. But I still think it would be beneficial if green elves would configure it as non-additive change to all routers globally. Yes, you couldn't use it as offering partial visibility since it would most propably break few things here and there but it would increase your possibility in finding out which AS# is/are originating the attack. I'm just waiting for the green elves. But in the mean time, would anyone configure decrement of TTL-COMM if JunOS and IOS would magically start to support such feature in hopes of reaching some time large enough cover to actually do anything good. Unless *ALL* vendors change their code to compare AS-PATH length for prefixes against the TTL-COMM value, decrementing the value as the route is passed from peer to peer is the only way to make this work that I can think of. Doing that without nixing the other communities that may need to be passed as well becomes a serious challenge. Yes, it's quite optimistic and naive to think such concensus could be achieved when much more modest changes which would require global co-operation never happen. Heck, the route-map to do this without regard for other communities would still be pretty hairy. Am I missing something here? No, thanks for the comments. -- ++ytti
attacking DDOS using BGP communities?
How feasible would these ideas be? 1) Signaling unwanted traffic. You would set community which would just inform that you are receiving unwanted traffic. This way responsible AS# with statistical netflow could easily automaticly search for these networks and report to NOC if both there is increased traffic to them and community is on. -would it be affective at all? Could your netflow parser use it easily? +wouldn't need big changes 2) 'TTL' community. You would have ~10 communities representing how many AS hops until route should not be advertised anymore. If you would experience DOS you'd start from TTL 1 and increase until DOS flow starts again, with any luck you would end up having very limited amount of AS# to communicate with in hopes of fixing their anti-spoofing filters and to catch malicious party. -just think about the amount of route-maps : -you would need to flap the network possible 10 times == damped +some idea who to contact w/o co-operation of NOCs (can be hard) +wins you time, often DOS is over before you've reached 3rd AS number to ask where the traffic is originating. 3) 'null route' community. This would only be useful if it would mean that you are also accepting more spesific annoucement, preferally even /32. Most people are propably crying about the idea already, but if you plan it wisely with prefix-limit setting it might not be suicide. Just remember that all downstream prefix-limit+your prefices must be smaller than what your upstream has set for prefix-limit, if this is not done then your downstreams can effectively trigger your upstream prefix-limit killing your connectivity. How AS handles the 'null route' community could vary, others set next-hop to null0 other might set it to analyzer tool. Just that it shouldn't reach the other end anymore. -the obvious: explosion of global bgp routing table (no, not nececcarily) +effective, you'd instantly free your link from any DOS traffic to given destination. -- ++ytti
