Re: Level3 IPv6 peering with HE only in London?

[Anurag Bhatia]

I emailed about this to friends at HE yesterday. Heard they are working on
it.


I can see forwward as well as reverse paths via Europe - so very likely
they lost connectivity/BGP session with Level3 in US or something like that.


Let's see how it goes.

On Thu, Apr 12, 2012 at 9:46 AM, Derek Ivey  wrote:

> I'm seeing the same thing from my area (Harrisburg, PA). Strange.
>
> *Show Level 3 (Harrisburg, PA) Traceroute to www.he.net*
>  1 
> vl-17.car1.Pittsburgh3.Level3.**net(2001:1900:35::21)
>  208 msec 200 msec 276 msec
>  2 
> vl-4044.car1.Washington1.**Level3.net(2001:1900:4:1::2B9)
>  48 msec 208 msec 200 msec
>  3 
> vl-4083.car2.Washington1.**Level3.net(2001:1900:4:1::DE)
>  200 msec 312 msec 104 msec
>  4 
> vl-4061.car1.NewYork2.Level3.**net(2001:1900:4:1::106)
>  160 msec 100 msec 124 msec
>  5 
> vl-4041.car1.NewYork1.Level3.**net(2001:1900:4:1::101)
>  80 msec 156 msec 56 msec
>  6 
> vl-4086.edge3.London1.Level3.**net(2001:1900:6:1::11)
>  212 msec 116 msec 248 msec
>  7 
> vl-4081.edge4.London1.Level3.**net(2001:1900:5:1::106)
>  200 msec
>
> vl-4081.edge3.London1.Level3.**net(2001:1900:5:1::102)
>  200 msec 204 msec
>  8 2001:1900:5:3::11E 208 msec 204 msec 208 msec
>  9 
> 10gigabitethernet7-4.core1.**nyc4.he.net(2001:470:0:128::1)
>  204 msec 40 msec 200 msec
>  10 
> 10gigabitethernet5-3.core1.**lax1.he.net(2001:470:0:10E::1)
>  408 msec 404 msec 260 msec
>  11 
> 10gigabitethernet7-4.core1.**fmt2.he.net(2001:470:0:18D::1)
>  368 msec 380 msec 416 msec
>  12 
> 10gigabitethernet2-1.core1.**fmt1.he.net(2001:470:0:2D::1)
>  256 msec 400 msec 224 msec
>
> C:\Users\Derek>tracert 2001:1900:35::21 (from my HE tunnel)
>
> Tracing route to 
> vl-17.car1.Pittsburgh3.Level3.**net[2001:1900:35::21]
> over a maximum of 30 hops:
> ...
>  316 ms14 ms21 ms  gige-g4-12.core1.ash1.he.net[2001:470:0:90::1]
>  425 ms25 ms24 ms  
> 10gigabitethernet1-2.core1.**nyc4.he.net[2001:470:0:36::2]
>  588 ms90 ms98 ms  
> 10gigabitethernet1-2.core1.**lon1.he.net[2001:470:0:128::2]
>  688 ms89 ms89 ms  
> ge-5-3-2.edge4.London.Level3.**net[2001:1900:5:3::11d]
>  788 ms89 ms89 ms  
> vl-4080.edge4.London1.Level3.**net[2001:1900:5:1::105]
>  8   158 ms   158 ms   158 ms  
> vl-4086.car1.NewYork1.Level3.**net[2001:1900:6:1::12]
>  9   163 ms   163 ms   163 ms  
> ae-2-4047.edge2.Washington12.**Level3.net[2001:1900:4:1::3b9]
>  10   163 ms   163 ms   163 ms  
> ae-1-4080.edge1.Washington12.**Level3.net[2001:1900:4:1::3d9]
>  11   164 ms   164 ms   164 ms  
> vl-4046.car1.Washington1.**Level3.net[2001:1900:4:1::3b2]
>  12   177 ms   177 ms   187 ms  
> vl-17.car1.Pittsburgh3.Level3.**net[2001:1900:35::21]
>
> Trace complete.
>
>
>
> On 4/12/2012 12:08 AM, Dave Sotnick wrote:
>
>> Hello Nanog,
>>
>> Looks like Level3's only IPv6 route to HE is via London right now:
>>
>> Show Level 3 (Las Vegas, NV) Traceroute to www.he.net
>>  1 vl-5.bar1.LasVegas1.Level3.net (2001:1900:2F::1) 0 msec 0 msec 0 msec
>>  2 
>> vl-11.bar2.LasVegas1.Level3.**net(2001:1900:4:1::3C6)
>>  0 msec 0 msec 0 msec
>>  3 
>> vl-4045.car1.Denver1.Level3.**net(2001:1900:4:1::276)
>>  84 msec 228
>> msec 224 msec
>>  4 
>> vl-4081.car2.Denver1.Level3.**net(2001:1900:4:1::32)
>>  20 msec 20 msec 20 msec
>>  5 
>> vl-4042.edge1.Chicago2.Level3.**net(2001:1900:4:1::36)
>>  44 msec 44 msec 44 msec
>>  6 
>> vl-4067.car1.Chicago1.Level3.**net(2001:1900:4:1::1D)
>>  48 msec 212
>> msec 224 msec
>>  7 
>> vl-4061.car2.NewYork2.Level3.**net(2001:1900:4:1::22)
>>  184 msec 216
>> msec 232 msec
>>  8 
>> vl-4080.car1.NewYork2.Level3.**net(2001:1900:4:1::F1)
>>  80 msec 80 msec 80 msec
>>  9 
>> vl-4041.car1.NewYork1.Level3.**net(2001:19

Re: Level3 IPv6 peering with HE only in London?

[Derek Ivey]

I'm seeing the same thing from my area (Harrisburg, PA). Strange.

*Show Level 3 (Harrisburg, PA) Traceroute to www.he.net*
  1 vl-17.car1.Pittsburgh3.Level3.net (2001:1900:35::21) 208 msec 200 
msec 276 msec
  2 vl-4044.car1.Washington1.Level3.net (2001:1900:4:1::2B9) 48 msec 
208 msec 200 msec
  3 vl-4083.car2.Washington1.Level3.net (2001:1900:4:1::DE) 200 msec 
312 msec 104 msec
  4 vl-4061.car1.NewYork2.Level3.net (2001:1900:4:1::106) 160 msec 100 
msec 124 msec
  5 vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101) 80 msec 156 
msec 56 msec
  6 vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11) 212 msec 116 
msec 248 msec

  7 vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106) 200 msec
vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102) 200 msec 204 msec
  8 2001:1900:5:3::11E 208 msec 204 msec 208 msec
  9 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) 204 msec 
40 msec 200 msec
 10 10gigabitethernet5-3.core1.lax1.he.net (2001:470:0:10E::1) 408 msec 
404 msec 260 msec
 11 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18D::1) 368 msec 
380 msec 416 msec
 12 10gigabitethernet2-1.core1.fmt1.he.net (2001:470:0:2D::1) 256 msec 
400 msec 224 msec


C:\Users\Derek>tracert 2001:1900:35::21 (from my HE tunnel)

Tracing route to vl-17.car1.Pittsburgh3.Level3.net [2001:1900:35::21]
over a maximum of 30 hops:
...
  316 ms14 ms21 ms  gige-g4-12.core1.ash1.he.net 
