IPv6 first hop security on a budget?

[Joel Whitehouse]

What's a good budget option for switching a small lab or office ipv6 
with RA Guard, DHCP6 snooping, and ICMP6 snooping?

RE: Ingress filtering from an external cloud service to the internal network

[Torres, Matt]

NANOG,
Thank you all. I have more than enough research to do now to further learn 
about everyone’s suggestions.
~Matt

>But if you at least had the freedom to put something like this:
>
>http://www.sproute.com/span
>
>in place or 20 other similar solutions. As in you do VPN, but right from the 
>cloud instance itself or >another instance.  There is also a set of various 
>solutions that do specialized metadata like Cilium, but >they get into 
>container networking and that is definitely application redesign.

RE: Question about experiences with BGP remote-AS

[Tony Wicks]

JunOS has three different modes for Virtual routers depending on your
situation requirements. I would suggest that something in the QFX or ACX
range will be able to replicate what you are after. Otherwise the entry
level MX will certainly do the job for a little more outlay. 

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of LF OD
Sent: Saturday, 6 May 2017 4:56 AM
To: nanog@nanog.org
Subject: Question about experiences with BGP remote-AS

We have a number of small routers in co-lo sites that peer with B2B
partners. As more of our partners move to cloud, we are considering a
consolidation effort and putting all of  our peering routers in a cloud
exchange site on a single HA pair of routers. Now, each existing B2B peering
router uses a unique private ASN to EBGP peer with partners and they, in
turn, EBGP peer with our extranet perimeter ASNs for security vetting and
other stuff.


We looked for a medium-density router (or L3-switch) that can replace
multiple small routers (b2b-only, no internet), but we need to retain all of
our existing ASNs and peerings. As it turns out, there are many routers that
can do VRFs but you cannot put a unique ASN on each VRF so replicating the
old environment isn't quite that straightforward. The BGP remote-as looks to
be a possible alternative solution, but we've never used it in production
and we are unsure of the caveats. Taken at face value, it looks like we can
mimic the multi-router/unique-ASN environment we have today on a single
platform. However, networking is rarely as smooth as that so I'm asking some
of the BGP gurus... what are the pros/cons of doing using remote-as? If
anyone here uses it extensively, we could really use some feedback if you
run into challenges or hidden surprises that we wouldn't normally think of
beforehand.


Thanks in advance!


LFOD

Re: Question about experiences with BGP remote-AS

[Radu-Adrian Feurdean]

On Fri, May 5, 2017, at 18:55, LF OD wrote:

> of our existing ASNs and peerings. As it turns out, there are many
> routers that can do VRFs but you cannot put a unique ASN on each VRF so
> replicating the old environment isn't quite that straightforward. The BGP
> remote-as looks to be a possible alternative solution, but we've never

You mean *local-as*, right ?

Otherwise, there was a vendor that allowed different ASN per VRF but
only with non-MPLS vrfs, and that product line is both end-of-sale and
major overkill for your set-up.

Re: Question about experiences with BGP remote-AS

[Tyler Conrad]

Neighbor x.x.x.x local-as {whateverasn} no-prepend replace-as

On Friday, May 5, 2017, LF OD  wrote:

> We have a number of small routers in co-lo sites that peer with B2B
> partners. As more of our partners move to cloud, we are considering a
> consolidation effort and putting all of  our peering routers in a cloud
> exchange site on a single HA pair of routers. Now, each existing B2B
> peering router uses a unique private ASN to EBGP peer with partners and
> they, in turn, EBGP peer with our extranet perimeter ASNs for security
> vetting and other stuff.
>
>
> We looked for a medium-density router (or L3-switch) that can replace
> multiple small routers (b2b-only, no internet), but we need to retain all
> of our existing ASNs and peerings. As it turns out, there are many routers
> that can do VRFs but you cannot put a unique ASN on each VRF so replicating
> the old environment isn't quite that straightforward. The BGP remote-as
> looks to be a possible alternative solution, but we've never used it in
> production and we are unsure of the caveats. Taken at face value, it looks
> like we can mimic the multi-router/unique-ASN environment we have today on
> a single platform. However, networking is rarely as smooth as that so I'm
> asking some of the BGP gurus... what are the pros/cons of doing using
> remote-as? If anyone here uses it extensively, we could really use some
> feedback if you run into challenges or hidden surprises that we wouldn't
> normally think of beforehand.
>
>
> Thanks in advance!
>
>
> LFOD
>

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 06 May, 2017

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  647110
Prefixes after maximum aggregation (per Origin AS):  252103
Deaggregation factor:  2.57
Unique aggregates announced (without unneeded subnets):  311926
Total ASes present in the Internet Routing Table: 57065
Prefixes per ASN: 11.34
Origin-only ASes present in the Internet Routing Table:   49371
Origin ASes announcing only one prefix:   21886
Transit ASes present in the Internet Routing Table:7694
Transit-only ASes present in the Internet Routing Table:219
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  40
Max AS path prepend of ASN ( 55644)  36
Prefixes from unregistered ASNs in the Routing Table:71
Numnber of instances of unregistered ASNs:   75
Number of 32-bit ASNs allocated by the RIRs:  18434
Number of 32-bit ASNs visible in the Routing Table:   14310
Prefixes from 32-bit ASNs in the Routing Table:   57955
Number of bogon 32-bit ASNs visible in the Routing Table:45
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:409
Number of addresses announced to Internet:   2843460964
Equivalent to 169 /8s, 123 /16s and 197 /24s
Percentage of available address space announced:   76.8
Percentage of allocated address space announced:   76.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.6
Total number of prefixes smaller than registry allocations:  216869

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   176804
Total APNIC prefixes after maximum aggregation:   50891
APNIC Deaggregation factor:3.47
Prefixes being announced from the APNIC address blocks:  175990
Unique aggregates announced from the APNIC address blocks:72729
APNIC Region origin ASes present in the Internet Routing Table:8063
APNIC Prefixes per ASN:   21.83
APNIC Region origin ASes announcing only one prefix:   2243
APNIC Region transit ASes present in the Internet Routing Table:   1131
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 40
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2888
Number of APNIC addresses announced to Internet:  763094372
Equivalent to 45 /8s, 123 /16s and 229 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:197305
Total ARIN prefixes after maximum aggregation:94097
ARIN Deaggregation factor: 2.10
Prefixes being announced from the ARIN address blocks:   199402
Unique aggregates announced from the ARIN address blocks: 91373
ARIN Region origin ASes present in the Internet Routing Table:17899
ARIN Prefixes per ASN:  

Re: Need recommendation on an affordable internet edge router

[Bryan Holloway]

+1 on the 7280R

We just started deploying them on our edges for peering and 
port-density. Great little box.


... and their A-Care support has been good and responsive.


On 5/4/17 7:55 PM, Tyler Conrad wrote:

I use the 7280R in production. Love it.

Pros: Cheap, fantastic API, can take (current) full tables of v4 and v6.
6x100G w 48x1/10G gives lots of flexibility.

Cons: Lack of proper VRF support and minimal bgp address families. (If you
want strict isolation, or can use a separate device for route leaking, they
can still do most of what we want).

On Thursday, May 4, 2017, Ken Chase  wrote:


anyone have thoughts about/experience with the Arista 7280R / their
flexroute engine?

/kc

On Thu, May 04, 2017 at 08:39:16PM +, c b said:
  >We have a number of internet edge routers across several data centers
approaching EOL/EOS, and are budgeting for replacements. Like most
enterprises, we have been Cisco-centric in our routing/switching platforms.
The ASR1Ks are too small for our needs and the ASR9Ks are prohibitively
expensive and probably overkill. That being said, our IT staff is willing
to look at other vendors if they are the right fit.
  >
  >
  >Requirements:
  >
  >  *   Can handle full internet tables, both v4 and v6 with room for
reasonable growth over the next 5 years.
  >  *   VRF capability.
  >  *   About 12-ish 10Gb ports and 10-ish 1Gb ports (24-ish total if
they are 1Gb/10Gb select-rate ports.)
  >  *   Full-Feature BGP (address-families, communities, peer-groups,
etc...)
  >  *   Used by carriers or large enterprises in a production role for at
least a year (and not causing ulcers)
  >  *   Affordable. I know that's subjective, but we need a solution that
is as close as possible to commodity-pricing if this modernization effort
balloons to include all of our data centers.
  >
  >We are open to named vendors and even so-called brite-box solutions. A
little nervous about fringe solutions like pure whitebox with Quagga, but
if the savings are there and people can vouch for it, we will consider it.
  >
  >In other words, if you've used it and stand by it, we value that input
