Are any of you operators utilizing VLANs to/with your transit providers in order to isolate traffic types or services, and/or to assist in traffic shaping before it hits your transit connections (isolating the effects of DDoS's)? Would you be prepared to share experiences, do's/don'ts, gotcha's etc? Off-line responses would be fine, obviously - I don't want to add to any of the current noise.
On 11/13/07, Rodney Joffe <rjoffe@centergate.com> wrote:
Are any of you operators utilizing VLANs to/with your transit providers in order to isolate traffic types or services, and/or to assist in traffic shaping before it hits your transit connections (isolating the effects of DDoS's)?
There was once a customer at a past job that used a sacrificial T1 to do this... They'd just announce/next-hop the attacked thing to the T1 interface, apparently remembering that there was BHR community available (and config'd for them) was hard to do. Are you looking to save the traffic for a reason or would just junking it down a tiny pipe work? (send me only x bps don't squeeze out all of my pipe in the process, unless your vlan config also included bandwidth limits?) -Chris
On Tue, 13 Nov 2007, Christopher Morrow wrote: > There was once a customer at a past job that used a sacrificial T1 to > do this... They'd just announce/next-hop the attacked thing to the T1 > interface, apparently remembering that there was BHR community > available (and config'd for them) was hard to do. Zocalo didn't do this with UUNet, but did with several transit providers and peers who didn't have such communities. -Bill
On Nov 13, 2007, at 11:16 AM, Christopher Morrow wrote:
On 11/13/07, Rodney Joffe <rjoffe@centergate.com> wrote:
Are any of you operators utilizing VLANs to/with your transit providers in order to isolate traffic types or services, and/or to assist in traffic shaping before it hits your transit connections (isolating the effects of DDoS's)?
There was once a customer at a past job that used a sacrificial T1 to do this... They'd just announce/next-hop the attacked thing to the T1 interface, apparently remembering that there was BHR community available (and config'd for them) was hard to do.
Are you looking to save the traffic for a reason or would just junking it down a tiny pipe work? (send me only x bps don't squeeze out all of my pipe in the process, unless your vlan config also included bandwidth limits?)
I have too many services to just want to use a T1 or two as sacrificial pipes. and I don't want to be messing around manually. I need to be able to have the transit providers effectively provide isolation for each subnet, so my idea is to advertise each service up a separate rate-limited VLAN. So if one service is DDoS'd, and its 100mb vlan is hosed, the other 9 services still cope easily with each of their 100mb vlans. Seems simple and logical to me, but I wasn't sure what I was missing.
-Chris
I have too many services to just want to use a T1 or two as sacrificial pipes. and I don't want to be messing around manually.
I need to be able to have the transit providers effectively provide isolation for each subnet, so my idea is to advertise each service up a separate rate-limited VLAN. So if one service is DDoS'd, and its 100mb vlan is hosed, the other 9 services still cope easily with each of their 100mb vlans.
Seems simple and logical to me, but I wasn't sure what I was missing.
That most providers like to do everything the same way everywhere, as much as possible. The real problem is that you may not really looking for a "100mb vlan." Assuming you buy a 1Gbps pipe to FOOnet, and you're hoping for happy DDoS- resistant bandwidth sharing of various services, what you really need is something doing rate limiting. Having it come across as a vlan may actually be more complex, and may make it more difficult (not technically, because it is technically straightfoward-even-if-complex, but finding a provider who'll /sell/ it). The trick is that you don't want to fill up the pipe. That necessitates rate limiting on the provider's side. This is obvious (I hope.) Now, the question boils down to this: Will it be easier to get FOOnet to: 1) Install rate limits for specific address ranges in your space, or 2) Install vlans and then install rate limits on those interfaces? Depending on the equipment in question, it's possible that 1) isn't possible. However, if it /is/ possible, from a configuration point of view, it's probably going to look much more attractive to FOOnet than having this complicated glob of vlan/rate limiting stuff sitting on their router. But they may simply be unwilling. So, the usual solution to this issue is to simply recognize that FOOnet is going to have less of an issue selling you several 100Mbps circuits. You can probably get a bit of a break on XC's, etc. too. If you shop around long enough, at clueful providers, you may find someone willing to do the vlan thing. It's certainly an elegant thing for /you/ on /your/ side, but remember that the complexity is just being shoved off on someone who probably doesn't want it. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Wed, 14 Nov 2007, Rodney Joffe wrote:
I have too many services to just want to use a T1 or two as sacrificial pipes. and I don't want to be messing around manually.
I need to be able to have the transit providers effectively provide isolation for each subnet, so my idea is to advertise each service up a separate rate-limited VLAN. So if one service is DDoS'd, and its 100mb vlan is hosed, the other 9 services still cope easily with each of their 100mb vlans.
Seems simple and logical to me, but I wasn't sure what I was missing.
The trick isn't the classification part, but needing multiple hardware queues. If you have multiple hardware queues, it doesn't matter too much whether you use "virtual" things like MPLS, VLAN, DSCP, 802.1p, PVCs, etc. Most will work. If you don't have multiple hardware queues, then it also doesn't matter too much whether you use "virtual" things like MPLS, VLANs, DSCP, 802.1P, PVCs, etc. Most will not work. Providers use sacrifical physical interfaces, e.g. a T1, because some routers aren't very good at managing multiple queues on a single physical interface, and may not have multiple hardware queues on a single physical interface.
Sean Donelan wrote:
On Wed, 14 Nov 2007, Rodney Joffe wrote:
I have too many services to just want to use a T1 or two as sacrificial pipes. and I don't want to be messing around manually.
I need to be able to have the transit providers effectively provide isolation for each subnet, so my idea is to advertise each service up a separate rate-limited VLAN. So if one service is DDoS'd, and its 100mb vlan is hosed, the other 9 services still cope easily with each of their 100mb vlans.
Seems simple and logical to me, but I wasn't sure what I was missing.
The trick isn't the classification part, but needing multiple hardware queues. If you have multiple hardware queues, it doesn't matter too much whether you use "virtual" things like MPLS, VLAN, DSCP, 802.1p, PVCs, etc. Most will work.
If you don't have multiple hardware queues, then it also doesn't matter too much whether you use "virtual" things like MPLS, VLANs, DSCP, 802.1P, PVCs, etc. Most will not work.
Providers use sacrifical physical interfaces, e.g. a T1, because some routers aren't very good at managing multiple queues on a single physical interface, and may not have multiple hardware queues on a single physical interface.
These sacrificial interfaces don't have to go anywhere... as in, they can be an old router (or server) sitting all by itself talking to another router you care about. I personally prefer to use L3 switches that can use an ASIC to blackhole traffic at exceedingly high rates and accept/originate routing feeds, but YMMV. Deepak Jain AiNET
participants (6)
-
Bill Woodcock -
Christopher Morrow -
Deepak Jain -
Joe Greco -
Rodney Joffe -
Sean Donelan