[2001:470:0:90::1]
  425 ms25 ms24 ms  10gigabitethernet1-2.core1.nyc4.he.net 
[2001:470:0:36::2]
  588 ms90 ms98 ms  10gigabitethernet1-2.core1.lon1.he.net 
[2001:470:0:128::2]
  688 ms89 ms89 ms  ge-5-3-2.edge4.London.Level3.net 
[2001:1900:5:3::11d]
  788 ms89 ms89 ms  vl-4080.edge4.London1.Level3.net 
[2001:1900:5:1::105]
  8   158 ms   158 ms   158 ms  vl-4086.car1.NewYork1.Level3.net 
[2001:1900:6:1::12]
  9   163 ms   163 ms   163 ms  ae-2-4047.edge2.Washington12.Level3.net 
[2001:1900:4:1::3b9]
 10   163 ms   163 ms   163 ms  ae-1-4080.edge1.Washington12.Level3.net 
[2001:1900:4:1::3d9]
 11   164 ms   164 ms   164 ms  vl-4046.car1.Washington1.Level3.net 
[2001:1900:4:1::3b2]
 12   177 ms   177 ms   187 ms  vl-17.car1.Pittsburgh3.Level3.net 
[2001:1900:35::21]


Trace complete.


On 4/12/2012 12:08 AM, Dave Sotnick wrote:

Hello Nanog,

Looks like Level3's only IPv6 route to HE is via London right now:

Show Level 3 (Las Vegas, NV) Traceroute to www.he.net
  1 vl-5.bar1.LasVegas1.Level3.net (2001:1900:2F::1) 0 msec 0 msec 0 msec
  2 vl-11.bar2.LasVegas1.Level3.net (2001:1900:4:1::3C6) 0 msec 0 msec 0 msec
  3 vl-4045.car1.Denver1.Level3.net (2001:1900:4:1::276) 84 msec 228
msec 224 msec
  4 vl-4081.car2.Denver1.Level3.net (2001:1900:4:1::32) 20 msec 20 msec 20 msec
  5 vl-4042.edge1.Chicago2.Level3.net (2001:1900:4:1::36) 44 msec 44 msec 44 
msec
  6 vl-4067.car1.Chicago1.Level3.net (2001:1900:4:1::1D) 48 msec 212
msec 224 msec
  7 vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22) 184 msec 216
msec 232 msec
  8 vl-4080.car1.NewYork2.Level3.net (2001:1900:4:1::F1) 80 msec 80 msec 80 msec
  9 vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101) 80 msec 80 msec 80 
msec
  10 vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11) 176 msec 144
msec 164 msec
  11 vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102) 136 msec 132 msec
vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106) 148 msec
  12 2001:1900:5:3::11E 160 msec 156 msec 160 msec
  13 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) 344
msec 208 msec 200 msec
  14 10gigabitethernet5-3.core1.lax1.he.net (2001:470:0:10E::1) 276
msec 260 msec 268 msec
  15 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18D::1) 272
msec 272 msec 324 msec
  16 10gigabitethernet2-1.core1.fmt1.he.net (2001:470:0:2D::1) 288 msec
272 msec 276 msec
  17  *  *  *
  18  *  *  *

Confirmed by L3's looking glasses (
http://lg.level3.net/traceroute/traceroute.cgi?site=lvg1&target=www.he.net&ipv6=true
) and my own corporate IPv6 connection from Level 3.

I opened a ticket with Level 3. Anyone else seen this?

-Dave

Level3 IPv6 peering with HE only in London?

[Dave Sotnick]

Hello Nanog,

Looks like Level3's only IPv6 route to HE is via London right now:

Show Level 3 (Las Vegas, NV) Traceroute to www.he.net
 1 vl-5.bar1.LasVegas1.Level3.net (2001:1900:2F::1) 0 msec 0 msec 0 msec
 2 vl-11.bar2.LasVegas1.Level3.net (2001:1900:4:1::3C6) 0 msec 0 msec 0 msec
 3 vl-4045.car1.Denver1.Level3.net (2001:1900:4:1::276) 84 msec 228
msec 224 msec
 4 vl-4081.car2.Denver1.Level3.net (2001:1900:4:1::32) 20 msec 20 msec 20 msec
 5 vl-4042.edge1.Chicago2.Level3.net (2001:1900:4:1::36) 44 msec 44 msec 44 msec
 6 vl-4067.car1.Chicago1.Level3.net (2001:1900:4:1::1D) 48 msec 212
msec 224 msec
 7 vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22) 184 msec 216
msec 232 msec
 8 vl-4080.car1.NewYork2.Level3.net (2001:1900:4:1::F1) 80 msec 80 msec 80 msec
 9 vl-4041.car1.NewYork1.Level3.net (2001:1900:4:1::101) 80 msec 80 msec 80 msec
 10 vl-4086.edge3.London1.Level3.net (2001:1900:6:1::11) 176 msec 144
msec 164 msec
 11 vl-4081.edge3.London1.Level3.net (2001:1900:5:1::102) 136 msec 132 msec
   vl-4081.edge4.London1.Level3.net (2001:1900:5:1::106) 148 msec
 12 2001:1900:5:3::11E 160 msec 156 msec 160 msec
 13 10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) 344
msec 208 msec 200 msec
 14 10gigabitethernet5-3.core1.lax1.he.net (2001:470:0:10E::1) 276
msec 260 msec 268 msec
 15 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18D::1) 272
msec 272 msec 324 msec
 16 10gigabitethernet2-1.core1.fmt1.he.net (2001:470:0:2D::1) 288 msec
272 msec 276 msec
 17  *  *  *
 18  *  *  *

Confirmed by L3's looking glasses (
http://lg.level3.net/traceroute/traceroute.cgi?site=lvg1&target=www.he.net&ipv6=true
) and my own corporate IPv6 connection from Level 3.

I opened a ticket with Level 3. Anyone else seen this?

-Dave

Re: Cheap Juniper Gear for Lab

[Robert E. Seastrom]

sth...@nethelp.no writes:

>> Anyway, not the best devices for an edge router that is for sure.
>> Which is too bad...  for very small DC edge applications, the J6350
>> was a pretty cool router in earlier versions of JunOS that didn't
>> decide to re-engineer your network and transit for you.
>
> We have 3 J2320s in the lab, all running 9.3R3.8. That's the last
> *real* JunOS (no session/flow tracking) for these boxes.
>
> They'll stay in the lab, and they'll never be upgraded to anything
> newer. Which is too bad, I had great hopes for the J series.

Got a pair of J2350s in the previous job to run as part of a command
and control network.  Had the same "I just want this stuff to route!"
experience that others have mentioned and griped about.

We tried running on 9.3 but - surprise - 9.3 won't do 32 bit ASNs.
That came in 10.1 or something.  As a member of the ARIN Advisory
Council, I felt compelled to eat the same dog food that I was selling,
and we found ourselves at an impasse.

We ended up putting the C&C network in VRFs on a couple of MX80s that
were already there.  With a few contemptuous comments on the side we
sent the 2350s back to the VAR.

I think my successors ended up undoing the VRFs and putting Cisco
2951s in their place.

I've heard it hypothesized that this change was related to the costs
of maintaining two different packet forwarding paths (remember that
the J series used, in 9.3 and before, an emulation of the ASIC in the
hardware based routers) and that, having decided to cancel one, they
decided to cancel the "less featureful" one.  This is a reasonable
decision to make even if we don't like it as techies.

