RE: as702 looking glass?

[John van Oppen]

No BGP looking glass but there is a traceroute gateway in AS702:

http://zelfservice.nl.uu.net/netwerk/pops/trace.uunet


John van Oppen
Spectrum Networks LLC
Direct: 206.973.8302
Main: 206.973.8300
Website: http://spectrumnetworks.us


-Original Message-
From: R. Scott Evans [mailto:na...@rsle.net] 
Sent: Friday, September 04, 2009 12:21 PM
To: nanog@nanog.org
Subject: Re: as702 looking glass?

On Fri, 4 Sep 2009 13:38:56 +0400 (MSD), Serg Shubenkov wrote
> Folks,
> 
> Does anyone know if Verizon (AS702) has a publicly accessable looking
> glass?
> 
> -- 
> Serg Shubenkov

it's been 2 years since I last inquired, but the answer then was:

"Date: Fri, 17 Aug 2007 17:37:09 + (GMT)
From: hel...@verizonbusiness.com
Subject: (2007081704481) BGP routes

Hi there,
I am afraid we do not have a public looking glass..."

[NANOG-announce] 2009 NANOG charter amendments

[Steve Feldman]

The NANOG charter is the document which governs the operation of  
NANOG, and the relationship between the community and NANOG's hosting  
organization, Merit Network.  The current text is at 
http://www.nanog.org/governance/charter/ 
.

During the NANOG annual election, voters are given the opportunity to  
decide on amendments to the NANOG charter.  Typically, the amendment  
process has been used to remedy oversights, modify processes with the  
benefit of experience, and to correct and tighten language.   This  
year, the election is being held during the NANOG meeting October  
18-21 in Dearborn, MI.

There are two ways to put an amendment on the ballot:

- Vote by a majority of the Steering Committee

- A petition signed by at least 30 eligible voters,
  and submitted by September 28, 2009.

See 
http://www.nanog.org/governance/elections/2009elections/2009charteramend.php 
  for more details on the process.  As amendments are proposed, they  
will be added to that page.

If you have any suggestions for amendments, or would like to comment  
on NANOG governance in general, please join the discussion on the  
nanog-futures list, or contact the Steering Committee or any of its  
members directly.

Steve Feldman
(for the Steering Committee)


___
NANOG-announce mailing list
nanog-annou...@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Repeated Blacklisting / IP reputation

[Scott Weeks]

--- leo.veg...@icann.org wrote:
In my limited experience, requesting address space from ARIN involved
describing what I would be doing with it. YMMV.
-


That's the easy part of the process.  Proof of what you did with what you 
already have assigned to you is the hard part.

scott

Re: Repeated Blacklisting / IP reputation

[Leo Vegoda]

On 09/09/2009 8:48, "Mark Andrews"  wrote:

[...]

> What a load of rubbish.  How is ARIN or any RIR/LIR supposed to
> know the intent of use?

In my limited experience, requesting address space from ARIN involved
describing what I would be doing with it. YMMV.

Leo 

FOSS WAN Acceleration Software

[BH]

Hello,
I was wondering if anyone had experience or could recommend free open source
WAN Accelerators/Optimizers. There seems to be only one FOSS project called
TrafficSqueezer but development has stopped and the project is still in an
Alpha stage.

I am not interested in the offerings of Cisco (WAAS) or Riverbed (StealHead)
or any other appliance based solution.

Thank-you in advance for any and all replies.

-- 
BH

Re: WS-X6148A-GE-TX performance question

[Nick Hilliard]

On 10/09/2009 22:17, Scott Spencer wrote:

