Re: Anyone from Facebook here?

[Joly MacFie]

Robert Pepper is now working for fb.

​Don't have an email.

​

On Tue, Oct 11, 2016 at 6:09 PM, Mark Andrews  wrote:

>
> You may want to follow up on this email thread.  IPv6 vs IPv4 performance
> to m.facebook.com.
>
> https://www.mail-archive.com/bind-users@lists.isc.org/msg23649.html
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE:  +61 2 9871 4742 INTERNET: ma...@isc.org
>



-- 
---
Joly MacFie  218 565 9365 Skype:punkcast
--
-

Re: nested prefixes in Internet

[Owen DeLong]

> On Oct 10, 2016, at 14:59 , Baldur Norddahl  wrote:
> 
> 
> 
> Den 10/10/2016 kl. 22.27 skrev Owen DeLong:
>> Not true… There are myriad reasons that the /24 might not reach a network 
>> peered with ISP-A, including the possibility of being a downstream customer 
>> of a network peered with or buying transit from ISP-A. In the latter case, 
>> not an issue, since it’s paid transit, but in the former (peered, not 
>> transit), again, ISP-A is probably not super excited to carry traffic that 
>> someone isn’t paying them to carry.
>> 
> 
> But ISP-A is in fact being paid to carry the traffic. Supposedly ISP-B has a 
> paid transit relation to ISP-A. In the case the transit link is down ISP-A 
> might have to transport the traffic through a less profitable link however.

Which isn’t really in the agreement between ISP-B and ISP-A unless it was 
specifically (and unusually) negotiated.

Also, you’re assuming that the leased space came with a transit agreement. In 
many cases, address leases don’t, so consider the additional scenario where 
ISP-B leases addresses from ISP-A, but has transit contracts with ISP-C and 
ISP-D but no connection at all to ISP-A.

> I know that if ISP-A was my network I would be making money even with the 
> transit link down. Yes I might have to transport something out of my network 
> through one of my transits, but outbound traffic is in fact free for us 
> because we are heavy inbound loaded.

Yes, but it doesn’t help if it also came in on a transit link. Any traffic you 
both receive and transmit on transit costs you money pretty much no matter who 
you are.


Owen

Anyone from Facebook here?

[Mark Andrews]

You may want to follow up on this email thread.  IPv6 vs IPv4 performance
to m.facebook.com.

https://www.mail-archive.com/bind-users@lists.isc.org/msg23649.html

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:  +61 2 9871 4742  INTERNET: ma...@isc.org

Re: List of US server providers?

[Carlos Kamtha]

thanks! 

-C

On Tue, Oct 11, 2016 at 11:25:50AM -0500, John Kristoff wrote:
> On Tue, 11 Oct 2016 14:23:19 +
> Carlos Kamtha  wrote:
> 
> > Was wondering if anyone can point me to a current list of
> > dedicated/VPS providers in the US. That is, if such a list exists...
> 
> I'm not sure such a comprehensive and regularly maintained list is
> available, and I'm not sure it could be.  It would be very large and
> difficult to keep current.  You can find many providers advertised or
> discussed in web-based forums such as Web Hosting Talk or Low End Talk.
> 
> I maintain a small subset and woefully incomplete list of providers,
> most of which have some U.S. presence, but not necessarily all, that
> I've had some recent experience with here:
> 
>   
> 
> John

Re: Large BGP Communities beacon in the wild

[Baldur Norddahl]

Hi

This looks like this on the ZTE M6000 platform:

ballerup-edge1#show bgp vpnv4 unicast vrf internet detail 192.147.168.0 
255.255.255.0

BGP routing table entry for 192.147.168.0/24
25w4d received from 149.6.136.169 (154.26.32.23), path-id 0
   Origin i, nexthop 149.6.136.169, metric 100, localpref 100,weight 0, 
rtpref 200, best, block best, selected,

   Community 174:21100 174:22010 60876:174
*Unknown attribute type 30 flag e0 len 12*
   As path [174 2914 15562]
   As4 path
   Received label  notag