None of the difficulties we had, however, would have gotten in the way
of the OP's apparent goal of getting comfortable typing things like
"show chassis environment", "request system software add", "show
config | display set", and "show version and haiku".

Unlike Owen I'm not going to say "useless due to security { ... }",
I'm going to say "useful with caveats, and you might want to think
twice about what you're trying to do before moving it out of the lab".

-r

Re: IPv6 support via Charter | Ideas on BGP Tunnel via HE

[Owen DeLong]

On Apr 11, 2012, at 2:14 PM, Charles N Wyble wrote:

> On 04/11/2012 02:34 PM, Seth Mos wrote:
>> 
>> 
>> I'm getting about 40mbit through the IPv6 tunnel, so i'd say it works well, 
>> although the throughput has slowly been dropping to the 30's range over the 
>> last 6 months. But that's probably because of the latency.
>> 
>> For something that is provided for free I'm really glad we have it.
> 
> Indeed. It's pretty amazing what HE has put together.
> 
>> I should have peered with their UK PoP as it's much closer by latency, thus 
>> faster.
> 
> Why don't you? Can you setup more then one peering?
> 
> 

Yes... Many of our customers set up multiple peerings.

Owen

Re: IPv6 support via Charter | Ideas on BGP Tunnel via HE

[Jared Mauch]

On Apr 11, 2012, at 6:19 PM, William Herrin wrote:

> On Wed, Apr 11, 2012 at 5:41 PM, Jared Mauch  wrote:
>> This is a big problem for the two providers involved in this "spat" having
>> inconsistent IPv4/IPv6 business relationships (peering, etc).
>> 
>> There are many professional service providers that will happily dual-stack
>> your internet port with consistent business relationships.  Don't let these
>> two parties that so far have agreed to disagree prevent you from using IPv6
>> to its fullest.  Select another carrier.
> 
> Hi Jared,
> 
> Is it really fair to say there are "two" parties in a peering spat
> when Cogent is one of them?

I know that the following IPv4 as-paths appear to enumerate transit paths where 
the providers can do IPv6 transit as well.

If HE does not take advantage of those existing IP transit connections for 
whichever IP version I'm not sure where I would cast blame.  Perhaps those 
ports don't have IPv6.  I have my own opinions about peering disputes which you 
can obtain privately.