I can't really find anything much on X6148A internal architecture online,
but it would seem that each port gets its own 1gb/s link to the
card/backplane, and that the bottleneck then is the 32gb/s backplane (which
is fine, as long as it's not 1 gb/s per each set of 8 ports!).


Sadly, it is 1Gb per each set of 8 ports.  The WS-X6148-GE-TX line card 
has its uses, just not in the data center.  To recap on the thread a 
couple of weeks ago:


- no storm control
- no port security
- 1G aggregate traffic for each group of 8 ports (i.e. think of it as 6 
x gigabit ethernet hubs with shared input buffers connected into a 32G 
backplane)

- 2 ports per etherchannel

It's not a service provider blade and doesn't belong in a data center 
switch setup.  Don't be disappointed by this: it was designed to be an 
aggregation blade for enterprise desktop usage and is quite useful in 
that context.


Nick

Re: BGP Confederation over Route Reflector

[Michael Hallgren]

Le jeudi 10 septembre 2009 à 11:20 -0600, Jason Iannone a écrit :
> I would say confeds are more appropriate for larger ibgp networks.
> You can have reflectors inside confederations.  See the BGP chapter of
> the JNCIP book.

I'd say, the choice is much dependent on the "political" topology within
your AS. The more inter-regional routing policing you feel that you
need, the more you'd be looking at a confed. architecture.  

mh

> 
> On Thu, Sep 10, 2009 at 9:33 AM, Buraglio, Nicholas D
>  wrote:
> > Lots of things can be used to determine how you decide to set up your
> > BGP peers.  
> > https://www.juniper.net/customers/csc/documentation/techdocs/downloads/pdf/350010.pdf
> >  has a decent amount of information on some of the differences that
> > can help you decide how to set up your peerings.
> >
> > nb
> >
> > ---
> > Nick Buraglio
> > Network Engineer, CITES, University of Illinois
> > GPG key 0x2E5B44F4
> > Phone: 217.244.6428
> > burag...@illinois.edu
> >
> > On Sep 9, 2009, at 9:52 PM, devang patel wrote:
> >
> >> Hello,
> >> What are the advantages of BGP Confederation over Route Reflector? I
> >> mean
> >> when one should decide to deploy BGP Confederation over Route
> >> Reflector
> >> deployment?
> >>
> >> Thanks,
> >> Devang Patel
> >>
> >
> >
> >
> 
-- 
michael hallgren, mh2198-ripe

RE: WS-X6148A-GE-TX performance question

[Holmes,David A]

Cisco recommends both cards for access-layer use, principally as wiring
closet aggregation for desktop users. Cisco recommends 65xx or 67xx line
cards for backbone (read deterministic) connections, which means that
only 65xx devices with sup720s, or older switch fabric modules can be
used for deterministic network design. 

Note that Etherchannel limitations apply to both cards. Also running one
port in a group of 8 at line rate ( for example using that port as a
SPAN destination for a VLAN where traffic exceeds 1 Gbps) will cause
drops on the other ports in the group.

(see
http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a
0080094714.shtml ) 

-Original Message-
From: Crooks, Sam [mailto:sam.cro...@experian.com] 
Sent: Thursday, September 10, 2009 2:59 PM
To: Bill Blackford; Scott Spencer
Cc: nanog@nanog.org
Subject: RE: WS-X6148A-GE-TX performance question

the other difference between WS-X6148-GE-TX and WS-X6148A-GE-TX is the A
has better QoS queuing potential (more hardware queues available) and a
lower list price...

As I recall, there are 6 ethernet controllers with 8 ports on each...
(8:1 oversubscription among the adjacent ports in a port group which use
the same ethernet controller).

The card is a Classic card, so the whole card is limited to 32 Gbps to
the backplane, which given the oversubscription ratio, shouldn't be much
of an issue...



> -Original Message-
> From: Bill Blackford [mailto:bblackf...@gmail.com] 
> Sent: Thursday, September 10, 2009 4:40 PM
> To: Scott Spencer
> Cc: nanog@nanog.org
> Subject: Re: WS-X6148A-GE-TX performance question
> 
> There was a good thread on Cisco-nsp regarding this exact 
> subject recently.
> My recollection is that both X6148 and X6148A have just 6 1GB ASICs.
> Therefore the over subscription rate is 8:1. The biggest 
> difference between these LC's is that X6148A will support 
> large MTU whereas X6148 will not.
> 
> -b
> 
> 
> On Thu, Sep 10, 2009 at 2:17 PM, Scott Spencer 
> wrote:
> 
> >  Are the X6148A cards dedicated 1 gb/s uplink for each port 
> ( shared 
> > 32 Gb/s bus , as long as each port is it's own 1 gb/s still to the 
> > 32gb/s bus and not shared with 7 other ports, so effectively just 
> > 125Mb/s per port then if all used at full/even capacity) ?
> >
> > I can't really find anything much on X6148A internal architecture 
> > online, but it would seem that each port gets its own 1gb/s link to 
> > the card/backplane, and that the bottleneck then is the 32gb/s 
> > backplane (which is fine, as long as it's not 1 gb/s per 
> each set of 8 ports!).
> >
> >
> > Best regards,
> >
> > Scott Spencer
> > Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. 
> > Inc.
> > Nationwide Toll Free: 800.977.7473.  Direct: 972.865.1395  Fax:
> > 972.931.3340
> >   sc...@dwc-computer.com 
> >  www.dwc-it.com Sales of new and used 
> > Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert
> > and more ~
> >
> >
> 
> 
> --
> Bill Blackford
> Network Engineer
> 

RE: WS-X6148A-GE-TX performance question

[Crooks, Sam]

the other difference between WS-X6148-GE-TX and WS-X6148A-GE-TX is the A
has better QoS queuing potential (more hardware queues available) and a
lower list price...

As I recall, there are 6 ethernet controllers with 8 ports on each...
(8:1 oversubscription among the adjacent ports in a port group which use
the same ethernet controller).

The card is a Classic card, so the whole card is limited to 32 Gbps to
the backplane, which given the oversubscription ratio, shouldn't be much
of an issue...



> -Original Message-
> From: Bill Blackford [mailto:bblackf...@gmail.com] 
> Sent: Thursday, September 10, 2009 4:40 PM
> To: Scott Spencer
> Cc: nanog@nanog.org
> Subject: Re: WS-X6148A-GE-TX performance question
> 
> There was a good thread on Cisco-nsp regarding this exact 
> subject recently.
> My recollection is that both X6148 and X6148A have just 6 1GB ASICs.
> Therefore the over subscription rate is 8:1. The biggest 
> difference between these LC's is that X6148A will support 
> large MTU whereas X6148 will not.
> 
> -b
> 
> 
> On Thu, Sep 10, 2009 at 2:17 PM, Scott Spencer 
> wrote:
> 
> >  Are the X6148A cards dedicated 1 gb/s uplink for each port 
> ( shared 
> > 32 Gb/s bus , as long as each port is it's own 1 gb/s still to the 
> > 32gb/s bus and not shared with 7 other ports, so effectively just 
> > 125Mb/s per port then if all used at full/even capacity) ?
> >
> > I can't really find anything much on X6148A internal architecture 
> > online, but it would seem that each port gets its own 1gb/s link to 
> > the card/backplane, and that the bottleneck then is the 32gb/s 
> > backplane (which is fine, as long as it's not 1 gb/s per 
> each set of 8 ports!).
> >
> >
> > Best regards,
> >
> > Scott Spencer
> > Data Center Asset Recovery/Remarketing Manager Duane Whitlow & Co. 
> > Inc.
> > Nationwide Toll Free: 800.977.7473.  Direct: 972.865.1395  Fax:
> > 972.931.3340
> >   sc...@dwc-computer.com 
> >  www.dwc-it.com Sales of new and used 
> > Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert
> > and more ~
> >
> >
> 
> 
> --
> Bill Blackford
> Network Engineer
> 

Re: WS-X6148A-GE-TX performance question

[Tim Lampman]

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/release/notes/OL_4164.html#wp2563293

Scott Spencer wrote:

 Are the X6148A cards dedicated 1 gb/s uplink for each port ( shared 32 Gb/s
bus , as long as each port is it's own 1 gb/s still to the 32gb/s bus and
not shared with 7 other ports, so effectively just 125Mb/s per port then if
all used at full/even capacity) ?

I can't really find anything much on X6148A internal architecture online,
but it would seem that each port gets its own 1gb/s link to the
card/backplane, and that the bottleneck then is the 32gb/s backplane (which
is fine, as long as it's not 1 gb/s per each set of 8 ports!).

 
Best regards,
 
Scott Spencer

Data Center Asset Recovery/Remarketing Manager
Duane Whitlow & Co. Inc.
Nationwide Toll Free: 800.977.7473.  Direct: 972.865.1395  Fax: 972.931.3340
  sc...@dwc-computer.com
 www.dwc-it.com 
Sales of new and used Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert
and more ~   
 

  



--
Tim Lampman
Co-Owner/CTO
*Broadline Networks Inc.*
57 Colborne Street West, Brantford, ON, N3T 1K6
*c.* 905-746-3114
www.broadlinenetworks.com  | 
t...@broadlinenetworks.com 

Re: Repeated Blacklisting / IP reputation

[Martin Hannigan]

On Thu, Sep 10, 2009 at 4:21 PM, David Conrad  wrote:

> On Sep 9, 2009, at 8:41 PM, Martin Hannigan wrote:
>
>> Not sure when ICANN got into the business of economic bailouts,
>>
>
> ??
>

The blog posting implies it:


"AfriNIC and LACNIC have fewest IPv4 /8s and service the regions with the
most developing economies. We decided that those RIRs should have four of
the easiest to use /8s reserved for them."

There is also a possible unintended consequence. If v4 address space markets
do end up being legitimized (I do believe that they will FWIW)  ICANN is in
effect declaring one class of space more valuable than another an
arbitrarily assigning that value.


>  but the mechanism that ICANN has defined seems patently unfair.
>>
>
> RFC 2777 is unfair?  Or are you unhappy that LACNIC and AfriNIC have 2 /8s
> from the least tainted pools?
>



I don't have a comment on the RFC. There is currently a global policy that
the RIR's and ICANN agreed to that defines the allocation of /8's from IANA
to RIR's. That policy doesnt include a set-aside and I think that
arbitrarily adding one is not in the spirit of cooperation. I think that
it's "good" that ICANN is being proactive, but I also think that it's "bad"
that they chose this to be proactive about. It's possible that not
everything is above the table as well. I think that the perception is
reality here though. ICANN has arbitrarily created process that impacts
RIR's unequally. To me, that's unfair.

Question is -- do a few /8's really matter? In the end game, I think that
they do all considered.

Best,

Marty


-- 
Martin Hannigan   mar...@theicelandguy.com
p: +16178216079
Power, Network, and Costs Consulting for Iceland Datacenters and Occupants

Re: WS-X6148A-GE-TX performance question

[Bill Blackford]

There was a good thread on Cisco-nsp regarding this exact subject recently.
My recollection is that both X6148 and X6148A have just 6 1GB ASICs.
Therefore the over subscription rate is 8:1. The biggest difference between
these LC's is that X6148A will support large MTU whereas X6148 will not.

-b


On Thu, Sep 10, 2009 at 2:17 PM, Scott Spencer wrote:

>  Are the X6148A cards dedicated 1 gb/s uplink for each port ( shared 32
> Gb/s
> bus , as long as each port is it's own 1 gb/s still to the 32gb/s bus and
> not shared with 7 other ports, so effectively just 125Mb/s per port then if
> all used at full/even capacity) ?
>
> I can't really find anything much on X6148A internal architecture online,
> but it would seem that each port gets its own 1gb/s link to the
> card/backplane, and that the bottleneck then is the 32gb/s backplane (which
> is fine, as long as it's not 1 gb/s per each set of 8 ports!).
>
>
> Best regards,
>
> Scott Spencer
> Data Center Asset Recovery/Remarketing Manager
> Duane Whitlow & Co. Inc.
> Nationwide Toll Free: 800.977.7473.  Direct: 972.865.1395  Fax:
> 972.931.3340
>   sc...@dwc-computer.com
>  www.dwc-it.com
> Sales of new and used Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert
> and more ~
>
>


-- 
Bill Blackford
Network Engineer

WS-X6148A-GE-TX performance question

[Scott Spencer]

 Are the X6148A cards dedicated 1 gb/s uplink for each port ( shared 32 Gb/s
bus , as long as each port is it's own 1 gb/s still to the 32gb/s bus and
not shared with 7 other ports, so effectively just 125Mb/s per port then if
all used at full/even capacity) ?

I can't really find anything much on X6148A internal architecture online,
but it would seem that each port gets its own 1gb/s link to the
card/backplane, and that the bottleneck then is the 32gb/s backplane (which
is fine, as long as it's not 1 gb/s per each set of 8 ports!).

 
Best regards,
 
Scott Spencer
Data Center Asset Recovery/Remarketing Manager
Duane Whitlow & Co. Inc.
Nationwide Toll Free: 800.977.7473.  Direct: 972.865.1395  Fax: 972.931.3340
  sc...@dwc-computer.com
 www.dwc-it.com 
Sales of new and used Cisco/Juniper/F5/Foundry/Brocade/Sun/IBM/Dell/Liebert
and more ~   
 

Re: Repeated Blacklisting / IP reputation

[David Conrad]

On Sep 9, 2009, at 8:41 PM, Martin Hannigan wrote:

Not sure when ICANN got into the business of economic bailouts,


??


but the mechanism that ICANN has defined seems patently unfair.


RFC 2777 is unfair?  Or are you unhappy that LACNIC and AfriNIC have  
2 /8s from the least tainted pools?


Regards,
-drc

ARIN XXIV follows NANOG 47 in Dearborn, MI

[John Curran]

Folks -

Just a reminder - ARIN XXIV will follow NANOG 47, starting with
a joint program session on Wednesday on IPv6.  If you will be
staying for the ARIN meeting on Thursday and Friday, please
refer to 
for logistics & registration information asap!

Thanks!
/John

John Curran
President and CEO
ARIN

Re: BGP Confederation over Route Reflector

[Jason Iannone]

I would say confeds are more appropriate for larger ibgp networks.
You can have reflectors inside confederations.  See the BGP chapter of
the JNCIP book.

On Thu, Sep 10, 2009 at 9:33 AM, Buraglio, Nicholas D
 wrote:
> Lots of things can be used to determine how you decide to set up your
> BGP peers.  
> https://www.juniper.net/customers/csc/documentation/techdocs/downloads/pdf/350010.pdf
>  has a decent amount of information on some of the differences that
> can help you decide how to set up your peerings.
>
> nb
>
> ---
> Nick Buraglio
> Network Engineer, CITES, University of Illinois
> GPG key 0x2E5B44F4
> Phone: 217.244.6428
> burag...@illinois.edu
>
> On Sep 9, 2009, at 9:52 PM, devang patel wrote:
>
>> Hello,
>> What are the advantages of BGP Confederation over Route Reflector? I
>> mean
>> when one should decide to deploy BGP Confederation over Route
>> Reflector
>> deployment?
>>
>> Thanks,
>> Devang Patel
>>
>
>
>

RE: Wireless STM-1 link

[Paul Stewart]

I totally agree with everything that Mike has posted here... one thing I
wanted to add is that a wireless link is only as good as it's
engineered.  We have many rock solid wireless links in use here - with
proper engineering and ongoing maintenance we very rarely have issues.
We do have some links that were not engineered to proper levels
(sometimes where a business decision overrode a technical decision for
example) and they do have blips every so often.  Maintenance is so
important after a link is established as stuff breaks, wears down,
leaks, and moves.

Paul


-Original Message-
From: Mike [mailto:mike-na...@tiedyenetworks.com]
Sent: September-10-09 12:35 PM
To: nanog@nanog.org
Subject: Re: Wireless STM-1 link



Kenny Sallee wrote:
> Seems everyone has focused on GE as the problem.  You can quickly rule
that
> out by looking at interface error counters and doing PING tests from
the
> wireless router/device to something on the local network on both
sides.  If
> OSPF is flapping because of missed HELLO packets then I'm thinking you
have
> a problem with either saturation on the link or actual wireless
issues.
>  When PING does work what do the times look like? I'd look at static
routing
> for a bit (if practical) or changing your OSPF HELLO intervals to see
if
> that does anything.  Here's a good link on troubleshooting
> OSPF adjacency changes:
>
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009
4050.shtml
>

I'd like to second the above. Wireless can, and often does, suffer from
isses that other media such as copper and fiber media do not, and you
need to be looking closely at the device's RF statistics (combined with
your own monitoring of link rssi, error blocks, retrans, and others...
you are monitoring and graphing this, yes?). Some of the variations you
can expect in wireless include -

Interference (if using unliscensed band gear - do NOT assume your
little corner of the world doesn't have anyone else using the band
occasionally!)
Thermal inversion fade
Water build up - especially inside of antennas and antenna elements,

this can take your -36 rssi and make it drop to -86 and then all of a
sudden come back in the space of 30 seconds. This can be the hardest
problem to find - look at your connectors, the seal up job, anywhere
they would have had to seal would be a place of penetration.
Birds, trucks, anything causing occasional multipath reflections or
blockage between the two sides

Also it is my direct experience that wireless devices from all
manufacturers also are more bug ridden and usually have far more exotic
corner cases where their gear just does the wrong thing occasionally.
Corrupt frames at the RF layer may not be detected due to various mac
layer defeciencies, with the result being incorrect reassembly and
framing of the junk as an ethernet frame and even including a valid fcs
in the ethernet header but corrupt junk in the packet itself.  Sometimes

the RF device's own bridging tables get corrupted as a result, causing
you to lose connectivity as bridge entries are relearned.  There's all
kinds of stuff that can go wrong here that is not your ordinary every
day cisco 4-byte asn bug variety.

My advice only is, be suspecious and be a good detective.

Mike-







"The information transmitted is intended only for the person or entity to which 
it is addressed and contains confidential and/or privileged material. If you 
received this in error, please contact the sender immediately and then destroy 
this transmission, including all attachments, without copying, distributing or 
disclosing same. Thank you."

Re: Repeated Blacklisting / IP reputation

[Joe Greco]

>   Because the cost of determining who is good and who is not has a great
>   cost.  If you buy an IP block, regardless of your intent, that IP block
>   should not have the ill-will of the previous owner passed on with it. 

Might as well be the end of discussion, right there, then, because what
you're suggesting suggests no grasp of the real world.

>   If
>   the previous owner sucked, the new owner should have the chance to use
>   that IP block without restriction until they prove that they suck, at
>   which point it will be blocked again.  That system seems to work well
>   enough: blacklist blocks when they start do be evil, according to your own
>   (you being the neteng in charge) definition of evil.

What you just described doesn't implement what you claim, at all.

... 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.

Re: Wireless STM-1 link

[Mike]

Kenny Sallee wrote:

Seems everyone has focused on GE as the problem.  You can quickly rule that
out by looking at interface error counters and doing PING tests from the
wireless router/device to something on the local network on both sides.  If
OSPF is flapping because of missed HELLO packets then I'm thinking you have
a problem with either saturation on the link or actual wireless issues.
 When PING does work what do the times look like? I'd look at static routing
for a bit (if practical) or changing your OSPF HELLO intervals to see if
that does anything.  Here's a good link on troubleshooting
OSPF adjacency changes:
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094050.shtml
  


I'd like to second the above. Wireless can, and often does, suffer from 
isses that other media such as copper and fiber media do not, and you 
need to be looking closely at the device's RF statistics (combined with 
your own monitoring of link rssi, error blocks, retrans, and others... 
you are monitoring and graphing this, yes?). Some of the variations you 
can expect in wireless include -


   Interference (if using unliscensed band gear - do NOT assume your 
little corner of the world doesn't have anyone else using the band 
occasionally!)

   Thermal inversion fade
   Water build up - especially inside of antennas and antenna elements, 
this can take your -36 rssi and make it drop to -86 and then all of a 
sudden come back in the space of 30 seconds. This can be the hardest 
problem to find - look at your connectors, the seal up job, anywhere 
they would have had to seal would be a place of penetration.
   Birds, trucks, anything causing occasional multipath reflections or 
blockage between the two sides


   Also it is my direct experience that wireless devices from all 
manufacturers also are more bug ridden and usually have far more exotic 
corner cases where their gear just does the wrong thing occasionally. 
Corrupt frames at the RF layer may not be detected due to various mac 
layer defeciencies, with the result being incorrect reassembly and 
framing of the junk as an ethernet frame and even including a valid fcs 
in the ethernet header but corrupt junk in the packet itself.  Sometimes 
the RF device's own bridging tables get corrupted as a result, causing 
you to lose connectivity as bridge entries are relearned.  There's all 
kinds of stuff that can go wrong here that is not your ordinary every 
day cisco 4-byte asn bug variety.


   My advice only is, be suspecious and be a good detective.

Mike-

Re: Wireless STM-1 link

[Kenny Sallee]

On Thu, Sep 10, 2009 at 2:55 AM, Rens  wrote:

> All the interfaces are forced to 1Gbps and full duplex.
>
> Maybe I should give some extra info.
> All the traffic seems to pass ok via that link but I have seen that often
> OSPF adjacencies go down/up , I suspect that the HELLO packets are being
> dropped that pass via that link.
>
> That's why I started to look a little deeper and do some ping tests.
>
> -Original Message-
> From: Adam Goodman [mailto:a...@wispring.com]
> Sent: jeudi 10 septembre 2009 11:45
> To: Rens
> Cc: 
> Subject: Re: Wireless STM-1 link
>
> Sounds like this might be an Ethernet negotiaton problem
>
> 
> Sent from my phone
>

Seems everyone has focused on GE as the problem.  You can quickly rule that
out by looking at interface error counters and doing PING tests from the
wireless router/device to something on the local network on both sides.  If
OSPF is flapping because of missed HELLO packets then I'm thinking you have
a problem with either saturation on the link or actual wireless issues.
 When PING does work what do the times look like? I'd look at static routing
for a bit (if practical) or changing your OSPF HELLO intervals to see if
that does anything.  Here's a good link on troubleshooting
OSPF adjacency changes:
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094050.shtml

Re: Wireless STM-1 link

[Kevin Loch]

Brian Reichert wrote:

On Thu, Sep 10, 2009 at 11:55:40AM +0200, Rens wrote:

All the interfaces are forced to 1Gbps and full duplex.


I thought that with 1000T, you need to keep autonegotiation in place:

  
http://etherealmind.com/2008/07/15/ethernet-autonegotiation-works-why-how-standard-should-be-set/

"A major problem is that many people are also hard setting
Gigabit Ethernet , and this is causing major problems. Gigabit
Ethernet must have auto-negotiation ENABLED to allow negotiation
of master / slave PHY relationship for clocking at the physical
layer.  Without negotiation the line clock will not establish
correctly and physical layers problems can result."

Further:

  http://en.wikipedia.org/wiki/Autonegotiation

"The debatable portions of the autonegotiation specifications were
eliminated by the 1998 version of IEEE 802.3. In 1999, the negotiation
protocol was significantly extended by IEEE 802.3ab, which specified the
protocol for gigabit Ethernet, making autonegotiation mandatory for
1000BASE-T gigabit Ethernet over copper."

Note the 'mandatory'...



I'm in the "it's not 1996 anymore, let autonegotiation do it's
job" camp.  I occasionally see folks who religiously "lock down"
all ports only to create the very duplex mismatches they are trying
to avoid.  Engineers, equipment, port positions and operating systems
can change over time defeating even the best laid plans for total
port control.

- Kevin

Re: BGP Confederation over Route Reflector

[Buraglio, Nicholas D]

Lots of things can be used to determine how you decide to set up your  
BGP peers.  
https://www.juniper.net/customers/csc/documentation/techdocs/downloads/pdf/350010.pdf
 
  has a decent amount of information on some of the differences that  
can help you decide how to set up your peerings.

nb

---
Nick Buraglio
Network Engineer, CITES, University of Illinois
GPG key 0x2E5B44F4
Phone: 217.244.6428
burag...@illinois.edu

On Sep 9, 2009, at 9:52 PM, devang patel wrote:

> Hello,
> What are the advantages of BGP Confederation over Route Reflector? I  
> mean
> when one should decide to deploy BGP Confederation over Route  
> Reflector
> deployment?
>
> Thanks,
> Devang Patel
>

Re: Repeated Blacklisting / IP reputation

[Valdis . Kletnieks]

On Wed, 09 Sep 2009 20:30:02 PDT, Leo Vegoda said:

> Putting these addresses back into use does not mean that they have to
> be allocated to networks where they'll number mail servers. ARIN staff
> is doubtless aware of the history of these blocks and will presumably
> do their best to allocate them to networks that aren't intended to
> host mail servers.

Those streaming video servers in that returned /24 are going to work *real*
well talking to a network that implemented the block as a null route rather
than a port-25 block.



pgpTDcdvozLS7.pgp
Description: PGP signature

Re: Repeated Blacklisting / IP reputation

[Benjamin Billon]

You're not Hotmail =)

Re: Repeated Blacklisting / IP reputation

[Peter Beckman]

On Thu, 10 Sep 2009, Benjamin Billon wrote:




 Why don't we just blacklist everything and only whitelist those we know
 are good?


Note we all could start using IPv6 and avoid this problem altogether.


Yeah. When ISP will start receiving SMTP traffic in IPv6, they could start to 
accept whitelisted senders only.


"IPv6 emails == clean"

Utopian thought?


 My statement about blacklisting everything was sarcastic.  Clearly
 blacklisting everything and whitelisting individual blocks is not a
 viable, reasonable nor cost-effective option.

 Clearly I also suck at conveying sarcasm via email. :-)

Beckman
---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: Repeated Blacklisting / IP reputation

[Kevin Loch]

Benjamin Billon wrote:



 Why don't we just blacklist everything and only whitelist those we know
 are good?


Note we all could start using IPv6 and avoid this problem altogether.


Yeah. When ISP will start receiving SMTP traffic in IPv6, they could 
start to accept whitelisted senders only.


"IPv6 emails == clean"

Utopian thought?


Are you not receiving SMTP traffic via IPv6 yet?

Received: from s0.nanog.org ([IPv6:2001:48a8:6880:95::20])

- Kevin

Re: Repeated Blacklisting / IP reputation

[bmanning]

On Thu, Sep 10, 2009 at 04:42:13PM +0200, Benjamin Billon wrote:
> 
> > Why don't we just blacklist everything and only whitelist those we know
> > are good?
> >
> >>Note we all could start using IPv6 and avoid this problem altogether.
> >
> Yeah. When ISP will start receiving SMTP traffic in IPv6, they could 
> start to accept whitelisted senders only.
> 
> "IPv6 emails == clean"
> 
> Utopian thought?

abt 8 years too late...

--bill

Re: Repeated Blacklisting / IP reputation

[Benjamin Billon]

 Why don't we just blacklist everything and only whitelist those we know
 are good?


Note we all could start using IPv6 and avoid this problem altogether.


Yeah. When ISP will start receiving SMTP traffic in IPv6, they could 
start to accept whitelisted senders only.


"IPv6 emails == clean"

Utopian thought?

RE: IPSEC-VRF MIB

[Bailey Stephen]

Will give it a go also, cheers

Ste Bailey 
FUJITSU

-Original Message-
From: Jason Bertoch [mailto:ja...@i6ix.com] 
Sent: 10 September 2009 15:26
To: nanog@nanog.org
Subject: Re: IPSEC-VRF MIB

Bailey Stephen wrote:
> I am looking to monitor the number of active IPSEC tunnels terminating
> in a given VRF via SNMP
>
>
> Vpn#show crypto mib ipsec flowmib global vrf test-vrf
>
> vrf test-vrf
>
> Active Tunnels:   2 
>
> ...
>
>
> Is there anyway I can get this ActiveTunnels value via SNMP and MIBs?
>   
Have you asked around on the Cacti forums?

Re: Repeated Blacklisting / IP reputation

[Peter Beckman]

On Thu, 10 Sep 2009, Mark Andrews wrote:


What a load of rubbish.  How is ARIN or any RIR/LIR supposed to
know the intent of use?


 Why don't we just blacklist everything and only whitelist those we know
 are good?

 Because the cost of determining who is good and who is not has a great
 cost.  If you buy an IP block, regardless of your intent, that IP block
 should not have the ill-will of the previous owner passed on with it.  If
 the previous owner sucked, the new owner should have the chance to use
 that IP block without restriction until they prove that they suck, at
 which point it will be blocked again.  That system seems to work well
 enough: blacklist blocks when they start do be evil, according to your own
 (you being the neteng in charge) definition of evil.

 ARIN needs to be impartial.  If they are going to sell the block, they
 should do their best to make a coordinated effort to make sure the block
 is as unencumbered as possible.  I get that there is a sense that ARIN
 needs to do more due dilligence to determine if the receiving party is
 worthy of that block, but I'm not aware of the process, and from the
 grumblings it doesn't seem like fun.


Note we all could start using IPv6 and avoid this problem altogether.


 Because as we know IPv6 space is inexhaustable.  Just like IPv4 was when
 it began its life. ;-)

 That won't avoid the problem, it will simply put the problem off until it
 rears its head again.  I'm sure that IPv6 space will be more easily gotten
 until problems arise, and in a few years (maybe decades, we can put this
 problem on our children's shoulders), we'll be back where we are now --
 getting recycled IP space that is blocked or encumbered due to bad
 previous owners.

Beckman
---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: IPSEC-VRF MIB

[Jason Bertoch]

Bailey Stephen wrote:

I am looking to monitor the number of active IPSEC tunnels terminating
in a given VRF via SNMP


Vpn#show crypto mib ipsec flowmib global vrf test-vrf

vrf test-vrf

Active Tunnels:   2 


...


Is there anyway I can get this ActiveTunnels value via SNMP and MIBs?
  

Have you asked around on the Cacti forums?

Re: Repeated Blacklisting / IP reputation

[Nick Feamster]

Hi Tom (and NANOG),

You may be interested in an alternative approach, motivated by the
very problem you are facing (see below).  Our system, SNARE, develops
IP reputation automatically based on a combination of network
features.  We'll discuss the pros and cons of this approach at MAAWG.
The additional information that SNARE provides might be helpful.

-Nick

Detecting Spammers with SNARE: Spatio-temporal Network-level Automatic
Reputation Engine

Shuang Hao, Nadeem Ahmed Syed, Nick Feamster, Alexander Gray, Sven Krasser
Usenix Security '09, Montreal, Canada, August 2009

Users and network administrators need ways to filter email messages
based primarily on the reputation of the sender. Unfortunately,
conventional mechanisms for sender reputation -- notably, IP
blacklists -- are cumbersome to maintain and evadable. This paper
investigates ways to infer the reputation of an email sender based
solely on network-level features, without looking at the contents of a
message. First, we study first-order properties of network-level
features that may help distinguish spammers from legitimate senders.
We examine features that can be ascertained without ever looking at a
packet's contents, such as the distance in IP space to other email
senders or the geographic distance between sender and receiver. We
derive features that are lightweight, since they do not require seeing
a large amount of email from a single IP address and can be gleaned
without looking at an email's contents -- many such features are
apparent from even a single packet. Second, we incorporate these
features into a classification algorithm and evaluate the classifier's
ability to automatically classify email senders as spammers or
legitimate senders. We build an automated reputation engine, SNARE,
based on these features using labeled data from a deployed commercial
spam-filtering system. We demonstrate that SNARE can achieve
comparable accuracy to existing static IP blacklists: about a 70%
detection rate for less than a 0.3% false positive rate. Third, we
show how SNARE can be integrated into existing blacklists, essentially
as a first-pass filter.

http://gtnoise.net/pub/index.php?detail=14

On Tue, Sep 8, 2009 at 4:58 PM, Tom Pipes  wrote:
> I am amazed with the amount of thoughtful comments I have seen, both on and 
> off list. It really illustrates that people are willing to try to help out, 
> but there is an overall lack of clear direction on how to improve things.  
> Most of us seem to adopt that which has always just worked for us. Don't get 
> me wrong, I'm sure there are a lot of improvements/mods going on with RBL 
> operators in terms of the technology and how they choose who to block.  I'm 
> also certain that most of the carriers are doing their best to follow RFCs, 
> use e-mail filtering, and perform deep packet inspection to keep themselves 
> off of the lists. AND there seems to be some technologies that were meant to 
> work, and cause their own sets of problems (example:  allowing the end user 
> to choose what is considered spam and blacklisting based on that).  As was 
> said before, it's not the "WHY" but rather how can we fix it if it's broke.
>
> The large debate seems to revolve around responsibility, or lack thereof. In 
> our case, we are the small operator who sits in the sidelines hoping that 
> someone larger than us, or more influential has an opinion.  We participate 
> in lists, hoping to make a difference and contribute, knowing that in a lot 
> of cases, our opinion is just that:  an opinion.  I suppose that could spark 
> a debate about joining organizations (who shall go nameless here), power to 
> the people, etc.
>
> It seems as though a potential solution *may* revolve around ARIN/IANA having 
> the ability to communicate an authoritative list of reassigned IP blocks back 
> to the carriers.  This could serve as a signal to remove a block from the 
> RBL, but I'm sure there will be downfalls with doing this as well.
>
> In my specific case, I am left with a legacy block that I have to accept is 
> going to be problematic. Simply contacting RBL operators is just not doing 
> the trick. Most of the e-mails include links or at least an error code, but 
> some carriers just seem to be blocking without an error, or even worse, an 
> ACL...
>
> We will continue to remove these blocks as necessary, reassign IPs from other 
> blocks where absolutely necessary, and ultimately hope the problem resolves 
> itself over time.
>
> Thanks again for the very thoughtful and insightful comments, they are 
> greatly appreciated.
>
> Regards,
>
>
> ---
> Tom Pipes
> T6 Broadband/
> Essex Telcom Inc
> tom.pi...@t6mail.com
>
>
> - Original Message -
> From: "Tom Pipes" 
> To: nanog@nanog.org
> Sent: Tuesday, September 8, 2009 9:57:58 AM GMT -06:00 US/Canada Central
> Subject: Repeated Blacklisting / IP reputation
>
> Greetings,
>
>
> We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in 2008. This 
> block 

Re: Wireless STM-1 link

[Brian Reichert]

On Thu, Sep 10, 2009 at 11:55:40AM +0200, Rens wrote:
> All the interfaces are forced to 1Gbps and full duplex.

I thought that with 1000T, you need to keep autonegotiation in place:

  
http://etherealmind.com/2008/07/15/ethernet-autonegotiation-works-why-how-standard-should-be-set/

"A major problem is that many people are also hard setting
Gigabit Ethernet , and this is causing major problems. Gigabit
Ethernet must have auto-negotiation ENABLED to allow negotiation
of master / slave PHY relationship for clocking at the physical
layer.  Without negotiation the line clock will not establish
correctly and physical layers problems can result."

Further:

  http://en.wikipedia.org/wiki/Autonegotiation

"The debatable portions of the autonegotiation specifications were
eliminated by the 1998 version of IEEE 802.3. In 1999, the negotiation
protocol was significantly extended by IEEE 802.3ab, which specified the
protocol for gigabit Ethernet, making autonegotiation mandatory for
1000BASE-T gigabit Ethernet over copper."

Note the 'mandatory'...

-- 
Brian Reichert  
55 Crystal Ave. #286Daytime number: (603) 434-6842
Derry NH 03038-1725 USA BSD admin/developer at large

Re: Repeated Blacklisting / IP reputation

[Dave Martin]

On Wed, Sep 09, 2009 at 04:13:18PM -0700, Jay Hennigan wrote:
> JC Dill wrote:
> As for a role account, there is "postmaster".  I would think that the  
> best hope in the real world, rather than an autoresponder would be an  
> RFC that clearly defines text accompanying an SMTP rejection notice  
> triggered by a blocklist, detailing the blocklist and contact for  
> removal.  Perhaps encouraging those who code MTAs and DNSBL hooks into  
> them to include such in the configuration files would be a good start.

That would be very useful.  Many of those small lists return 'Unknown
user' rather than an actual blacklist message.  A url where one could
get reason (meaning headers) for the block would be even better.  If
they don't admit that it's a block, it's hard to do much more than tell
the user to contact the recipient via some other channel and have *them*
contact their support system.


-- 
Dave
-
Nobody believed that I could build a space station here.  So I built it anyway.
It sank into the vortex.  So I built another one.  It sank into the vortex.  
The third station burned down, fell over then sank into the vortex.  The fourth
station just vanished.  And the fifth station, THAT stayed!

IPSEC-VRF MIB

[Bailey Stephen]

Hey all,

 

I am looking to monitor the number of active IPSEC tunnels terminating
in a given VRF via SNMP

 

I can use the following command on the device (Cisco 3845 -
12.4(22)T)

 

Vpn#show crypto mib ipsec flowmib global vrf test-vrf

vrf test-vrf

Active Tunnels:   2 

...

 

Is there anyway I can get this ActiveTunnels value via SNMP and MIBs?

 

I can do an SNMP walk and get the GlobalActiveTunnels, but I need the
number of active tunnels in a VRF

 

Any help would be appreciated

 

Cheers

 

Stephen Bailey

 

FUJITSU

Fujitsu Services Limited, Registered in England no 96056, Registered
Office 22 Baker Street, London, W1U 3BW

 

This e-mail is only for the use of its intended recipient.  Its contents
are subject to a duty of confidence and may be privileged.  Fujitsu
Services does not guarantee that this e-mail has not been intercepted
and amended or that it is virus-free.

 

RE: Wireless STM-1 link

[Rens]

Between 20 & 80 Mbps, no real relation between the problem and the time of a
day/higher/lower traffic

 

  _  

From: Kieran Murphy [mailto:da...@daffy.za.net] 
Sent: jeudi 10 septembre 2009 15:14
To: Rens
Cc: Florian Weimer; nanog@nanog.org
Subject: Re: Wireless STM-1 link

 

Whats the utilization of the link at the time that you're seeing problems?

On Thu, Sep 10, 2009 at 2:10 PM, Rens  wrote:

I have tried both actually, forced and auto, same issue


-Original Message-
From: Florian Weimer [mailto:fwei...@bfk.de]
Sent: jeudi 10 septembre 2009 15:04
To: Rens
Cc: nanog@nanog.org
Subject: Re: Wireless STM-1 link

> All the interfaces are forced to 1Gbps and full duplex.

This takes the interface out of spec, IIRC.  Try with auto-negotation
enabled.

--
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99



 

Re: Wireless STM-1 link

[Kieran Murphy]

Whats the utilization of the link at the time that you're seeing problems?

On Thu, Sep 10, 2009 at 2:10 PM, Rens  wrote:

> I have tried both actually, forced and auto, same issue
>
> -Original Message-
> From: Florian Weimer [mailto:fwei...@bfk.de]
> Sent: jeudi 10 septembre 2009 15:04
> To: Rens
> Cc: nanog@nanog.org
> Subject: Re: Wireless STM-1 link
>
> > All the interfaces are forced to 1Gbps and full duplex.
>
> This takes the interface out of spec, IIRC.  Try with auto-negotation
> enabled.
>
> --
> Florian Weimer
> BFK edv-consulting GmbH   http://www.bfk.de/
> Kriegsstraße 100  tel: +49-721-96201-1
> D-76133 Karlsruhe fax: +49-721-96201-99
>
>
>

RE: Wireless STM-1 link

[Rens]

I have tried both actually, forced and auto, same issue

-Original Message-
From: Florian Weimer [mailto:fwei...@bfk.de] 
Sent: jeudi 10 septembre 2009 15:04
To: Rens
Cc: nanog@nanog.org
Subject: Re: Wireless STM-1 link

> All the interfaces are forced to 1Gbps and full duplex.

This takes the interface out of spec, IIRC.  Try with auto-negotation
enabled.

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Wireless STM-1 link

[Florian Weimer]

> All the interfaces are forced to 1Gbps and full duplex.

This takes the interface out of spec, IIRC.  Try with auto-negotation
enabled.

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Wireless STM-1 link

[Arie Vayner]

Rens,

Does not sound like the symptoms for what I want to write about, but this is
something you need to consider in any way:

When you run sub-rate links (i.e. 1GE interface with really 155Mbps as the
service) you need to make sure that you do not try to push more traffic than
the link can take.
This is mostly relevant for traffic bursts, which happen all the time with
IP traffic. So even if on average you do not use the bandwidth, still you
have short bursts whenever you start a transaction (like a file transfer
etc).

In order to avoid packets being dropped due to this burst on the link, the
1GE equipment before the link should be doing egress shaping to the rate
(sometimes even it is good to choose a rate slightly lower then the actual
rate) of the link.
This would make sure that the network equipment manages the packet drops (if
you have a child QOS policy) and you do not get random tail drops of the
burst.

This means that you need to choose the right network device that actually
supports egress shaping. Be aware that many L2/L3 switches do not support
this.

Arie

On Thu, Sep 10, 2009 at 12:55 PM, Rens  wrote:

> All the interfaces are forced to 1Gbps and full duplex.
>
> Maybe I should give some extra info.
> All the traffic seems to pass ok via that link but I have seen that often
> OSPF adjacencies go down/up , I suspect that the HELLO packets are being
> dropped that pass via that link.
>
> That's why I started to look a little deeper and do some ping tests.
>
> -Original Message-
> From: Adam Goodman [mailto:a...@wispring.com]
> Sent: jeudi 10 septembre 2009 11:45
> To: Rens
> Cc: 
> Subject: Re: Wireless STM-1 link
>
> Sounds like this might be an Ethernet negotiaton problem
>
> 
> Sent from my phone
>
> On Sep 10, 2009, at 12:05 PM, "Rens"  wrote:
>
> > Hi all,
> >
> >
> >
> > I'm encountering a problem with a wireless STM-1 link which has a
> > switch
> > connected at each end.
> >
> > The wireless link has Gigabit Ethernet interfaces and so have my
> > switches.
> >
> >
> >
> > When I ping between the 2 switches via that wireless link I'm
> > getting a lot
> > of pings that are lost.
> >
> > The wireless link is not saturated but I'm thinking it could have to
> > do
> > something with the gigabit interfaces and only having 155Mbps on the
> > link
> > itself?
> >
> >
> >
> > All ideas welcome.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Rens
> >
>
>
>

RE: Wireless STM-1 link

[Rens]

Yes all the radio RF levels are 100% ok.

-Original Message-
From: Josh Cheney [mailto:josh.che...@gmail.com] 
Sent: jeudi 10 septembre 2009 12:47
To: Rens
Cc: 'Adam Goodman'; nanog@nanog.org
Subject: Re: Wireless STM-1 link

I'm assuming that you have checked all of the wireless parameters (noise 
floor, signal strength, jitter, etc)? I've seen behavior like this on 
links where the noise floor has risen to the point where the true signal 
cannot be distinguished from background noise.

