Re: [c-nsp] 10g Copper Transceivers for SPF+

[Tom Hill]

On 26/05/17 15:24, Nick Cutting wrote:
> I got a couple of greedy replies from traseiver vendors, but nothing
> from the wise old network wizards.

ProLabs were very nice to me; greed isn't really the problem - these
things won't be getting made at any scale yet.

> The GLC-10G-T - which seems to fool the switch into thinking it is SR
> , so yes I agree with the naysayers it sounds like a bad idea from
> the get go.
> 
> Is anyone using them, or has been using them?

Yes, and their reason for masquerading is generally because most vendors
haven't yet caught up with the idea yet, or don't have their own parts.
Whereas they will commonly have 10G DAC, or SR products. The reported
part number is just read from the EEPROM, and doesn't really affect how
they work in the device.

I have a pair of them. One pretends to be a DAC and the other pretends
to be an SR optic, and there's very little difference in behaviour. The
3560E whinged a bit about the transceiver not being valid, but then
pulled it up and worked just fine anyway - and that was through
(official) OneX converters, too.

The ASR9000s (Typhoon cards) had no problems with them at all, and
worked a treat over ~20m of internal patching within the DC. Didn't use
it for long, as I was just testing them out whilst we were commissioning
that hardware. No errors though!

> Reason being it would be a great way to uplink our old switches with
> SPF+ modules to our 10g copper nexus Borders, without using a
> breakout cable on the 100g ports.

Given their cost, you might find 40G breakout cheaper. Handy things to
have about for a pinch though, I must say.

I had plans to test them on slightly more daring cable runs, but I
haven't yet gotten around to it. :)

-- 
Tom
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] 10g Copper Transceivers for SPF+

[Nick Cutting]

I brought this up in 2015  - and they were new to market then.
I got a couple of greedy replies from traseiver vendors, but nothing from the 
wise old network wizards.

The GLC-10G-T - which seems to fool the switch into thinking it is SR , so yes 
I agree with the naysayers it sounds like a bad idea from the get go.

Is anyone using them, or has been using them? 

Reason being it would be a great way to uplink our old switches with SPF+ 
modules to our 10g copper nexus Borders, without using a breakout cable on the 
100g ports.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[Saku Ytti]

On 26 May 2017 at 14:44,   wrote:

Hey,

> Regarding OSPF unless you are using virtual-links or sham-links, then all
> messages are bound to a directly connected subnet so you can safely
> implement the ttl check with 254 (one hop).

This is implementation specific and you need to know which one it is.
If figuring out it is challenging start with 255 and see if it works,
if not, revert to 254. For example in JNPR lo0 filter we verify that
ICMP ND has hop-limit 255, because it's done before TTL is
decremented, verifying 254 would expose us to ICMP ND attacks from one
hop off-link.


-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best practise/security design for BGP and OSPF

[adamv0025]

Hi 

Don't use ttl check on iBGP sessions, it doesn't add any security. 

Regarding OSPF unless you are using virtual-links or sham-links, then all
messages are bound to a directly connected subnet so you can safely
implement the ttl check with 254 (one hop). 

 

Regarding securing PE-RR iBGP sessions, there's nothing that can be done
from security perspective, other than maybe the obligatory MD5 hash, cause
at this stage it's too late or way too complex to implement any security.
The BGP infrastructure has to be protected at the edges of the AS. 

 

Maybe the only other thing that you can enable if not enabled by default and
supported is the BGP enhanced attribute error handling (or even BGP
attribute filtering -but again that if implemented should be done at the
edge).  

But just checked and the enhanced attribute error handling is enabled by
default on XE 3S and IOS 15. and XR 4.3. 

 

adam

 

netconsultings.com

::carrier-class solutions for the telecommunications industry::

 

From: CiscoNSP List [mailto:cisconsp_l...@hotmail.com] 
Sent: Thursday, May 25, 2017 3:25 AM
To: Saku Ytti; adamv0...@netconsultings.com
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Best practise/security design for BGP and OSPF

 

Cheers for the replies - Just to clarify, these templates were for purely
PE->RR (Not for transit), we do run key-chain auth on OSPF, and I was hoping
to do likewise for iBGP -> RR's, but I dont *think* key-chains are supported
in XE (Yet?)...I need to do some more reading, but I believe XR supports it,
but not XE?  Regarding TTL(In both OSPF and BGP)hop count can be
arbitrary, if we encounter a link failure...do we just use worse case
scenario hops ?  Is there anything you'd add/remove from the templates that
Ive sent through?  (Obviously soft-reconfig inbound chews memory, and can be
removed, but things like max-prefix .have it currently set at warning
only...recommend killing the session for x minutes if it's exceed?)any
other suggestions are greatly appreciatedthanks. 

 

  _  

From: Saku Ytti  >
Sent: Tuesday, 23 May 2017 7:10 PM
To: adamv0...@netconsultings.com  
Cc: CiscoNSP List; cisco-nsp@puck.nether.net
 
Subject: Re: [c-nsp] Best practise/security design for BGP and OSPF 

 

On 23 May 2017 at 12:00,   > wrote:

Hey,

> Regarding OSPF,
> Best security is to use it solely for routing PE loopbacks (i.e. no
> connectivity outside the core).

But because it's IP, you might receive spooffed packet further down
the line and believe you received it from far-end. So OP's question
about TTL-security is valid one, and I'd support that. I'd also run
MD5 auth.
But of course if you have good iACL, stopping internet from sending
other than ICMP, UDP highports to links and loops, you should be
pretty safe.

ISIS and OSPF have quite interesting properties, ISIS is more secure
out-of-the-box, but in many cases you cannot stop box from punting
CLNS packets, so any edge-interface may reach control-plane by crafted
CLNS packets (without ISIS being configured on the interface).
Where-as OSPF out-of-the-box is less secure due to IP, but pretty much
every box supports ACLs, allowing you to consistently protect box.'

-- 
  ++ytti

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/