route-views>sh ip bgp 216.218.186.2
BGP routing table entry for 216.218.128.0/17, version 417045
Paths: (35 available, best #26, table Default-IP-Routing-Table)
...snip...
  1239 3549 6939 6939
144.228.241.130 from 144.228.241.130 (144.228.241.130)
  Origin IGP, localpref 100, valid, external
  2914 1299 6939 6939
129.250.0.11 from 129.250.0.11 (129.250.0.12)
  Origin IGP, metric 5, localpref 100, valid, external
  Community: 2914:420 2914:1008 2914:2000 2914:3000 65504:1299
  3356 3549 6939 6939
4.69.184.193 from 4.69.184.193 (4.68.3.50)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 3356:3 3356:22 3356:86 3356:575 3356:666 3356:2012 3549:4143 
3549:30840
  701 1299 6939 6939
157.130.10.233 from 157.130.10.233 (137.39.3.60)
  Origin IGP, localpref 100, valid, external
  1668 3549 6939 6939
66.185.128.48 from 66.185.128.48 (66.185.128.48)
  Origin IGP, metric 7, localpref 100, valid, external
  7018 1299 6939 6939
12.0.1.63 from 12.0.1.63 (12.0.1.63)
  Origin IGP, localpref 100, valid, external
  Community: 7018:5000
  3257 1299 6939 6939
89.149.178.10 from 89.149.178.10 (213.200.87.91)
  Origin IGP, metric 10, localpref 100, valid, external
  Community: 3257:8100 3257:30052 3257:50001 3257:54900 3257:54901
  3561 3549 6939 6939
206.24.210.102 from 206.24.210.102 (206.24.210.102)
  Origin IGP, localpref 100, valid, external
  6453 3549 6939 6939
66.110.0.86 from 66.110.0.86 (66.110.0.86)
  Origin IGP, localpref 100, valid, external

Re: IPv6 support via Charter | Ideas on BGP Tunnel via HE

[William Herrin]

On Wed, Apr 11, 2012 at 5:41 PM, Jared Mauch  wrote:
> This is a big problem for the two providers involved in this "spat" having
> inconsistent IPv4/IPv6 business relationships (peering, etc).
>
> There are many professional service providers that will happily dual-stack
> your internet port with consistent business relationships.  Don't let these
> two parties that so far have agreed to disagree prevent you from using IPv6
> to its fullest.  Select another carrier.

Hi Jared,

Is it really fair to say there are "two" parties in a peering spat
when Cogent is one of them?

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Cheap Juniper Gear for Lab

[Jeff Richmond]

FWIW, when I took my JNCIE, I used all J-series running flow code (disabled) 
for my study pod and never had any issues. I have 9 physical routers plus a 
bunch of VRs on them. I agree there can be issues depending on what you are 
trying to do, but I am not sure why this is such a big deal if this is just a 
lab setup. I wouldn't test something on a J-series and expect to deploy it on 
M/MX/T in production or something, but that wasn't what the OP was asking to 
do. For a home lab I can't think of any reason not to use some J-series boxes. 

-Jeff

On Apr 11, 2012, at 1:29 PM, Leigh Porter wrote:

> 
> On 11 Apr 2012, at 18:36, "Carl Rosevear"  wrote:
> 
>> Yeah, I have to apply the term "awful" and "annoying" to the packet
>> mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC
>> on the phone trying to get the thing to just pass packets.  Best part
>> was, I didn't know how to do it and nor did they!  I escalated, worked
>> with many engineers.  My key statement was "I just want my router to
>> route.  Make it do what it is supposed to do.  No session tracking!
>> This is not a firewall."  So, now it doesn't require valid sessions to
>> pass packets but it does still appear to *track* sessions in some
>> tables and I am, of course, very curious when some attack vector will
>> fill up some table.
>> 
> 
> I have had some rather odd issues with the SRX boxes but JTAC were pretty 
> good at turning around fixes for me for my specific issues.
> 
> Since then I have had quite a lot of SRX boxes across the range running 
> various MPLS services including MPLS over GRE with fragmentation/reassembly 
> which has been working very well. Since 11.1R3 I've had no issues at all with 
> them.
> 
> So yeah the new flow mode stuff had its issues, but as a *small* MPLS box it 
> is very functional. Of course in MPLS mode, you turn the flow stuff off..
> 
> 
> --
> Leigh Porter
> 
> 
> 
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
> 

Re: IPv6 support via Charter | Ideas on BGP Tunnel via HE

[Jared Mauch]

On Apr 11, 2012, at 5:19 PM, PC wrote:

> He.net tunnels are also good to have because depending on your provider,
> there's still many with incomplete views of the ipv6 routing table and he
> might have a path.  This is a more prevalent issue with ipv6 than v4 at the
> moment.

This is a big problem for the two providers involved in this "spat" having
inconsistent IPv4/IPv6 business relationships (peering, etc).

There are many professional service providers that will happily dual-stack
your internet port with consistent business relationships.  Don't let these
two parties that so far have agreed to disagree prevent you from using IPv6
to its fullest.  Select another carrier.

- Jared

Re: IPv6 support via Charter | Ideas on BGP Tunnel via HE

[PC]

He.net tunnels are also good to have because depending on your provider,
there's still many with incomplete views of the ipv6 routing table and he
might have a path.  This is a more prevalent issue with ipv6 than v4 at the
moment.
On Apr 11, 2012 2:03 PM, "Anurag Bhatia"  wrote:

> Hi Seth
>
>
> I just did a test from Eu based server sitting below EU based HE Tunnel
> node by downloading Ubuntu release file from US based server. This does not
> tells about possible high speed but surely tells what is available atleast.
> Server itself is sitting on M-Online with 100Mbps pipe.
>
>
>
>
> IPv4:
>
> traceroute to mirror.anl.gov (146.137.96.7), 30 hops max, 60 byte packets
>  1  gw.giga-dns.com (91.194.90.1) [AS51167]  16.876 ms  16.925 ms  16.915
> ms
>  2  host-93-104-204-33.customer.m-online.net (93.104.204.33) [AS8767]
>  1.166 ms  1.449 ms  1.445 ms
>  3  xe-2-1-0.rt-decix-1.m-online.net (212.18.6.162) [AS8767]  8.889 ms
>  8.888 ms  8.880 ms
>  4  20gigabitethernet4-3.core1.fra1.he.net (80.81.192.172) [AS6695]
>  18.586
> ms  19.831 ms  19.824 ms
>  5  10gigabitethernet1-4.core1.par2.he.net (184.105.213.162) [AS6939]
>  18.794 ms  18.789 ms 10gigabitethernet2-2.core1.par2.he.net (72.52.92.26)
> [AS6939]  18.437 ms
>  6  10gigabitethernet1-1.core1.par2.he.net (184.105.213.90) [AS6939]
>  18.507 ms 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93)
> [AS6939]
>  96.880 ms  97.345 ms
>  7  esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) [AS6939]
>  95.544 ms 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93)
> [AS6939]
>  97.616 ms esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18)
> [AS6939]  95.354 ms
>  8  washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293]  97.835 ms
> esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) [AS6939]
>  95.727
> ms washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293]  98.492 ms
>  9  washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293]  98.463 ms
> washsdn1-sdn2-washcr1.es.net (134.55.220.54) [AS293]  110.668 ms  110.641
> ms
> 10  starsdn1-ip-washsdn2.es.net (134.55.218.65) [AS293]  120.357 ms
>  120.844 ms washsdn1-sdn2-washcr1.es.net (134.55.220.54) [AS293]  110.834
> ms
> 11  starcr1-ip-starsdn1.es.net (134.55.219.25) [AS293]  164.788 ms
>  164.548
> ms  164.550 ms
> 12  starcr1-ip-starsdn1.es.net (134.55.219.25) [AS293]  164.758 ms
> anlmr2-starcr1.es.net (134.55.219.53) [AS293]  128.288 ms  128.286 ms
> 13  guava-esnet.anchor.anl.gov (192.5.170.77) [AS683]  117.532 ms
> anlmr2-starcr1.es.net (134.55.219.53) [AS293]  128.263 ms
> guava-esnet.anchor.anl.gov (192.5.170.77) [AS683]  117.500 ms
> 14  * guava-esnet.anchor.anl.gov (192.5.170.77) [AS683]  117.687 ms
>  117.858 ms
> 15  * * *
> 16  * * *
> 17  * * *
> 18  * * *
>
>
> root@server7:/home/anurag/tmp# wget -4
>
> http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso
> --2012-04-11 21:56:46--
>
> http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso
> Resolving mirror.anl.gov... 146.137.96.7
> Connecting to mirror.anl.gov|146.137.96.7|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 1644474368 (1.5G) [application/octet-stream]
> Saving to: `ubuntu-12.04-beta2-dvd-i386.iso.1'
>
>
> 100%[>]
> 1,644,474,368 4.78M/s   in 5m 38s
>
> 2012-04-11 22:02:25 (4.64 MB/s) - `ubuntu-12.04-beta2-dvd-i386.iso.1' saved
> [1644474368/1644474368]
>
>
>
>
>
>
>
>
> IPv6:
>
>
> traceroute to mirror.anl.gov (2620:0:dc0:1800:214:4fff:fe7d:1b9), 30 hops
> max, 80 byte packets
>  1  2001:470:25:78f::1 (2001:470:25:78f::1) [AS6939]  18.918 ms  21.147 ms
>  23.357 ms
>  2  gige-g2-20.core1.zrh1.he.net (2001:470:0:11d::1) [AS6939]  23.341 ms
>  23.324 ms  23.797 ms
>  3  10gigabitethernet5-1.core1.fra1.he.net (2001:470:0:21c::1) [AS6939]
>  29.781 ms  30.252 ms  23.671 ms
>  4  10gigabitethernet5-3.core1.lon1.he.net (2001:470:0:1d2::1) [AS6939]
>  37.897 ms  37.880 ms  43.095 ms
>  5  10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) [AS6939]
>  104.552 ms  105.763 ms  105.742 ms
>  6  10gigabitethernet2-3.core1.ash1.he.net (2001:470:0:36::1) [AS6939]
>  113.963 ms  114.467 ms  111.478 ms
>  7
> lawrence-berkeley-national-laboratory.gigabitethernet4-15.core1.ash1.he.net
> (2001:470:1:27f::2)
> [AS6939]  109.467 ms  109.452 ms  109.435 ms
>  8  washcr1-te-eqxashrt1.es.net (2001:400:0:15a::1) [AS293]  115.929 ms
>  113.625 ms  115.896 ms
>  9  washsdn1-sdn2-washcr1.es.net (2001:400:0:e0::2) [AS293]  114.606 ms
>  112.068 ms  112.045 ms
> 10  starsdn1-ip-washsdn2.es.net (2001:400:0:ab::1) [AS293]  126.783 ms
>  130.008 ms  126.747 ms
> 11  starcr1-ip-starsdn1.es.net (2001:400:0:a2::2) [AS293]  127.268 ms
>  124.223 ms  124.125 ms
> 12  anlmr2-starcr1.es.net (2001:400:0:c0::1) [AS293]  128.066 ms  130.529
> ms  130.513 ms
> 13  2001:400:2202:8::2 (2001:400:2202:8::2) [AS293] 

Re: IPv6 support via Charter | Ideas on BGP Tunnel via HE

[Charles N Wyble]

On 04/11/2012 02:34 PM, Seth Mos wrote:
>
>
> I'm getting about 40mbit through the IPv6 tunnel, so i'd say it works well, 
> although the throughput has slowly been dropping to the 30's range over the 
> last 6 months. But that's probably because of the latency.
>
> For something that is provided for free I'm really glad we have it.

Indeed. It's pretty amazing what HE has put together.

> I should have peered with their UK PoP as it's much closer by latency, thus 
> faster.

Why don't you? Can you setup more then one peering?

Re: Cheap Juniper Gear for Lab

[Leigh Porter]

On 11 Apr 2012, at 18:36, "Carl Rosevear"  wrote:

> Yeah, I have to apply the term "awful" and "annoying" to the packet
> mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC
> on the phone trying to get the thing to just pass packets.  Best part
> was, I didn't know how to do it and nor did they!  I escalated, worked
> with many engineers.  My key statement was "I just want my router to
> route.  Make it do what it is supposed to do.  No session tracking!
> This is not a firewall."  So, now it doesn't require valid sessions to
> pass packets but it does still appear to *track* sessions in some
> tables and I am, of course, very curious when some attack vector will
> fill up some table.
> 

I have had some rather odd issues with the SRX boxes but JTAC were pretty good 
at turning around fixes for me for my specific issues.

Since then I have had quite a lot of SRX boxes across the range running various 
MPLS services including MPLS over GRE with fragmentation/reassembly which has 
been working very well. Since 11.1R3 I've had no issues at all with them.

So yeah the new flow mode stuff had its issues, but as a *small* MPLS box it is 
very functional. Of course in MPLS mode, you turn the flow stuff off..


--
Leigh Porter



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Re: IPv6 support via Charter | Ideas on BGP Tunnel via HE

[Anurag Bhatia]

Hi Seth


I just did a test from Eu based server sitting below EU based HE Tunnel
node by downloading Ubuntu release file from US based server. This does not
tells about possible high speed but surely tells what is available atleast.
Server itself is sitting on M-Online with 100Mbps pipe.




IPv4:

traceroute to mirror.anl.gov (146.137.96.7), 30 hops max, 60 byte packets
 1  gw.giga-dns.com (91.194.90.1) [AS51167]  16.876 ms  16.925 ms  16.915 ms
 2  host-93-104-204-33.customer.m-online.net (93.104.204.33) [AS8767]
 1.166 ms  1.449 ms  1.445 ms
 3  xe-2-1-0.rt-decix-1.m-online.net (212.18.6.162) [AS8767]  8.889 ms
 8.888 ms  8.880 ms
 4  20gigabitethernet4-3.core1.fra1.he.net (80.81.192.172) [AS6695]  18.586
ms  19.831 ms  19.824 ms
 5  10gigabitethernet1-4.core1.par2.he.net (184.105.213.162) [AS6939]
 18.794 ms  18.789 ms 10gigabitethernet2-2.core1.par2.he.net (72.52.92.26)
[AS6939]  18.437 ms
 6  10gigabitethernet1-1.core1.par2.he.net (184.105.213.90) [AS6939]
 18.507 ms 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93) [AS6939]
 96.880 ms  97.345 ms
 7  esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) [AS6939]
 95.544 ms 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93) [AS6939]
 97.616 ms esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18)
[AS6939]  95.354 ms
 8  washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293]  97.835 ms
esnet.gigabitethernet4-15.core1.ash1.he.net (216.66.70.18) [AS6939]  95.727
ms washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293]  98.492 ms
 9  washcr1-te-eqxashrt1.es.net (134.55.221.145) [AS293]  98.463 ms
washsdn1-sdn2-washcr1.es.net (134.55.220.54) [AS293]  110.668 ms  110.641 ms
10  starsdn1-ip-washsdn2.es.net (134.55.218.65) [AS293]  120.357 ms
 120.844 ms washsdn1-sdn2-washcr1.es.net (134.55.220.54) [AS293]  110.834 ms
11  starcr1-ip-starsdn1.es.net (134.55.219.25) [AS293]  164.788 ms  164.548
ms  164.550 ms
12  starcr1-ip-starsdn1.es.net (134.55.219.25) [AS293]  164.758 ms
anlmr2-starcr1.es.net (134.55.219.53) [AS293]  128.288 ms  128.286 ms
13  guava-esnet.anchor.anl.gov (192.5.170.77) [AS683]  117.532 ms
anlmr2-starcr1.es.net (134.55.219.53) [AS293]  128.263 ms
guava-esnet.anchor.anl.gov (192.5.170.77) [AS683]  117.500 ms
14  * guava-esnet.anchor.anl.gov (192.5.170.77) [AS683]  117.687 ms
 117.858 ms
15  * * *
16  * * *
17  * * *
18  * * *


root@server7:/home/anurag/tmp# wget -4
http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso
--2012-04-11 21:56:46--
http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso
Resolving mirror.anl.gov... 146.137.96.7
Connecting to mirror.anl.gov|146.137.96.7|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1644474368 (1.5G) [application/octet-stream]
Saving to: `ubuntu-12.04-beta2-dvd-i386.iso.1'

100%[>]
1,644,474,368 4.78M/s   in 5m 38s

2012-04-11 22:02:25 (4.64 MB/s) - `ubuntu-12.04-beta2-dvd-i386.iso.1' saved
[1644474368/1644474368]








IPv6:


traceroute to mirror.anl.gov (2620:0:dc0:1800:214:4fff:fe7d:1b9), 30 hops
max, 80 byte packets
 1  2001:470:25:78f::1 (2001:470:25:78f::1) [AS6939]  18.918 ms  21.147 ms
 23.357 ms
 2  gige-g2-20.core1.zrh1.he.net (2001:470:0:11d::1) [AS6939]  23.341 ms
 23.324 ms  23.797 ms
 3  10gigabitethernet5-1.core1.fra1.he.net (2001:470:0:21c::1) [AS6939]
 29.781 ms  30.252 ms  23.671 ms
 4  10gigabitethernet5-3.core1.lon1.he.net (2001:470:0:1d2::1) [AS6939]
 37.897 ms  37.880 ms  43.095 ms
 5  10gigabitethernet7-4.core1.nyc4.he.net (2001:470:0:128::1) [AS6939]
 104.552 ms  105.763 ms  105.742 ms
 6  10gigabitethernet2-3.core1.ash1.he.net (2001:470:0:36::1) [AS6939]
 113.963 ms  114.467 ms  111.478 ms
 7
lawrence-berkeley-national-laboratory.gigabitethernet4-15.core1.ash1.he.net(2001:470:1:27f::2)
[AS6939]  109.467 ms  109.452 ms  109.435 ms
 8  washcr1-te-eqxashrt1.es.net (2001:400:0:15a::1) [AS293]  115.929 ms
 113.625 ms  115.896 ms
 9  washsdn1-sdn2-washcr1.es.net (2001:400:0:e0::2) [AS293]  114.606 ms
 112.068 ms  112.045 ms
10  starsdn1-ip-washsdn2.es.net (2001:400:0:ab::1) [AS293]  126.783 ms
 130.008 ms  126.747 ms
11  starcr1-ip-starsdn1.es.net (2001:400:0:a2::2) [AS293]  127.268 ms
 124.223 ms  124.125 ms
12  anlmr2-starcr1.es.net (2001:400:0:c0::1) [AS293]  128.066 ms  130.529
ms  130.513 ms
13  2001:400:2202:8::2 (2001:400:2202:8::2) [AS293]  130.976 ms  128.915 ms
 128.892 ms
14  * * *
15  * * *








root@server7:/home/anurag/tmp# wget -6
http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso
--2012-04-11 21:45:52--
http://mirror.anl.gov/pub/ubuntu-iso/DVDs/ubuntu/12.04/beta-2/ubuntu-12.04-beta2-dvd-i386.iso
Resolving mirror.anl.gov... 2620:0:dc0:1800:214:4fff:fe7d:1b9
Connecting to mirror.anl.gov|2620:0:dc0:1800:214:4fff:fe7d:1b9|:80...
connected.
HTTP request sent, awaiting response... 2