Josh

Rens wrote:
> All the interfaces are forced to 1Gbps and full duplex.
> 
> Maybe I should give some extra info.
> All the traffic seems to pass ok via that link but I have seen that often
> OSPF adjacencies go down/up , I suspect that the HELLO packets are being
> dropped that pass via that link.
> 
> That's why I started to look a little deeper and do some ping tests.
> 
> -Original Message-
> From: Adam Goodman [mailto:a...@wispring.com]
> Sent: jeudi 10 septembre 2009 11:45
> To: Rens
> Cc: 
> Subject: Re: Wireless STM-1 link
> 
> Sounds like this might be an Ethernet negotiaton problem
> 
> 
> Sent from my phone
> 
> On Sep 10, 2009, at 12:05 PM, "Rens"  wrote:
> 
>> Hi all,
>>
>>
>>
>> I'm encountering a problem with a wireless STM-1 link which has a  
>> switch
>> connected at each end.
>>
>> The wireless link has Gigabit Ethernet interfaces and so have my  
>> switches.
>>
>>
>>
>> When I ping between the 2 switches via that wireless link I'm  
>> getting a lot
>> of pings that are lost.
>>
>> The wireless link is not saturated but I'm thinking it could have to  
>> do
>> something with the gigabit interfaces and only having 155Mbps on the  
>> link
>> itself?
>>
>>
>>
>> All ideas welcome.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Rens
>>
> 
> 


