If you're going with Extricom you don't need to worry about channel planning
beyond adding more channel blankets.
Frank
-Original Message-
From: Carl Karsten [mailto:[EMAIL PROTECTED]
Sent: Monday, November 12, 2007 10:56 PM
To: nanog@merit.edu
Cc: [EMAIL PROTECTED]; Adrian Chadd;
[EMAIL PROTECTED] (Frank Bulk) wrote:
If you're going with Extricom you don't need to worry about channel planning
beyond adding more channel blankets.
Is that based on marketing, theory (based on the whitepapers and patent
descriptions) or practical experience?
Elmar.
Elmar:
Marketing and theory -- I haven't had a chance to test it myself.
BTW, I'm not regurgitating Extricom's marketing rhetoric when I say you
don't need to worry about channel planning -- their product is designed with
that specifically in mind. The technical benefits and caveats of this
Hi there, I just had a real quick question. I hope this is found to be
on topic.
Is it to be expected to see rfc1918 src'd packets coming from transit carriers?
We have filters in place on our edge (obviously) but should we be seeing
traffic from 192.168.0.0 and 10.0.0.0 et cetera
On 13-Nov-2007, at 10:08, Drew Weaver wrote:
Hi there, I just had a real quick question. I hope this is
found to be on topic.
Is it to be expected to see rfc1918 src'd packets coming from
transit carriers?
You should not send packets with RFC1918 source or destination
They do. What you are seeing are probably forged packets. Nmap etc. all let
you forge SIP, in fact they automate it. One Nmap mode actually actively
obfuscates network scans by doing random SIPs--e.g. 10,000 random SIPs and one
real one--this makes it hard to figure out who is actually
On Tue, 13 Nov 2007, Drew Weaver wrote:
Hi there, I just had a real quick question. I hope this is found to be
on topic.
Is it to be expected to see rfc1918 src'd packets coming from transit
carriers?
I would recommend grilling your carriers to find out why they're not
dropping packets
Hi there, I just had a real quick question. I hope this is found to
be on topic.
Is it to be expected to see rfc1918 src'd packets coming from transit
carriers?
We have filters in place on our edge (obviously) but should we be seeing
traffic from 192.168.0.0 and 10.0.0.0 et
From [EMAIL PROTECTED] Tue Nov 13 09:12:04 2007
Cc: nanog@merit.edu nanog@merit.edu
From: Joe Abley [EMAIL PROTECTED]
To: Drew Weaver [EMAIL PROTECTED]
Subject: Re: General question on rfc1918
Date: Tue, 13 Nov 2007 10:10:26 -0500
On 13-Nov-2007, at 10:08, Drew Weaver wrote:
On 13-Nov-2007, at 10:35, Robert Bonomi wrote:
On 13-Nov-2007, at 10:08, Drew Weaver wrote:
Hi there, I just had a real quick question. I hope this is
found to be on topic.
Is it to be expected to see rfc1918 src'd packets coming from
transit carriers?
You should not send packets
On Tue, 13 Nov 2007, Drew Weaver wrote:
Hi there, I just had a real quick question. I hope this is found to be
on topic.
Is it to be expected to see rfc1918 src'd packets coming from transit
carriers?
I would recommend grilling your carriers to find out why they're not
dropping packets
On Tue, 13 Nov 2007, Drew Weaver wrote:
Is it to be expected to see rfc1918 src'd packets coming from transit carriers?
Yes. Any ISP which uses RFC1918 on internal links may generate
various ICMP error packets (e.g. traceroute/TTL expire, PMTU
discovery/Fragmentation required, etc) from
Joe Abley (jabley) writes:
You drop the packet at your border before it is sent out to the Internet.
This is why numbering interfaces in the data path of non-internal traffic is
a bad idea.
Unfortunately many providers have the bad habit of using RFC1918
for
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,
On 11/13/07, Rodney Joffe [EMAIL PROTECTED] 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
Frank Bulk wrote:
Foundry OEMs from Meru, which also uses a single-channel approach. It does
not have an L1 requirement.
Meru APs tunnel back to the controller, so any old L3 will do. We took an AP
home (just for grins) and it still worked back to our controller through
residential
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
This is probably just regional, but here in SE PA, I've had a few
customers who send their outgoing mail through smtp.comcast.net getting
internal queueing error.
Anybody find what it is or was and when/if it was fixed?
TIA,
James Smallacombe PlantageNet, Inc. CEO and
Hard-earned knowledge:
Meru's single-channel approach has some compatability issues with
certain drivers, most notably Lenovo laptops with the Atheros chipset.
If you decide to go that route, make sure you have a USB key lying
around with the latest drivers from the Lenovo site for the T60's
Also, some issues with Intel, too:
http://www.intel.com/support/wireless/wlan/sb/cs-006205.htm
http://listserv.educause.edu/cgi-bin/wa.exe?A2=ind0608L=wireless-lanD=1H=
1T=0P=5230
I know that this has been at least somewhat addressed, but I'm not sure if
they are fully addressed.
Regards,
Proposed new FCC rules for backup power sources for central offices, cell
sites, remote switches, digital loops, etc. For the first time, the FCC
is considering specific backup power time requirements of 24 hours for
central offices and 8 hours for outside plant and cell sites. Although
On Tue, Nov 13, 2007 at 03:07:03PM -0500, Sean Donelan wrote:
Proposed new FCC rules for backup power sources for central offices, cell
sites, remote switches, digital loops, etc. For the first time, the FCC
is considering specific backup power time requirements of 24 hours for
What? The gov't putting their nose in where it shouldn't be? NEVER!
-Mike
On Nov 13, 2007 1:00 PM, Wayne E. Bouchard [EMAIL PROTECTED] wrote:
On Tue, Nov 13, 2007 at 03:07:03PM -0500, Sean Donelan wrote:
Proposed new FCC rules for backup power sources for central offices, cell
One of the results of the changes is that there will probably be fewer
COs in the world of the future. They strictly speaking aren't required
as often as they used to be, and more and more infrastructure will be
deemed end-powered or outside plant anyway.
If everything goes fiber to the
On Tue, Nov 13, 2007 at 01:15:53PM -0800, Mike Lyon wrote:
What? The gov't putting their nose in where it shouldn't be? NEVER!
I must say, if you're a provider with US presence and you're not
paying attention to the FCC, DHS (NCS, NCSD) and possibly that thing called
NSTAC you may wake
I do find it very interesting with all of what has happened post 9/11.
Or maybe it's just more in the open now since then. But now we have
the gov't putting there noses into everything network related it
seems. For example, the Patriot Act (not saying this is good bad, i'll
leave my thoughts to
On Tue, 13 Nov 2007, Wayne E. Bouchard wrote:
On Tue, Nov 13, 2007 at 03:07:03PM -0500, Sean Donelan wrote:
Can you find the FCC proposed 24-hours of backup power at this CO after
Hurricane Katrina?
http://www.thecentraloffice.com/Katrina/lkctla.jpg
27 matches
Mail list logo
