NLR PacketNet Technical Guide
Typical Member connection to NLR PacketNet
Connections Summary
1.) Primary 10GE – Members get
a 10GE interface on their 'local' NLR PacketNet
CRS1. For those members who are not local to a NLR PacketNet
CRS node, NLR will provide a 10GE backhaul circuit over the NLR WaveNet
to a pre-defined PacketNet node.
2.) Secondary VLAN – In
addition, members may request a 1GE port on their local NLR
FrameNet 6509. This port, mapped to a VLAN, transports to a second
NLR PacketNet CRS1 node. There is no bandwidth dedicated to
this connection on the NLR FrameNet backbone.
Both these connections are included as part of NLR membership.
Physical
Cross-connect
Responsibility – It
is the responsibility of the member to provide any cross-connects or
local loop connectivity to get to their assigned ports on the NLR
device(s). This includes providing and running fiber to the
NLR device(s). An option available is to arrange for NLR
Implementation to perform this work via contracted hands-and-eyes
support, and charge this back to the member at cost.
Optics
– NLR will supply the optics for the
members' connections on the PacketNet
CRS1. These are LR1310nm XENPAKs, with a power output of
0.5dBm to -8.2dBm and a receive sensitivity of 0.5dBm to
-14.4dBm. NLR provides Attenuation if it is necessary, and Optics for the connection to the FrameNet 6509. Please see the document 'Connecting to the NLR Layer2
Network' for more information.
Fiber
Connector Type –
For the member's primary 10GE connection, the
connector type will be SC. For the
member's secondary VLAN connection, the connector
type will be LC.
MTU
– By default, NLR will set the interfaces facing NLR members
to a layer3 (IP) MTU of 9000 bytes.
IP
numbering – By
default, for IPv4 and IPv6, NLR will expect the member to provide IP
addressing for their connections to the NLR PacketNet.
Protocols
By Default, every member connection will be setup with the following
protocols active:
1.) BGP
2.) MSDP
3.) PIMv2
BGP
ASN
- NLR AS is 19401
Peering
Addresses – By
default, BGP peering will be enabled between interface
addresses. This would mean one BGP session for each
member's 10G primary connection and a second for
the member's VLAN backup connection.
IPv6
– By default, NLR will plan to enable IPv4 and IPv6 for each
member enabled using a separate BGP session
for IPv4 and for IPv6. NLR will provide a /40 allocation
to any member without their own IPv6 address space upon request.
Multicast
– By default, NLR will plan to enable both unicast and
multicast support for both IPv4 and IPv6 for each member.
Members who wish to use multicast must enable the multicast SAFI and
advertise all multicast enabled networks in that SAFI. If a member does not wish to configure multicast, communicate your preference to the NLR engineer bringing up the connection.
Prefix
Lists – NLR will
use a prefix-list for each member to protect against unintended route
leakage. The member should submit a list of prefixes they
intend to advertise to the NLR NOC. NLR will then add the advertised prefixes to their prefix database.
Route
Type Limitations - There is
no approval process for routes, but private addresses, bogons, and the
routes from other 'upstream' providers are
not allowed without further planning to ensure stability and proper
route tagging.
Prefix
Length Limitations
– Members are encouraged to aggregate their routes wherever
possible. However, there is no limit to the maximum
or minimum prefix length accepted by NLR, either for IPv4 or IPv6.
MEDs
from NLR – NLR will
set MEDs on route advertisements equal to the IGP metric. It
will be the member's responsibility to ensure that
traffic flows, as they want. For example, if the member wants
to make sure all their NLR L3 traffic flows over their primary 10G
connection, they will need to make sure they set local prefrences, since
relying on MEDs will cause some traffic to prefer the backup connection.
Dampening
– NLR disables BGP route dampening.
Authentication
– By default, NLR will not use authentication. NLR will
support MD5 authenticated peering sessions if requested. NLR
PacketNet supports GTSM.
BGP
Communities – see
the NLR BGP Communities page for
details. NLR will not strip BGP communities attached by
members.
MSDP
Peering
Addresses - MSDP peering will
use interface addresses by default.
SA
Limitations –
Administratively scoped group addresses, and groups from the SSM block are blocked. Private addresses and bogons do not show
as source addresses.
MSDP
SA Advertisement Limits
– PacketNet is currently unable to limit the number of
SAs. This may be implemented in the future, with the type of
limit (e.g. per source or per peer) depending on technical feasibility.
PIMv2
Versions
- Only v2 PIM allowed. NLR does not support Dense mode.
RP Election Limits
– NLR will block all auto-rp and bsr packets from members.
Security
Blackhole
Routing – Users of
NLR PacketNet can tag a pre-specified BGP community to on of their
routes (usually a /32) that is currently being attacked. NLR
will then blackhole traffic to that route rather than sending it on to
the member. Members will only be able to blackhole their own
routes.
In addition, users can request (via a normal trouble ticket) that NLR investigates an
incident or a more particular packet filter be put in
place.
nlr-participants.pdf