-- 
Josh Cheney
josh.che...@gmail.com
http://www.joshcheney.com

Re: Wireless STM-1 link

[Josh Cheney]

I'm assuming that you have checked all of the wireless parameters (noise 
floor, signal strength, jitter, etc)? I've seen behavior like this on 
links where the noise floor has risen to the point where the true signal 
cannot be distinguished from background noise.


Josh

Rens wrote:

All the interfaces are forced to 1Gbps and full duplex.

Maybe I should give some extra info.
All the traffic seems to pass ok via that link but I have seen that often
OSPF adjacencies go down/up , I suspect that the HELLO packets are being
dropped that pass via that link.

That's why I started to look a little deeper and do some ping tests.

-Original Message-
From: Adam Goodman [mailto:a...@wispring.com]
Sent: jeudi 10 septembre 2009 11:45
To: Rens
Cc: 
Subject: Re: Wireless STM-1 link

Sounds like this might be an Ethernet negotiaton problem


Sent from my phone

On Sep 10, 2009, at 12:05 PM, "Rens"  wrote:


Hi all,



I'm encountering a problem with a wireless STM-1 link which has a  
switch

connected at each end.

The wireless link has Gigabit Ethernet interfaces and so have my  
switches.




When I ping between the 2 switches via that wireless link I'm  
getting a lot