25w4d received from 216.66.83.101 (216.218.252.202), path-id 0
   Origin i, nexthop 216.66.83.101, metric 25, localpref 100,weight 0, 
rtpref 200,

   Community 60876:6939
*Unknown attribute type 30 flag e0 len 12*
   As path [6939 1299 2914 15562]
   As4 path
   Received label  notag



Regards,

Baldur

Den 11/10/2016 kl. 17.01 skrev Job Snijders:

Dear all,

Large BGP Communities are a novel way to signal information between
networks. An example of a Large BGP Communities is: 2914:4056024901:80.

Large BGP Communities are composed of three 4-octet integers, separated
by something like a colon. This is easy to remember and accommodates
advanced routing policies in relation to 4-Byte ASNs. It is the tool that has
been missing since 4-octet ASNs were introduced.

IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in
the "BGP Path Attributes" registry under the "Border Gateway Protocol
(BGP) Parameters" group.

The draft can be read here: 
https://tools.ietf.org/html/draft-ietf-idr-large-community

Additional information about Large BGP Communities can be found here:
http://largebgpcommunities.net/

Starting today (2016.10.11), the following two BGP beacons are available
to the general public, with AS_PATH 2914_15562$

 Both these prefixes have a Large BGP Community attached:

 2001:67c:208c::/48
 192.147.168.0/24

 Large BGP Community - 15562:1:1

The NLNOG RING BGP Looking Glass is running the latest version of BIRD
which understands the Large BGP Community Path Attribute.

IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24
IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48

In theory, since this is an optional transitive BGP Path Attribute, all
the Looking Glass' peers should boomerang the Large Community back to
the LG.  However we currently observe that 50 out of 75 peers propagate
the Large BGP Community to the LG.

Relevant Router commands to see if you receive the attribute, or whether
one of intermediate networks has stripped the attribute from the route:
 
 IOS: show ip bgp path-attribute unknown

 shows all prefixes with unknown path attributes.

IOS #2 - like on route views:
route-views>sh ip bgp 192.147.168.0
 BGP routing table entry for 192.147.168.0/24, version 98399100
 Paths: (39 available, best #30, table default)
   Not advertised to any peer
   Refresh Epoch 1
   701 2914 15562
 137.39.3.55 from 137.39.3.55 (137.39.3.55)
   Origin IGP, localpref 100, valid, external
   unknown transitive attribute: flag 0xE0 type 0x1E 
length 0xC
 value  3CCA  0001  0001
   rx pathid: 0, tx pathid: 0

 IOS-XR: (you must look at specific prefixes)
 RP/0/RSP0/CPU0:Router#show bgp  ipv6 unicast 2001:67c:208c::/48 
unknown-attributes
 BGP routing table entry for 2001:67c:208c::/48
 Community: 2914:370 2914:1206 2914:2203 2914:3200
 Unknown attributes have size 15
 Raw value:
 e0 1e 0c 00 00 3c ca 00 00 00 01 00 00 00 01
 
 
 JunOS:

 user@JunOS-re6> show route 2001:67c:208c::/48 detail
 2001:67c:208c::/48 (1 entry, 1 announced)
 AS path: 15562 I
 Unrecognized Attributes: 15 bytes
 Attr flags e0 code 1e: 00 00 3c ca 00 00 00 01 00 00 00 01
^^^

A note about router Configurations:
 
Ensure you are not fitlering the path attributes, eg:


JunOS:
 [edit protocols bgp]
 user@junos# delete drop-path-attributes 30

XR:
 configure
 router bgp YourASN
 attribute-filter group ReallyBadIdea ! avoid creating bogons
 no attribute 30
   !
 !

Contact persons: myself or Jared Mauch or NTT NOC. BGP Session
identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562.

Kind regards,

Job

Re: List of US server providers?

[John Kristoff]

On Tue, 11 Oct 2016 14:23:19 +
Carlos Kamtha  wrote:

> Was wondering if anyone can point me to a current list of
> dedicated/VPS providers in the US. That is, if such a list exists...

I'm not sure such a comprehensive and regularly maintained list is
available, and I'm not sure it could be.  It would be very large and
difficult to keep current.  You can find many providers advertised or
discussed in web-based forums such as Web Hosting Talk or Low End Talk.

I maintain a small subset and woefully incomplete list of providers,
most of which have some U.S. presence, but not necessarily all, that
I've had some recent experience with here:

  

John

Large BGP Communities beacon in the wild

[Job Snijders]

Dear all,

Large BGP Communities are a novel way to signal information between
networks. An example of a Large BGP Communities is: 2914:4056024901:80.

Large BGP Communities are composed of three 4-octet integers, separated
by something like a colon. This is easy to remember and accommodates
advanced routing policies in relation to 4-Byte ASNs. It is the tool that has
been missing since 4-octet ASNs were introduced.

IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) in
the "BGP Path Attributes" registry under the "Border Gateway Protocol
(BGP) Parameters" group.