and will put it on the initial list. Also, if you chose solution-X after
comparing it to solution-Y it would be very helpful to detail what you
tested and why you chose.
  >
  >Thanks in advance.
  >

--
Ken Chase - m...@sizone.org  Guelph Canada

Question about experiences with BGP remote-AS

[LF OD]

We have a number of small routers in co-lo sites that peer with B2B partners. 
As more of our partners move to cloud, we are considering a consolidation 
effort and putting all of  our peering routers in a cloud exchange site on a 
single HA pair of routers. Now, each existing B2B peering router uses a unique 
private ASN to EBGP peer with partners and they, in turn, EBGP peer with our 
extranet perimeter ASNs for security vetting and other stuff.


We looked for a medium-density router (or L3-switch) that can replace multiple 
small routers (b2b-only, no internet), but we need to retain all of our 
existing ASNs and peerings. As it turns out, there are many routers that can do 
VRFs but you cannot put a unique ASN on each VRF so replicating the old 
environment isn't quite that straightforward. The BGP remote-as looks to be a 
possible alternative solution, but we've never used it in production and we are 
unsure of the caveats. Taken at face value, it looks like we can mimic the 
multi-router/unique-ASN environment we have today on a single platform. 
However, networking is rarely as smooth as that so I'm asking some of the BGP 
gurus... what are the pros/cons of doing using remote-as? If anyone here uses 
it extensively, we could really use some feedback if you run into challenges or 
hidden surprises that we wouldn't normally think of beforehand.


Thanks in advance!


LFOD

Re: Ingress filtering from an external cloud service to the internal network

[Yan Filyurin]

I just read an article about these people.  They are even more interesting
than Illumio or these other VPN solutions. The important part is that you
get to stitch tunnels together on some other host, so the changing IP of
endpoints is irrelevant.

http://zentera.net/



On Fri, May 5, 2017 at 11:13 AM, George William Herbert <
george.herb...@gmail.com> wrote:

> You can usually run OpenVPN from a cloud host. The source IP changing
> possibly should require only one open exception to the local VPN
> termination point.
>
> Better, find a cloud that doesn't do that shit with changing endpoints and
> gives you real VPNs.  What sort of cloud doesn't these days?...?...
>
>
> Sent from my iPhone
>
> > On May 4, 2017, at 10:08 AM, Torres, Matt 
> wrote:
> >
> > Unfortunately, a private connection or VPN to the cloud service provider
> is not available right now, but I can see how that could help solve my
> problem. :-)
> > ~Matt
> >
> >> Is it possible for you to get a private/direct connect service from
> your network perimeter to the cloud provider and eliminate using the public
> connectivity?
> >>
> >> Or because its Internet-based you have to use public connectivity?
>

Re: Ingress filtering from an external cloud service to the internal network

[Yan Filyurin]

Since you can't change the design you may not be able to put some kind of
overlay solution in place, which is just a fancy way of saying a VPN
solution.  What if you look at it in a different way and put some kind of
endpoint security cloud solution like Illumio.

But if you at least had the freedom to put something like this:

http://www.sproute.com/span

in place or 20 other similar solutions. As in you do VPN, but right from
the cloud instance itself or another instance.  There is also a set of
various solutions that do specialized metadata like Cilium, but they get
into container networking and that is definitely application redesign.

On Thu, May 4, 2017 at 1:08 PM, Torres, Matt 
wrote:

> Unfortunately, a private connection or VPN to the cloud service provider
> is not available right now, but I can see how that could help solve my
> problem. :-)
> ~Matt
>
> > Is it possible for you to get a private/direct connect service from your
> network perimeter to the cloud provider and eliminate using the public
> connectivity?
> >
> >Or because its Internet-based you have to use public connectivity?
>

RE: Ingress filtering from an external cloud service to the internal network

[Torres, Matt]

According to my application guy, this is true of the Microsoft O365 hybrid 
solution. It requires direct inbound connections on various ports from largely 
undefined IP space. I imagine the private VPN limitation (i.e., not having a 
VPN) is on our side and MS provides something like this...

>Better, find a cloud that doesn't do that shit with changing endpoints and 
>gives you real VPNs.  What sort of >cloud doesn't these days?...?...

Re: Ingress filtering from an external cloud service to the internal network