of pings that are lost.

The wireless link is not saturated but I'm thinking it could have to  
do
something with the gigabit interfaces and only having 155Mbps on the  
link

itself?



All ideas welcome.



Regards,



Rens







--
Josh Cheney
josh.che...@gmail.com
http://www.joshcheney.com

Re: Traffic Shaping on ISPs

[Astrodog]

BT/Virgin throttling information:

http://www.theregister.co.uk/2009/02/11/virgin_media_throttle_extension/
http://www.theregister.co.uk/2008/08/07/bt_samknows_bandwidth_throttling/
http://news.bbc.co.uk/2/hi/technology/8077839.stm
http://www.telegraph.co.uk/technology/news/5431052/BT-admits-limiting-download-speeds-and-throttling-iPlayer-traffic.html

It looks like the throttling window lines up fairly well with the
times you're seeing problems. Now, if that's the throttling, or just
BT's network being oversubscribed... who knows.

Good luck getting your problem cleared up.

 Harrison Grundy

On Thu, Sep 10, 2009 at 4:49 AM, Jake Vargas wrote:
>> While I cannot confirm officially, there is a lot of rumors, that several
>> larger UK ISP's are throttling traffic at that time period.
>> I am not sure who to contact, but the individual ISP's to solve this, from
>> your point, maybe another NANOG'er knows.
>
> Hi Lasse,
>
> Thanks for the reply. We wrote an app to reveal troubles.
>
> Just to satisfy any curiosity and get some facts out, I will provide a real 
> world example (1 of many) from a direct test of one of our BT sourced 
> customers (this is from a 08-29 test at ~22:04 hours GMT):
>
> Date                    IP                      RTT     Port    ActualRecv    
>   NicSent NicRecv
> 090829 22:04:24 86.128.0.0/10   103.5   80      199     13      214
> 090829 22:04:24 86.128.0.0/10           103.5   80      199     13      214
> 090829 22:04:24 86.128.0.0/10           103.5   443     200     12      215
> 090829 22:04:24 86.128.0.0/10           103.5   443     199     12      214
> 090829 22:04:24 86.128.0.0/10           103.5   7255    2       2       5
> 090829 22:04:24 86.128.0.0/10           103.5   7255    3       1       4
> 090829 22:04:24 86.128.0.0/10           103.5   7003    3       2       5
> 090829 22:04:24 86.128.0.0/10           103.5   7003    4       1       5
> 090829 22:04:24 86.128.0.0/10           103.5   7202    27      3       32
> 090829 22:04:24 86.128.0.0/10           103.5   7202    24      2       29
> 090829 22:04:24 86.128.0.0/10           103.5   7499    27      3       32
> 090829 22:04:24 86.128.0.0/10           103.5   7499    25      2       31
> 090829 22:04:24 86.128.0.0/10           103.5   80      195     13      206
> Idle NIC bandwidth  Send:     0 KB/sec   Recv:     0 KB/sec
>
> To remove any doubt we also measured idle bandwidth utilization on the NIC 
> when the test wasn't run to remove any other culprit such as torrent 
> download, A/V streaming and etc in the background. In this case, 0/0 on idle 
> use. All results are in KBytes
>
> I withheld the actual IP address of this test and replaced it from the source 
> prefix. We have quite a few iterations of similar results from other source 
> addresses from this prefix alone. All appear to exhibit the same issue.
>
> I've already written British Telecom and they never replied.
>
>
>