The draft can be read here: 
https://tools.ietf.org/html/draft-ietf-idr-large-community

Additional information about Large BGP Communities can be found here:
http://largebgpcommunities.net/

Starting today (2016.10.11), the following two BGP beacons are available
to the general public, with AS_PATH 2914_15562$

Both these prefixes have a Large BGP Community attached:

2001:67c:208c::/48
192.147.168.0/24

Large BGP Community - 15562:1:1

The NLNOG RING BGP Looking Glass is running the latest version of BIRD
which understands the Large BGP Community Path Attribute.

IPv4 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.147.168.0/24
IPv6 LG: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:67c:208c::/48

In theory, since this is an optional transitive BGP Path Attribute, all
the Looking Glass' peers should boomerang the Large Community back to
the LG.  However we currently observe that 50 out of 75 peers propagate
the Large BGP Community to the LG.

Relevant Router commands to see if you receive the attribute, or whether
one of intermediate networks has stripped the attribute from the route:

IOS: show ip bgp path-attribute unknown 
shows all prefixes with unknown path attributes.

IOS #2 - like on route views:
route-views>sh ip bgp 192.147.168.0
 BGP routing table entry for 192.147.168.0/24, version 98399100
 Paths: (39 available, best #30, table default)
   Not advertised to any peer
   Refresh Epoch 1
   701 2914 15562
 137.39.3.55 from 137.39.3.55 (137.39.3.55)
   Origin IGP, localpref 100, valid, external
   unknown transitive attribute: flag 0xE0 type 0x1E 
length 0xC
 value  3CCA  0001  0001
   rx pathid: 0, tx pathid: 0
 
IOS-XR: (you must look at specific prefixes)
RP/0/RSP0/CPU0:Router#show bgp  ipv6 unicast 2001:67c:208c::/48 
unknown-attributes 
BGP routing table entry for 2001:67c:208c::/48
Community: 2914:370 2914:1206 2914:2203 2914:3200
Unknown attributes have size 15
Raw value:
e0 1e 0c 00 00 3c ca 00 00 00 01 00 00 00 01 


JunOS:
user@JunOS-re6> show route 2001:67c:208c::/48 detail 
2001:67c:208c::/48 (1 entry, 1 announced)
AS path: 15562 I
Unrecognized Attributes: 15 bytes
Attr flags e0 code 1e: 00 00 3c ca 00 00 00 01 00 00 00 01
   ^^^

A note about router Configurations:

Ensure you are not fitlering the path attributes, eg:

JunOS:
[edit protocols bgp]
user@junos# delete drop-path-attributes 30

XR:
configure
router bgp YourASN
attribute-filter group ReallyBadIdea ! avoid creating bogons
no attribute 30 
  !
!

Contact persons: myself or Jared Mauch or NTT NOC. BGP Session
identifier 83.231.213.230 / 2001:728:0:5000::a92 AS 15562.

Kind regards,

Job

List of US server providers?

[Carlos Kamtha]

Hello Everyone,

Was wondering if anyone can point me to a current list of dedicated/VPS 
providers in the US. That is, if such a list exists...

Any help would be greatly appreciated.

Cheers.

-C

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

[Lee]

On 10/10/16, Jay Hennigan  wrote:
> On 10/6/16 1:26 PM, Jesse McGraw wrote:
>> Nanog,
>>
>> (This is me scratching an itch of my own and hoping that sharing it
>> might be useful to others on this list.  Apologies if it isn't)
>>
>>   When I'm trying to comprehend a new or complicated Cisco router,
>> switch or firewall configuration an old pet-peeve of mine is how
>> needlessly difficult it is to follow deeply nested logic in route-maps,
>> ACLs, QoS policy-maps etc etc
>>
>> To make this a bit simpler I’ve been working on a perl script to convert
>> these text-based configuration files into HTML with links between the
>> different elements (e.g. To an access-list from the interface where it’s
>> applied, from policy-maps to class-maps etc), hopefully making it easier
>> to to follow the chain of logic via clicking links and using the forward
>> and back buttons in your browser to go back and forth between command
>> and referenced list.
>
> Way cool. Now to hook it into RANCID

It looks like what I did in 2.3.8 should still work - control_rancid
puts the diff output into $TMP.diff so add this bit:
grep "^Index: " $TMP.diff | awk '/^Index: configs/{
 if ( ! got1 ) { printf("/usr/local/bin/myscript.sh "); got1=1; }
 printf("%s ", $2)
 }
 END{ printf("\n") }
' >$TMP.doit
/bin/sh $TMP.doit >$TMP.out
if [ -s $TMP.out ] ; then
   .. send mail / whatever
rm $TMP.doit $TMP.out
fi

Regards,
Lee

Re: A perl script to convert Cisco IOS/Nexus/ASA configurations to HTML for easier comprehension

[Lee]

On 10/8/16, Hank Nussbacher  wrote:
> On 07/10/2016 17:59, Lee wrote:
>> On 10/7/16, Hank Nussbacher  wrote:
>>> On 07/10/2016 00:33, Lee wrote:
 dunno about creating web pages, but
 https://www.nanog.org/meetings/abstract?id=785
 has a section on showing filters that are defined but not referenced &
 referenced but not defined
>>> In IOS-XR it is one command "sho rpl unused ?"
>>> RP/0/RSP0/CPU0:petach-tikva-gp#show rpl unused ?
>>>   as-path-set   Display as-path-set objects
>>>   community-set Display community-set objects
>>>   extcommunity-set  Display extended community objects
>>>   prefix-setDisplay prefix-set objects
>>>   rd-setDisplay rd-set objects
>>>   route-policy  Display route-policy objects
>>>   tag-set   Display tag-set objects
>>>
>>> RP/0/RSP0/CPU0:petach-tikva-gp#show rpl unused prefix
>>> Fri Oct  7 08:24:53.237 IDT
>>>
>>> ACTIVE -- Referenced by at least one policy which is attached
>>> INACTIVE -- Only referenced by policies which are not attached
>>> UNUSED -- Not attached (directly or indirectly) and not referenced
>> I'm actually starting to miss being out of the game.  I'm retired, so
>> don't have access to anything running IOS-XR.  Just out of curiosity,
>> how does the output of 'show rpl unused prefix' compare to the output
>> of the script at  http://pastebin.com/pem7tHAJ
>>
>> Thanks,
>> Lee
>>
> Samples:
>
   <.. snip samples ..>
  interesting.. thanks!

> Note the sloppy code - sometimes they state UNUSED and sometimes
> (UNUSED).  Or "the following policies are"... rather than "the following
> routing policies are".  Just plain sloppy Cisco coding and poor QA.  And
> once you delete these unreferenced objects, "show rpl unused" will still
> show them since there is a bug in Cisco code (CSCuy07932/CSCug9153). See:
> http://www.gossamer-threads.com/lists/cisco/nsp/192481
> for details.

Which is why I like having the source code -- there's the possibility
of fixing whatever myself instead of having to wait for the vendor to
fix it :)

Thanks,
Lee

Re: nested prefixes in Internet

[Jimmy Hess]

On Mon, Oct 10, 2016 at 12:24 PM, Niels Bakker