Re: IPv6 support via Charter | Ideas on BGP Tunnel via HE

[William Herrin]

On Wed, Apr 11, 2012 at 2:16 PM, Anurag Bhatia  wrote:
> Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6
> Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of
> overhead. Yet to test other parameters. I heard Tunnels are usually bad.
> Can someone tell how to test this tunnel setup to confirm if there is a
> performance issue or not? I am thinking of writing a quick bash script and
> run via cron to test latency, packet loss and bandwidth throughput for
> couple of days. If anyone has better idea, please let me know.

HE does a fine job with their IPv6 tunnels. If they're you're only v6
connectivity or you need them to provide a backup IPv6 route for when
sole native v6 provider goes down, they're a superb choice.

However...

Do not, do not, do not, rig your system to prefer tunneled IPvanything
to native IPvanythingelse. For all of the obvious reasons.

If you publish an IPv6 address for www.anuragbhatia.com, clients with
IPv6 will use that IPv6 address in preference to the address published
for IPv4. If your sole IPv6 access is with a tunnel, don't publish an
IPv6 address for www. Publish the IPv6 address under
www6.anuragbhatia.com instead. And on your mail server, have the
second MX point to a name with a , and let the first MX stay on
v4.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv6 support via Charter | Ideas on BGP Tunnel via HE

[Seth Mos]

Hi,

Op 11 apr 2012, om 20:16 heeft Anurag Bhatia het volgende geschreven:

> Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6
> Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of
> overhead. Yet to test other parameters. I heard Tunnels are usually bad.
> Can someone tell how to test this tunnel setup to confirm if there is a
> performance issue or not? I am thinking of writing a quick bash script and
> run via cron to test latency, packet loss and bandwidth throughput for
> couple of days. If anyone has better idea, please let me know.

Also using a HE.net BGP tunnel for our IPv6, simply because having just 1 
native provider with Ipv6 isn't redundant. That and it's 8mbit.

The v4 connection which the tunnel connects over is 90mbit, and the tunnel 
needs to travel from NL to DE for the FRA BGP peering.

I'm getting about 40mbit through the IPv6 tunnel, so i'd say it works well, 
although the throughput has slowly been dropping to the 30's range over the 
last 6 months. But that's probably because of the latency.

For something that is provided for free I'm really glad we have it.

I should have peered with their UK PoP as it's much closer by latency, thus 
faster.

Cheers,

Seth

RE: Cheap Juniper Gear for Lab

[Tom Ammon]

>-Original Message-
>From: Jay Hanke [mailto:jay.ha...@mankatonetworks.com] 
>Sent: Wednesday, April 11, 2012 1:03 PM
>To: sth...@nethelp.no
>Cc: nanog@nanog.org
>.Subject: Re: Cheap Juniper Gear for Lab
>
>> We have 3 J2320s in the lab, all running 9.3R3.8. That's the last
>> *real* JunOS (no session/flow tracking) for these boxes.
>>>
>
>+1 on that. We have a number of 2300s in our lab for the same purpose
>running 8.x code.
>
>We also use Junosphere extensively, but nothing beats real hardware.
>j2300s are cheap.
>
>Jay

So, I have a question, then. For the purposes of learning JUNOS, is 8.3 code 
sufficient? Would you be missing a lot of features that are in newer code? I 
would assume IPv6 features are different between 8.3 and the latest code, is 
that right?

Tom

-
Tom Ammon
Network Engineer
M: (801)674-9273
tom.am...@utah.edu

Center for High Performance Computing
University of Utah
http://www.chpc.utah.edu
---L-O---

Re: Cheap Juniper Gear for Lab

[Jay Hanke]

> We have 3 J2320s in the lab, all running 9.3R3.8. That's the last
> *real* JunOS (no session/flow tracking) for these boxes.
>

+1 on that. We have a number of 2300s in our lab for the same purpose
running 8.x code.

We also use Junosphere extensively, but nothing beats real hardware.
j2300s are cheap.

Jay

RE: IPv6 support via Charter | Ideas on BGP Tunnel via HE

[Rampley Jr, Jim F]

Anurag,

We (Charter) are planning on starting early field trials with our business 
customers with IPv6 real soon (within Q2).  We have a few customers already 
identified, but would you be interested in participating with us? 


Jim Rampley | Principal Engineer | 314-543-2505
12405 Powerscourt Drive, St. Louis, MO 63131



-Original Message-
From: Anurag Bhatia [mailto:m...@anuragbhatia.com] 
Sent: Wednesday, April 11, 2012 1:16 PM
To: NANOG Mailing List
Subject: IPv6 support via Charter | Ideas on BGP Tunnel via HE

Hello,


Does anyone here has clues on IPv6 support via Charter? We recently got BGP
up on the connection and they denied for IPv6 support for now. Support
engineer gave expected time of something like end of year which seems very
late as per our plans.


Is situation same for everyone who sits in downstream of Charter?


Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6
Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of
overhead. Yet to test other parameters. I heard Tunnels are usually bad.
Can someone tell how to test this tunnel setup to confirm if there is a
performance issue or not? I am thinking of writing a quick bash script and
run via cron to test latency, packet loss and bandwidth throughput for
couple of days. If anyone has better idea, please let me know.



Thanks.

-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia 
Linkedin: http://linkedin.anuragbhatia.com

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: IPv6 support via Charter | Ideas on BGP Tunnel via HE

[Dan Sneddon]

Hurricane Electric have a presentation on testing their tunnels using 
Traceroute6, Tracepath6, and mtr:
http://ipv6.he.net/presentations/trace6.pdf

iperf now supports IPv6 and works well for testing tunnels as well.  

I have previously gotten good results from Hurricane Electric tunnels. 

--
Dan Sneddon
Network Engineering & Network Security
twitter | AS13414
d...@twitter.com | Follow me! @dansneddon


On Wednesday, April 11, 2012 at 11:16 AM, Anurag Bhatia wrote:

> Hello,
> 
> 
> Does anyone here has clues on IPv6 support via Charter? We recently got BGP
> up on the connection and they denied for IPv6 support for now. Support
> engineer gave expected time of something like end of year which seems very
> late as per our plans.
> 
> 
> Is situation same for everyone who sits in downstream of Charter?
> 
> 
> Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6
> Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of
> overhead. Yet to test other parameters. I heard Tunnels are usually bad.
> Can someone tell how to test this tunnel setup to confirm if there is a
> performance issue or not? I am thinking of writing a quick bash script and
> run via cron to test latency, packet loss and bandwidth throughput for
> couple of days. If anyone has better idea, please let me know.
> 
> 
> 
> Thanks.
> 
> -- 
> 
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
> 
> Twitter: @anurag_bhatia 
> Linkedin: http://linkedin.anuragbhatia.com
> 
> 

IPv6 support via Charter | Ideas on BGP Tunnel via HE

[Anurag Bhatia]

Hello,


Does anyone here has clues on IPv6 support via Charter? We recently got BGP
up on the connection and they denied for IPv6 support for now. Support
engineer gave expected time of something like end of year which seems very
late as per our plans.


Is situation same for everyone who sits in downstream of Charter?