[George William Herbert]

You can usually run OpenVPN from a cloud host. The source IP changing possibly 
should require only one open exception to the local VPN termination point.

Better, find a cloud that doesn't do that shit with changing endpoints and 
gives you real VPNs.  What sort of cloud doesn't these days?...?...


Sent from my iPhone

> On May 4, 2017, at 10:08 AM, Torres, Matt  wrote:
> 
> Unfortunately, a private connection or VPN to the cloud service provider is 
> not available right now, but I can see how that could help solve my problem. 
> :-)
> ~Matt
> 
>> Is it possible for you to get a private/direct connect service from your 
>> network perimeter to the cloud provider and eliminate using the public 
>> connectivity? 
>> 
>> Or because its Internet-based you have to use public connectivity?

Static IP allocation schemes for end users (commercial)

[Graham Johnston]

I work for a cable MSO, meaning that our access network is DOCSIS based. 15 
years ago when we had way more IP addresses than customers we had a static IP 
allocation scheme wherein we aligned a /24 with each node and reserved the 
first 20 or so IPs for static assignment, the rest being left for dynamic 
assignment. The primary reason behind this scheme was that as the network grew 
and a node moved from one CMTS to another we could pull the /24 with it and 
customers wouldn't have to re-address.

As our network has grown, in terms of the number of nodes, as well as the 
number of IPs in use we've come to the obvious conclusion that the old scheme 
isn't workable into the future. For instance I will soon have more nodes in 
service than I have /24s allocated to me.

Instead we are entertaining two basic options as an alternative.

  *   Create static reservations, as required, within the otherwise dynamic 
range.
 *   Whether or not the customer continues to DHCP or assigns the IP 
statically doesn't matter to me.
  *   Move to having a single subnet, or portion therein, per CMTS. This keeps 
the process more or less identical to what we do now.

Both of the schemes above would require the customer to undergo addressing 
changes in the event that we move their node between CMTSs in the future.

Can anyone else share what they are doing or otherwise identify if there is a 
best practice in this area?

Thanks,
Graham

Re: Retarus (AS 48328)

[Martin Hannigan]

I heard from the team at Retarus. They were responsive. Much appreciated.

Thanks all.


On Fri, May 5, 2017 at 08:41 Patrick Schultz 
wrote:

> Hi Martin,
> the only address I can point you at is "support at retarus dot com".
> We once had to contact them about a SMTP problem and this was the only
> working contact.
>
> Best,
> Patrick
>
> Am 04.05.17 um 06:31 schrieb Martin Hannigan:
> > I hate to do this, but I have exhausted _all of my sources of data
> > including the SOA (points at VRSN) and domain name contact addresses for:
> >
> > Registrant Name: Retarus GmbH
> > Registrant Organization: Retarus GmbH
> > Registrant Street: Aschauerstrasse 30
> > Registrant City: Muenchen
> > Registrant State/Province: Bav
> > Registrant Postal Code: 81549
> > Registrant Country: DE
> >
> > I worked backwards from a domain name of RMX.DE. I don't know what the
> > distinction is other than this name perhaps being an operational domain
> for
> > their mail security services.
> >
> > If someone has a pointer or can do an offline introduction to someone in
> > tech-ops or networking there, I'd appreciate it.
> >
> > Best,
> >
> > -M<
> >
>
>

TCP over fragmented IPv6 dropped in Comcast's network

[Clint Armstrong]

In troubleshooting why a DNS zone transfer fails over IPv6 from a DNS
master hosted on a Comcast connection, I've discovered that a router in
Comcast's network is IPv6 Fragments with TCP headers.

More specifically it appears that this router silently drops any packet
with a non-zero fragment offset, followed by a tcp header. Packets with a
fragment offset followed by a udp header, or anything else, are passed just
fine. Also, fragments sent in the opposite direction, from outside Comcast
coming in, are passed just fine.

I believe I was able to determine the problematic router by using the
sendip tool to generate these dropped packets and increasing the TTL on the
packet until I no longer got an ICMPv6 unreachable response from the next
hop.

If anyone else with a Comcast IPv6 connection would like to test and see if
your connections are affected by this issue, here is how you can test.

First you need sendip version 2.5-mec-3a2 with the frag.so module.

Start tcpdump or wireshark looking for ICMPv6 Time Exceeded messages.