RE: Wireless STM-1 link

[Rens]

All the interfaces are forced to 1Gbps and full duplex.

Maybe I should give some extra info.
All the traffic seems to pass ok via that link but I have seen that often
OSPF adjacencies go down/up , I suspect that the HELLO packets are being
dropped that pass via that link.

That's why I started to look a little deeper and do some ping tests.

-Original Message-
From: Adam Goodman [mailto:a...@wispring.com]
Sent: jeudi 10 septembre 2009 11:45
To: Rens
Cc: 
Subject: Re: Wireless STM-1 link

Sounds like this might be an Ethernet negotiaton problem


Sent from my phone

On Sep 10, 2009, at 12:05 PM, "Rens"  wrote:

> Hi all,
>
>
>
> I'm encountering a problem with a wireless STM-1 link which has a  
> switch
> connected at each end.
>
> The wireless link has Gigabit Ethernet interfaces and so have my  
> switches.
>
>
>
> When I ping between the 2 switches via that wireless link I'm  
> getting a lot
> of pings that are lost.
>
> The wireless link is not saturated but I'm thinking it could have to  
> do
> something with the gigabit interfaces and only having 155Mbps on the  
> link
> itself?
>
>
>
> All ideas welcome.
>
>
>
> Regards,
>
>
>
> Rens
>