Also, does it makes sense to go for BGP Tunnel for now? I just setup IPv6
Tunnel via Hurricane Electric. Latency seems pretty much OK ~ 10-15ms of
overhead. Yet to test other parameters. I heard Tunnels are usually bad.
Can someone tell how to test this tunnel setup to confirm if there is a
performance issue or not? I am thinking of writing a quick bash script and
run via cron to test latency, packet loss and bandwidth throughput for
couple of days. If anyone has better idea, please let me know.



Thanks.

-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia 
Linkedin: http://linkedin.anuragbhatia.com

IPv6 Launch day preparation

[Pierre-Yves Maunier]

Hello all,

we've had an interesting day today in Paris discussing about how to prepare
the IPv6 implementation in various networks.

With a couple of vendors and software companies (Juniper, Cisco, A10
Networks, Fortinet, BreakingPoint, StoneSoft, Infoblox, PaloAlto) we
decided to make a very technical day about IPv6 transition techniques and
various ways to implement it in different type of networks.

We've had the morning for some mechanisms presentations and all the
afternoon with a lab interconnecting all the vendors and having various
scenarios to test all the mechanisms we discussed in the morning.

The lab description can be found here :
http://g6.asso.fr/wp-content/uploads/2012/03/ipv6-launch-lab.pdf