Then send test packets to any destination IP you'd like to test a route to
using the command `sendip  -p ipv6 -6s  -6h 2  -p
frag -Fo 1 -p tcp`

Increment the 6h value until you no longer get an ICMPv6 Time Exceeded
response. At that point try removing the `-p tcp` parameter and see if that
works. In my case, it does, demonstrating that this problematic router
successfully passes IPv6 fragments without a TCP header.

If anyone at Comcast would like to contact me off-list, I'll share more
details of my findings, including the source address where I'm testing
from, and what I believe is the problematic router.

Re: Retarus (AS 48328)

[Patrick Schultz]

Hi Martin,
the only address I can point you at is "support at retarus dot com".
We once had to contact them about a SMTP problem and this was the only working 
contact.

Best,
Patrick

Am 04.05.17 um 06:31 schrieb Martin Hannigan:
> I hate to do this, but I have exhausted _all of my sources of data
> including the SOA (points at VRSN) and domain name contact addresses for:
> 
> Registrant Name: Retarus GmbH
> Registrant Organization: Retarus GmbH
> Registrant Street: Aschauerstrasse 30
> Registrant City: Muenchen
> Registrant State/Province: Bav
> Registrant Postal Code: 81549
> Registrant Country: DE
> 
> I worked backwards from a domain name of RMX.DE. I don't know what the
> distinction is other than this name perhaps being an operational domain for
> their mail security services.
> 
> If someone has a pointer or can do an offline introduction to someone in
> tech-ops or networking there, I'd appreciate it.
> 
> Best,
> 
> -M<
> 

RE: Ingress filtering from an external cloud service to the internal network

[Torres, Matt]

Unfortunately, a private connection or VPN to the cloud service provider is not 
available right now, but I can see how that could help solve my problem. :-)
~Matt

> Is it possible for you to get a private/direct connect service from your 
> network perimeter to the cloud provider and eliminate using the public 
> connectivity? 
>
>Or because its Internet-based you have to use public connectivity?

Re: Need recommendation on an affordable internet edge router

[Richard Holbo]

I've had no issues with their gear and have used the NE40/80 routers, some
of the switching gear and some FTTP, NE40e will do full tables.  US support
is in Texas and has been good.  Mostly my experience with Huawei support
has been that I don't need it.  Once you get over the learning curve.. it
mostly just makes sense and does what you think it ought to.
/rh

On Thu, May 4, 2017 at 3:26 PM, c b  wrote:

> Can someone toss in a brief testimonial for huawei? In the US, I never
> hear that name in enterprise space, only in carriers. No idea what
> day-to-day ops or support is like with that vendor. All the others I am
> quite familiar with to one degree or another.
>
>
> 
> From: Dragan Jovicic 
> Sent: Thursday, May 4, 2017 3:20 PM
> To: Saku Ytti
> Cc: c b; nanog@nanog.org
> Subject: Re: Need recommendation on an affordable internet edge router
>
> Hi,
>
> But you probably should review at least:
>   - Juniper MX204, MX480
>   - Cisco ASR9k
>   - Huawei NE20, NE40
>   - Alcatel 7750SR
>
> Having all of these somewhere in our network, and my heart being with JNPR
> boxes, I'll say have a look at Huawei offerings.
>
> +Dragan
>
> On Fri, May 5, 2017 at 12:10 AM, Saku Ytti  ytti.fi>> wrote:
> On 5 May 2017 at 01:04, c b > wrote:
>
> Hey,
>
> > The ASR9k is certainly up to the task and it's one of the few we looked
> at
> > initially, but the pricing is nowhere near commodity even if we got a
> > minimal build.
>
> What is commodity? Where are you comparing it to which satisfies your
> requirements?
>
> > As far as volume, the initial purchase for this round of budget will be
> an
> > HA pair. If the solution works well, we have potential to replace 12 or
> so
> > throughout FY17, maybe into FY18.
>
> Yeah sales droids likely won't be interested in 2 at all. But if you
> commit on those 12, even if you'll order them separately. I think
> that's something sales droid will care about, and you'll have
> negotiation leverage as you can keep bouncing between several vendors
> seeing who gets your business.
> You should really expect at least 70% discount on 12 units, 80% would
> be good. Under 70% would be walk out the room.
>
> --
>   ++ytti
>
>