RE: Traffic Shaping on ISPs

[Jake Vargas]

> While I cannot confirm officially, there is a lot of rumors, that several
> larger UK ISP's are throttling traffic at that time period.
> I am not sure who to contact, but the individual ISP's to solve this, from
> your point, maybe another NANOG'er knows.

Hi Lasse, 

Thanks for the reply. We wrote an app to reveal troubles.

Just to satisfy any curiosity and get some facts out, I will provide a real 
world example (1 of many) from a direct test of one of our BT sourced customers 
(this is from a 08-29 test at ~22:04 hours GMT):

DateIP  RTT PortActualRecv  
NicSent NicRecv
090829 22:04:24 86.128.0.0/10   103.5   80  199 13  214
090829 22:04:24 86.128.0.0/10   103.5   80  199 13  214
090829 22:04:24 86.128.0.0/10   103.5   443 200 12  215
090829 22:04:24 86.128.0.0/10   103.5   443 199 12  214
090829 22:04:24 86.128.0.0/10   103.5   72552   2   5
090829 22:04:24 86.128.0.0/10   103.5   72553   1   4
090829 22:04:24 86.128.0.0/10   103.5   70033   2   5
090829 22:04:24 86.128.0.0/10   103.5   70034   1   5
090829 22:04:24 86.128.0.0/10   103.5   720227  3   32
090829 22:04:24 86.128.0.0/10   103.5   720224  2   29
090829 22:04:24 86.128.0.0/10   103.5   749927  3   32
090829 22:04:24 86.128.0.0/10   103.5   749925  2   31
090829 22:04:24 86.128.0.0/10   103.5   80  195 13  206
Idle NIC bandwidth  Send: 0 KB/sec   Recv: 0 KB/sec