(it's in "frenglish" but really understable for english speaking only
people, personnaly I'm dual stack french/english :-) )

Actually we had :

- a Juniper MX480 with a service card to act as a eyeball network providing
IPv6 only connectivity to their customers and a NAT64 (Juniper) + DNS64
(Infoblox) to allow them to reach IPv4 only contents

- Stonesoft running a dual stack entreprise network (FW+IPS) that can reach
all IPv4/IPv6 contents

- A10 networks configured as a IPv4 load balancer and IPv6 NAT64 gateway
for contents servers using private IPv4 only address space : The IPv4 only
servers were reachable from IPv6 only machines

- PaloAlto and Fortinet as IPv4/IPv6 Firewalls

- an IPv4 only web server (to be accessible from the IPv6 only eyeball
network thanks to the NAT64+DNS64 setup)

- an IPv6 only web server

And in order to stress all the vendors hardware/software, we had breaking
point which was able to generate IPv4/IPv6 applicative traffic from several
kpps/mbps to loads of Mpps/Gbps

It was very interesting to have this setup on which anybody in the audience
was able to ask for specific test/configuration to understand all the
mechanisms.

Unfortunately we did not have a link to the DFZ to run more interesting
tests but we will probably have another Lab day with a better setup for
this (and having all the people in the audience using their laptops to
simulate eyeball customers).

Our goal was mainly to make people aware about what can be done to move
forward with IPv6 and I think we achieved this goal.

If you have any comments, feel free to reply here.

-- 
Pierre-Yves Maunier

Re: Cheap Juniper Gear for Lab

[sthaug]

> Anyway, not the best devices for an edge router that is for sure.
> Which is too bad...  for very small DC edge applications, the J6350
> was a pretty cool router in earlier versions of JunOS that didn't
> decide to re-engineer your network and transit for you.

We have 3 J2320s in the lab, all running 9.3R3.8. That's the last
*real* JunOS (no session/flow tracking) for these boxes.

They'll stay in the lab, and they'll never be upgraded to anything
newer. Which is too bad, I had great hopes for the J series.

But at least they're nice boxes to teach the JunOS CLI and things
like that...

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: Cheap Juniper Gear for Lab

[Carl Rosevear]

Yeah, I have to apply the term "awful" and "annoying" to the packet
mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC
on the phone trying to get the thing to just pass packets.  Best part
was, I didn't know how to do it and nor did they!  I escalated, worked
with many engineers.  My key statement was "I just want my router to
route.  Make it do what it is supposed to do.  No session tracking!
This is not a firewall."  So, now it doesn't require valid sessions to
pass packets but it does still appear to *track* sessions in some
tables and I am, of course, very curious when some attack vector will
fill up some table.

Anyway, not the best devices for an edge router that is for sure.
Which is too bad...  for very small DC edge applications, the J6350
was a pretty cool router in earlier versions of JunOS that didn't
decide to re-engineer your network and transit for you.

Anyway I digress.  But this had, in the past, been a frustrating
enough issue for me that I had to share.


--Carl



On Tue, Apr 10, 2012 at 6:30 PM, Owen DeLong  wrote:
>
> On Apr 10, 2012, at 6:02 PM, Mark Kamichoff wrote:
>
>> On Tue, Apr 10, 2012 at 11:57:31AM -0700, Owen DeLong wrote:
 The fact that you can't put it into flow mode.
>>> s/flow/packet/
>>> (oops, wasn't awake yet)
>>
>> Actually, this is possible:
>>
>> prox@asgard> show configuration security
>> forwarding-options {
>>    family {
>>        inet6 {
>>            mode packet-based;
>>        }
>>        mpls {
>>            mode packet-based;
>>        }
>>    }
>> }
>>
>> The above is from an SRX210B, but the same configuration will work on
>> any J-series or /branch/ SRX-series platform.
>>
>
> Right, sort of. To the extent that it works. It doesn't actually do 
> everything you
> think it should, and, it's somewhat dependent on the version of JunOS as to
> how well it does or doesn't work.
>
>> Don't let the "mpls" keyword throw you off.  This actually causes the
>> box to run the inet /and/ mpls address families in packet mode.
>>
>
> I'm not unfamiliar or uninitiated in this regard. I had tickets with Juniper 
> for
> over a year and it escalated quite high up their escalation chain before they
> finally admitted "Yeah, Services JunOS is different and it behaves differently
> and if you need to do what you're trying to do, you should buy an M or MX
> series."
>
> It's quite unfortunate. I'd really like for the SRX series to not be so 
> crippled for
> my purposes.
>
> Owen
>
>



-- 
Carl Rosevear
Manager of Operations
Skytap, Inc.
direct (206) 588-8899

Re: Cheap Juniper Gear for Lab

[Leo Bicknell]

In a message written on Tue, Apr 10, 2012 at 08:31:04PM -0500, Tim Eberhard 
wrote:
> While I know you are a smart engineer and obviously have been working
> with this gear for a long time you're really not adding anything or
> backing up your argument besides saying yet again the packet
> forwarding is different. While this maybe true..It's my understanding
> that enabling packet mode does turn it into a normal packet based
> junos.

I honestly don't remember what caused the problem when I ran into
it, but the first time I configured IPv6 on a SRX I used per-packet
and I had all sorts of problems.  After contacting Juniper support
and some friends who ran them they all told me to configure flow-based
for IPv6, and it started working properly.  Juniper support basically
said IPv6 didn't work at all unless it was in flow mode.

My vague memory at least was OSPFv3 would not come up in IPv6
per-packet mode no matter what changes were made, but with flow
mode it came right up.

In any event, I will back up Owen on this one.  Any JunOS box with
a security {} section (which I think means of Netscreen lineage)
does a number of weird things when you're used to the JunOS boxes
without a security section.  For instance they basically default
to a stateful firewall, so when I used a pair for redundancy and
had asymmetrical paths it took way too many lines of config (4-5
features that had to be turned off) to make it not-stateful.  That's
a big surprise when you come from working on M-series.

Still, they are very nice boxes, particularly for the capabilities
you get at the price point.  It's just that darn security {} section
that seems to be quite poorly thought out, even all the working
parts are just laid out in a way that's not intuitive to me and
don't seem to match the rest of JunOS well.  Want to list a netblock,
you have to put it in an "address book".  Want to list two, it has
to be in an "address-book group", you can't just list them between
brackets, and so on.  It may be the only router platform where I turn to
the web gui from time to time to configure things, otherwise it's an
exercise in frustration trying to get the syntax right.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpiuZJqUZnvh.pgp
Description: PGP signature

RPKI field experiences

[Alex Band]

We just released a new version of our RPKI relying party software, RIPE NCC 
RPKI Validator 2.0.4:
http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources

There are now more than 7,200 RPKI valid BGP route announcements entered in the 
global system, so there is a solid data set to gain operational experience 
with. We would really like you to try it out and report back on the usability 
and reliability. 

ARINs Pilot information is here in case you want to create some of your own 
ROAs: https://www.arin.net/resources/rpki.html

As always, the RIPE NCC RPKI Validator requires no configuration and has no 
dependencies other than Java 1.6 and rsync available on your system. 
Simply unzip the package, run ./bin/rpki-validator from the base directory and 
browse to http://localhost:8080

Cheers,

Alex

RE: Cheap Juniper Gear for Lab

[Eric Van Tol]

> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com]
> Sent: Tuesday, April 10, 2012 9:31 PM
> To: Mark Kamichoff
> Cc: jgood...@studio442.com.au; nanog@nanog.org
> Subject: Re: Cheap Juniper Gear for Lab
> 
> It's quite unfortunate. I'd really like for the SRX series to not be
> so crippled for
> my purposes.
> 
> Owen

While it may not forward packets exactly like an M-series or MX, for the OP's 
purpose of simply learning JUNOS in a home lab, it will work just fine.  I 
learned quite a bit using Olives (which don't exist), with the understanding 
that there were a lot of limitations. 

To the OP, I would also suggest checking out Juniper's website, specifically 
the 'Education' section.  There are a ton of excellent learning tools on there 
- Learning Bytes, Web-Based Training, Day One books, etc.:

http://www.juniper.net/us/en/training/jnbooks/
https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5853
https://learningportal.juniper.net/juniper/user_courses.aspx


-evt

RE: facebook ipv6 is down?

[Frank Bulk]

It's been down three times today, first from 2:58 pm to 5:58 pm Central, and
then again from 7:59 pm to 9:58 pm, and then again from 10:59 pm till now.

Interesting that the up and downs have been one to two minutes before the
hour.

Frank

-Original Message-
From: Aftab Siddiqui [mailto:aftab.siddi...@gmail.com] 
Sent: Wednesday, April 11, 2012 2:00 AM
To: Ido Szargel
Cc: NANOG list (nanog@nanog.org)
Subject: Re: facebook ipv6 is down?

Yes, its down from Asian route via C&W for atleast an hour now (first
problem reported).

Regards,

Aftab A. Siddiqui


On Wed, Apr 11, 2012 at 11:55 AM, Ido Szargel  wrote:

> Hi,
>
>
>
> It seems that on the last 3 hours facebook isn't available via ipv6, when
> tracing from HE I don't even get to FB network, only as far as Ashburn on
> their network,
>
> When tracing from nl-ix I get to facebook network but the trace stops
>
>
>
> traceroute6 -I www.v6.facebook.com
>
> traceroute to www.v6.facebook.com (2620:0:1cfe:face:b00c:0:3:0), 30 hops
> max, 40 byte packets
>
> 1  2a01:1b0:705::f (2a01:1b0:705::f)  3.858 ms  3.744 ms  3.504 ms
>
> 2  bit.telecity2.nlsix.net (2001:7f8:13::a501:2859:2)  2.133 ms  2.061 ms
> 1.923 ms
>
> 3  br01.ams1.tfbnw.net (2001:7f8:1::a503:2934:1)  3.276 ms  3.159 ms
>  3.000
> ms
>
> 4  ae28.bb02.iad1.tfbnw.net (2620:0:1cff:dead:beef::485)  90.835 ms
>  91.009
> ms  90.953 ms
>
> 5  ae12.bb02.sjc1.tfbnw.net (2620:0:1cff:dead:beef::85)  160.883 ms
>  160.820
> ms  160.897 ms
>
> 6  ae2.pr01.sjc1.tfbnw.net (2620:0:1cff:dead:beef::10)  152.688 ms
>  152.638
> ms  152.890 ms
>
> 7  * * *
>
> 8  * * *
>
> 9  * * *
>
> 10  * * *
>
>
>
> Is anyone else having the same issue?
>
>
>
> Thanks,
>
> Ido
>
>

Re: facebook ipv6 is down?

[Tore Anderson]

* Ido Szargel

> It seems that on the last 3 hours facebook isn't available via ipv6, when
> tracing from HE I don't even get to FB network, only as far as Ashburn on
> their network,
> 
> When tracing from nl-ix I get to facebook network but the trace stops

> Is anyone else having the same issue?

Yes, but only to their IPv6-only host name. Their main host name works.

$ curl -v http://www.v6.facebook.com 
* About to connect() to www.v6.facebook.com port 80 (#0)
*   Trying 2620:0:1cfe:face:b00c:0:3:0... Timeout
* connect() timed out!
[...]

$ curl -v http://www.facebook.com 
* About to connect() to www.facebook.com port 80 (#0)
*   Trying 2620:0:1c18:0:face:b00c:0:3... connected
* Connected to www.facebook.com (2620:0:1c18:0:face:b00c:0:3) port 80 (#0)
[...]

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com

Re: facebook ipv6 is down?

[Aftab Siddiqui]

Yes, its down from Asian route via C&W for atleast an hour now (first
problem reported).

Regards,

Aftab A. Siddiqui


On Wed, Apr 11, 2012 at 11:55 AM, Ido Szargel  wrote:

> Hi,
>
>
>
> It seems that on the last 3 hours facebook isn't available via ipv6, when
> tracing from HE I don't even get to FB network, only as far as Ashburn on
> their network,
>
> When tracing from nl-ix I get to facebook network but the trace stops
>
>
>
> traceroute6 -I www.v6.facebook.com
>
> traceroute to www.v6.facebook.com (2620:0:1cfe:face:b00c:0:3:0), 30 hops
> max, 40 byte packets
>
> 1  2a01:1b0:705::f (2a01:1b0:705::f)  3.858 ms  3.744 ms  3.504 ms
>
> 2  bit.telecity2.nlsix.net (2001:7f8:13::a501:2859:2)  2.133 ms  2.061 ms
> 1.923 ms
>
> 3  br01.ams1.tfbnw.net (2001:7f8:1::a503:2934:1)  3.276 ms  3.159 ms
>  3.000
> ms
>
> 4  ae28.bb02.iad1.tfbnw.net (2620:0:1cff:dead:beef::485)  90.835 ms
>  91.009
> ms  90.953 ms
>
> 5  ae12.bb02.sjc1.tfbnw.net (2620:0:1cff:dead:beef::85)  160.883 ms
>  160.820
> ms  160.897 ms
>
> 6  ae2.pr01.sjc1.tfbnw.net (2620:0:1cff:dead:beef::10)  152.688 ms
>  152.638
> ms  152.890 ms
>
> 7  * * *
>
> 8  * * *
>
> 9  * * *
>
> 10  * * *
>
>
>
> Is anyone else having the same issue?
>
>
>
> Thanks,
>
> Ido
>
>