I would suggest doing a VC with the TOR switches. That way you can
have "one" switch for a lot of racks (I believe 10 would be the upper
limit if using Juniper). If you have a VC you could do L3 and L2
where needed on every rack that the VC covers.
// Olof
2009/11/13 Łukasz Bromirski :
> On 2009
Well,
If it counts Paul, thanks for vixie cron. ;)
-Original Message-
From: Paul Vixie [mailto:vi...@isc.org]
Sent: Thursday, November 12, 2009 4:58 PM
To: na...@merit.edu
Subject: Re: What DNS Is Not
"Kevin Oberman" writes:
> I find it mildly amusing that my first contact with Pau
"Kevin Oberman" writes:
> I find it mildly amusing that my first contact with Paul was about 25
> years ago when he was at DEC and I objected to his use of a wildcard for
> dec.com.
I was only an egg.
> The situations are not parallel and the Internet was a very different
> animal in those days
Randy Bush wrote:
>> It has been routinely observed in nanog presentations that settlement
>> free providers by their nature miss a few prefixes that well connected
>> transit purchasing ISPs carry.
>
> just trying to understand what you mean,
>
> o no transit-free provider actually has all (
On 2009-11-12 22:37, David Coulson wrote:
The MX-series are pretty nice. That should be able to do VPLS PE,
however I've never tried it - MX240 did it pretty well last time I
tried. I've no clue how the cost of that switch compares to a cisco 4900
or something (not that a 4900 is anything specia
I believe TRILL will render this discussion moot. It should be shipping
on gear from various vendors within the next year.
-Original Message-
From: Malte von dem Hagen [mailto:m...@hosteurope.de]
Sent: Thursday, November 12, 2009 1:09 PM
To: Raj Singh
Cc: nanog@nanog.org
Subject: Re: L
I believe the issue will become a moot point in the next 12 months when
vendors begin to ship switches with TRILL.
TRILL is basically a layer 2 routing protocol that will replace spanning
tree. It will allow you to connect several uplinks, utilize all the
bandwidth of the uplinks, prevent loops,
Hi,
Am 12.11.2009 22:29 Uhr schrieb Jonathan Lassoff:
> Are there any applications that absolutely *have* to sit on the same
> LAN/broadcast domain and can't be configured to use unicast or multicast
> IP?
yes. There are at least some implementations of iSCSI and the accompanying
management servi
Jonathan Lassoff wrote:
I was recently looking into this (top-of-rack VPLS PE box). Doesn't seem
to be any obvious options, though the new Juniper MX80 sounds like it
can do this. It's 2 RU, and looks like it can take a DPC card or comes
in a fixed 48-port GigE variety.
The MX-series are pret
Excerpts from David Coulson's message of Thu Nov 12 13:07:35 -0800 2009:
> You could route /32s within your L3 environment, or maybe even leverage
> something like VPLS - Not sure of any TOR-level switches that MPLS
> pseudowire a port into a VPLS cloud though.
I was recently looking into this (
Raj Singh wrote:
We are actually looking at going Layer 3 all the way to the top of rack and make each rack its own /24. This provides us flexibility when doing maintenance (spanning-tree). Also, troubleshooting during outages is much easier by using common tools like ping and trace routes.
I'm c
Hej,
Am 12.11.2009 21:04 Uhr schrieb Raj Singh:
> We are actually looking at going Layer 3 all the way to the top of rack and
> make each rack its own /24.
what a waste of IPs and unnecessary loss of flexibility!
> This provides us flexibility when doing maintenance (spanning-tree).
If you use
Seth Mattinen wrote:
I'd always wondered how you make a subnet available across racks with L3
rack switching. It seems that you don't.
You could route /32s within your L3 environment, or maybe even leverage
something like VPLS - Not sure of any TOR-level switches that MPLS
pseudowire a port int
On 12/11/2009 20:40, Bulger, Tim wrote:
Slightly off-topic.. Consider offloading 100Mb connections like PDUs,
DRAC/iLO, etc. to lower cost switches to get the most out of your
premium ports.
Not just that, you can also use lower cost switches to move your management
fully out-of-band with resp
On Thu, Nov 12, 2009 at 2:40 PM, Bulger, Tim wrote:
> If you use stackable switches, you can stack across cabinets (up to 3 with
> 1 meter Cisco 3750 Stackwise), and uplink on the ends. It's a pretty solid
> layout if you plan your port needs properly based on NIC density and cabinet
> size, plu
* David Ulevitch:
> On 11/11/09 12:48 PM, Florian Weimer wrote:
>>> Since people need to *explicitly* choose using the OpenDNS servers, I
>>> can hardly see how anybody's wishes are foisted on these people.
>>>
>>> If you don't like the answers you get from this (free) service, you
>>> can of cour
If you use stackable switches, you can stack across cabinets (up to 3 with 1
meter Cisco 3750 Stackwise), and uplink on the ends. It's a pretty solid
layout if you plan your port needs properly based on NIC density and cabinet
size, plus you can cable cleanly to an adjacent cabinet's switch if
On Thu, Nov 12, 2009 at 12:19:36PM -0800, Seth Mattinen wrote:
>
> I'd always wondered how you make a subnet available across racks with L3
> rack switching. It seems that you don't.
>
> ~Seth
It's possible, with prior planning. You can have the uplinks be layer 2
trunks, with a layer 3 SVI in
Steve Feldman wrote:
>
> On Nov 12, 2009, at 2:48 PM, Raj Singh wrote:
>
>> Guys,
>>
>> I am wondering how many of you are doing layer 3 to top of rack
>> switches and what the pros and cons are. Also, if you are doing layer
>> 3 to top of rack do you guys have any links to published white paper
We are actually looking at going Layer 3 all the way to the top of rack and
make each rack its own /24. This provides us flexibility when doing maintenance
(spanning-tree). Also, troubleshooting during outages is much easier by using
common tools like ping and trace routes.
I want to make sure
On Nov 12, 2009, at 2:48 PM, Raj Singh wrote:
Guys,
I am wondering how many of you are doing layer 3 to top of rack
switches and what the pros and cons are. Also, if you are doing
layer 3 to top of rack do you guys have any links to published
white papers on it?
Dani Roisman gave an e
We are heading towards that type of deployment beginning next year with
Juniper EX4200 switches in a redundant configuration. This will be pure
Layer2 in nature on the switches and they will "uplink" to Juniper
M10i's for layer3... the power savings, space savings etc over
traditional Cisco 6500 c
Guys,
I am wondering how many of you are doing layer 3 to top of rack switches and
what the pros and cons are. Also, if you are doing layer 3 to top of rack do
you guys have any links to published white papers on it?
Thanks,
Raj Singh
On Wed, Nov 11, 2009 at 11:18:20AM -0800, Steve Gibbard wrote:
> If you have three components, the chances of all three being broken at
> once are even less than the chances of two of them being broken at
> once. With four, you're even safer, and so on and so forth. But once
> you get beyond two,
We've been getting more and more requests for ESPN360 from our
customers. From what i understand, ESPN requires that the ISP
"subscribe" to their content and pay a fee to do so. I have been unable
to find much information on what it takes to subscribe and what the fees
are to do so. Does anyone
> Following on, the best way is to 'trust' on all uplinks between devices
> and filter at the edge. So you have a customer who shouldn't be sending
> tagged traffic, set the port to not trusted (should be the default
> state) and any customer using QoS should have "mls qos trust dscp" on
> the dema
Christian Seitz wrote:
There ist also a loose and a strict filter recommendation by Gert Doering [1],
but the strict filter is very strict at the moment. It allows only /48s from
RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also
assignes /47 or /46 from this range. Also
All,
This may not be the right audience but I do not know of a better set of experts
to ask this question.
We monitor antivirus and spyware activity very close on our desktop and laptop
environment. Often you can correlate this activity with an increase in
bandwidth. The bandwidth is not an is
Following on, the best way is to 'trust' on all uplinks between devices
and filter at the edge. So you have a customer who shouldn't be sending
tagged traffic, set the port to not trusted (should be the default
state) and any customer using QoS should have "mls qos trust dscp" on
the demark port.
Look at "show mls qos map" to see the defaults that may be rewriting
your information depending on trust (or non-trust) mechanisms you have
configured.
If you trust CoS, a frame received with cos5 and dscp46 will get
rewritten to dscp 40 with default maps...
"show mls qos interface (intf)" is als
hello
indeed, a fellow nanoger gave me this hint.
1. i had to enable mls qos globally in "network" switches
2. set the mls qos trust dscp on the uplinks (ingress port)
thanks
ps thanks to andrey.gordon too :)
On 11/12/2009 03:21 PM, Brian Feeny wrote:
>
> You should make sure that any li
KDDI, NTT, and WIDE are all on or adjacent to LAIIX.
if you hit those, your pretty much covered.
--bill
On Wed, Nov 11, 2009 at 12:34:24PM -0800, Operations wrote:
> Greetings,
>
> Im sure someone here is GREAT with connecting to Japan so I ask the
> following:
>
>
> We have a POP in 600 W
You should make sure that any links that go between devices have trust
set. In your case if your doing DSCP,
then make sure each link that goes between devices which must carry
tagged packets have trust dscp set.
Brian
On Nov 12, 2009, at 5:11 AM, Bogdan wrote:
hello
i am playing with
> On second thoughts, thinking about this I am probably looking for some
> kind of Layer2 encryption devices. This will make things a lot easier
> for the deployment. Any experiences, thoughts on these types of devices,
> would be much appreciated.
You could use OpenVPN, but that would be chea
hello
i am playing with qos on some devices
- cisco 3560
- cisco 7609
and i have some things that i don't seem to understand.
1. in 3560, i enable mls qos, on the ingress port applyed policy map,
classify the packets with acl, mark, all good. on the egress ports i use
srr-queue with shape/share,
* a...@baklawasecrets.com
> - I could ask the question as to whether I can peer with separate
> routers on each of the upstreams. i.e. to protect against router
> failures on their side.
If you're getting transit from two different upstreams, you're pretty
much guaranteed to be connected to two
36 matches
Mail list logo