To remove any doubt we also measured idle bandwidth utilization on the NIC when 
the test wasn't run to remove any other culprit such as torrent download, A/V 
streaming and etc in the background. In this case, 0/0 on idle use. All results 
are in KBytes

I withheld the actual IP address of this test and replaced it from the source 
prefix. We have quite a few iterations of similar results from other source 
addresses from this prefix alone. All appear to exhibit the same issue. 

I've already written British Telecom and they never replied.

Re: Wireless STM-1 link

[Adam Goodman]

Sounds like this might be an Ethernet negotiaton problem


Sent from my phone

On Sep 10, 2009, at 12:05 PM, "Rens"  wrote:


Hi all,



I'm encountering a problem with a wireless STM-1 link which has a  
switch

connected at each end.

The wireless link has Gigabit Ethernet interfaces and so have my  
switches.




When I ping between the 2 switches via that wireless link I'm  
getting a lot

of pings that are lost.

The wireless link is not saturated but I'm thinking it could have to  
do
something with the gigabit interfaces and only having 155Mbps on the  
link

itself?



All ideas welcome.



Regards,



Rens

Wireless STM-1 link

[Rens]

Hi all,

 

I'm encountering a problem with a wireless STM-1 link which has a switch
connected at each end.

The wireless link has Gigabit Ethernet interfaces and so have my switches.

 

When I ping between the 2 switches via that wireless link I'm getting a lot
of pings that are lost.

The wireless link is not saturated but I'm thinking it could have to do
something with the gigabit interfaces and only having 155Mbps on the link
itself?

 

All ideas welcome.

 

Regards,

 

Rens

RE: Traffic Shaping on ISPs

[Lasse Schmidt]

Hi Jake


While I cannot confirm officially, there is a lot of rumors, that several
larger UK ISP's are throttling traffic at that time period.
I am not sure who to contact, but the individual ISP's to solve this, from
your point, maybe another NANOG'er knows.



Lasse



-Original Message-
From: Jake Vargas [mailto:jvar...@crypticstudios.com] 
Sent: 10. september 2009 09:54
To: 'nanog@nanog.org'
Subject: Traffic Shaping on ISPs

Hi Nanog, 

We have recently introduced a MMORPG (online game) to the Internet. We
currently are receiving many complaints from UK (and a few EU) customers of
sudden traffic loss or slowness which makes the game unplayable. The
complaints come through like clockwork from 6:00PM to 11:59PM (GMT). Our
chief complaint customers originate from British Telecom who equate to an
aggregate estimate of 200Mbps during said hours. 

Is there any advice, known traffic shaping bucket or predictive traffic
shaping of sorts that could be impeding our customers use over our ports
TCP/7000-7500? Would our traffic be considered P2P traffic and throttled
once inside their ASN (or even outside)? 

Understandably ISPs would want to protect the precious bandwidth and IP
services.

We are based in US but I am at a wits end on route shifting over our major
ISP connections and finding no resolution. 

Is there anyone who has experienced cross-the-pond issues such as this and
had had luck in finding a resolution or at least an answer? (Maybe a form to
fill out for cut-through allowance/whitelist for our prefix and port range,
if such a thing existed?).

Much obliged, 
Jake


__ Information from ESET Smart Security, version of virus signature
database 4412 (20090909) __

The message was checked by ESET Smart Security.

http://www.eset.com


 

__ Information from ESET Smart Security, version of virus signature
database 4412 (20090909) __

The message was checked by ESET Smart Security.

http://www.eset.com
 

Traffic Shaping on ISPs

[Jake Vargas]

Hi Nanog, 

We have recently introduced a MMORPG (online game) to the Internet. We 
currently are receiving many complaints from UK (and a few EU) customers of 
sudden traffic loss or slowness which makes the game unplayable. The complaints 
come through like clockwork from 6:00PM to 11:59PM (GMT). Our chief complaint 
customers originate from British Telecom who equate to an aggregate estimate of 
200Mbps during said hours. 

Is there any advice, known traffic shaping bucket or predictive traffic shaping 
of sorts that could be impeding our customers use over our ports TCP/7000-7500? 
Would our traffic be considered P2P traffic and throttled once inside their ASN 
(or even outside)? 

Understandably ISPs would want to protect the precious bandwidth and IP 
services.

We are based in US but I am at a wits end on route shifting over our major ISP 
connections and finding no resolution. 

Is there anyone who has experienced cross-the-pond issues such as this and had 
had luck in finding a resolution or at least an answer? (Maybe a form to fill 
out for cut-through allowance/whitelist for our prefix and port range, if such 
a thing existed?).

Much obliged, 
Jake