Re: Telstra issues

[Chris Hills]

On 03/09/09 07:47, Mark Newton wrote:

We run one which isn't connected to Telstra :-)

There are media reports this morning of major outages in Telstra's domestic
network.
http://www.australianit.news.com.au/story/0,24897,26021106-15306,00.html


Thank goodness PPC-1 is nearing completion, eh?

http://www.pipeinternational.com/index.php?option=com_myblog&Itemid=65

nanog@nanog.org

[Brian Raaen]

I'm not sure where to take this issue.  The Regular AT&T NOC contacts
are refusing to talk to me since I do not have a circuit ID, and do not
seem to have any understanding about transiting issues.  I am unable to
fully monitor and manage a router I control, as all traffic bound to its
lan IP that transits through the AT&T network is blocked.  The Router is
connected to a Verizon circuit, but any connection that transits through
AT&T is blocked.  The ip in Question is from a direct ARIN allocation
that I control.  I have attached a ping demonstrating that I am
receiving an ICMP deny from an AT&T core router.  I have also attached a
traceroute to both the offending IP and the WAN IP which appears to be
working.

bra...@brian-debian:~$ ping gw.bwtc.net
PING gw.bwtc.net (72.14.76.1) 56(84) bytes of data.
>From 12.89.27.105 icmp_seq=1 Packet filtered
>From 12.89.27.105 icmp_seq=3 Packet filtered
^C
--- gw.bwtc.net ping statistics ---
4 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3004ms


bra...@brian-debian:~$ sudo traceroute-nanog -AO gw.bwtc.net
[sudo] password for braaen:
traceroute to gw.bwtc.net (72.14.76.1), 64 hops max, 40 byte packets
 1  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms 
3 ms  3 ms
 2  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms 
3 ms  4 ms
 3  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms
rtrs00.america.net (69.60.176.21) [AS4452] d...@america.net  13 ms
69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms
 4  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  12 ms  35 ms  17 ms
 5  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
dnsad...@globix.net [MPLS: Label 673 Exp 0]  15 ms  14 ms  25 ms
 6  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
dnsad...@globix.net  14 ms  14 ms  18 ms
 7  ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
dnsad...@globix.net  14 ms  12 ms  14 ms
 8  border11.tge3-3.qts-1.acs.pnap.net (64.94.3.113) [AS14745]
hostmas...@pnap.net  14 ms  14 ms  14 ms
 9  core1.te2-2-bbnet2.acs002.pnap.net (64.94.0.79) [AS14745]
hostmas...@pnap.net  14 ms core1.te2-1-bbnet1.acs002.pnap.net
(64.94.0.15) [AS14745] hostmas...@pnap.net  14 ms 12.86.102.5
(12.86.102.5) [] rm-hostmas...@ems.att.com  14 ms
10  12.86.102.5 (12.86.102.5) [] rm-hostmas...@ems.att.com  13 ms 
23 ms  13 ms
11  cr1.attga.ip.att.net (12.122.141.2) []
rm-hostmas...@ems.att.com [MPLS: Label 16745 Exp 0]  40 ms
cr2.ormfl.ip.att.net (12.122.5.141) [] rm-hostmas...@ems.att.com
[MPLS: Label 20348 Exp 0] More labels  40 ms More labels  40 ms
12  cr2.ormfl.ip.att.net (12.122.5.141) []
rm-hostmas...@ems.att.com More labels  40 ms More labels  41 ms More
labels  40 ms
13  cr2.nwrla.ip.att.net (12.122.30.77) []
rm-hostmas...@ems.att.com [MPLS: Label 0 Exp 0] More labels  40 ms
gar1.nwrla.ip.att.net (12.123.153.85) []
rm-hostmas...@ems.att.com  38 ms  38 ms
14  gar1.nwrla.ip.att.net (12.123.153.85) []
rm-hostmas...@ems.att.com  50 ms  38 ms  38 ms
15  12.89.27.106 (12.89.27.106) [] rm-hostmas...@ems.att.com  43
ms  44 ms  44 ms
16  * * 12.89.27.105 (12.89.27.105) [] rm-hostmas...@ems.att.com 
44 ms !A




bra...@brian-debian:~$ sudo traceroute-nanog -AO 157.130.26.166
traceroute to 157.130.26.166 (157.130.26.166), 64 hops max, 40 byte packets
 1  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  4 ms 
3 ms  6 ms
 2  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms 
3 ms  3 ms
 3  rtrs00.america.net (69.60.176.21) [AS4452] d...@america.net  14 ms 
13 ms  13 ms
 4  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms  13 ms  12 ms
 5  66.0.192.194 (66.0.192.194) [AS20141] d...@deltacom.net  13 ms  13
ms  15 ms
 6  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
dnsad...@globix.net [MPLS: Label 673 Exp 0]  30 ms
ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
dnsad...@globix.net  14 ms gig4-16.core2.suw1.qualitytech.com
(64.88.172.145) [AS20141] dnsad...@globix.net  34 ms
 7  ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
dnsad...@globix.net  19 ms  13 ms  13 ms
 8  core3.tge4-1-bbnet1.acs.pnap.net (64.94.0.3) [AS14745]
hostmas...@pnap.net  14 ms core3.tge4-1-bbnet2.acs.pnap.net (64.94.0.67)
[AS14745] hostmas...@pnap.net  14 ms  15 ms
 9  core3.tge4-1-bbnet2.acs.pnap.net (64.94.0.67) [AS14745]
hostmas...@pnap.net  14 ms core3.tge4-1-bbnet1.acs.pnap.net (64.94.0.3)
[AS14745] hostmas...@pnap.net  14 ms  15 ms
10  TenGigabitEthernet3-4.ar5.ATL1.gblx.net (207.218.80.217) [AS3549]
d...@gblx.net.80.218.207.in-addr.arpa  14 ms  14 ms  14 ms
11  ge4-3-1000M.ar3.PTY1.gblx.net (67.16.135.18) [AS22566] d...@gblx.net 
18 ms  14 ms  14 ms
12  0.so-1-1-0.XT1.ATL4.ALTER.NET (152.63.86.170) []
hostmas...@uu.net  14 ms  49 ms verizon-1.ar2.ATL2.gblx.net
(64.208.110.170) [AS3549] d...@gblx.net  17 ms
13  0.so-1-1-0.XT1.ATL4.ALTER.NET (152.63.86.170) []
hostmas...@uu.net  33 ms  14 ms  16 ms
14  0.so-7-1-0.XL3.BOS4.ALTER.NET (152.63.0.209) 

nanog@nanog.org

[Robert D. Scott]

Work through your provider, I would start with you local end.  They should
help you, you ARE their customer.  If not, you need a new provider. Look
into out of band management.

Robert D. Scott rob...@ufl.edu
Senior Network Engineer 352-273-0113 Phone
CNS - Network Services  352-392-2061 CNS Phone Tree
University of Florida   352-392-9440 FAX
Florida Lambda Rail 352-294-3571 FLR NOC
Gainesville, FL  32611  321-663-0421 Cell


-Original Message-
From: Brian Raaen [mailto:bra...@zcorum.com] 
Sent: Thursday, September 03, 2009 7:29 AM
To: nanog@nanog.org
Subject: Need Help Getting IP Unblocked by AT&T

I'm not sure where to take this issue.  The Regular AT&T NOC contacts are
refusing to talk to me since I do not have a circuit ID, and do not seem to
have any understanding about transiting issues.  I am unable to fully
monitor and manage a router I control, as all traffic bound to its lan IP
that transits through the AT&T network is blocked.  The Router is connected
to a Verizon circuit, but any connection that transits through AT&T is
blocked.  The ip in Question is from a direct ARIN allocation that I
control.  I have attached a ping demonstrating that I am receiving an ICMP
deny from an AT&T core router.  I have also attached a traceroute to both
the offending IP and the WAN IP which appears to be working.

bra...@brian-debian:~$ ping gw.bwtc.net
PING gw.bwtc.net (72.14.76.1) 56(84) bytes of data.
>From 12.89.27.105 icmp_seq=1 Packet filtered From 12.89.27.105 
>icmp_seq=3 Packet filtered
^C
--- gw.bwtc.net ping statistics ---
4 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3004ms


bra...@brian-debian:~$ sudo traceroute-nanog -AO gw.bwtc.net [sudo] password
for braaen:
traceroute to gw.bwtc.net (72.14.76.1), 64 hops max, 40 byte packets
 1  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms
3 ms  3 ms
 2  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms
3 ms  4 ms
 3  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms
rtrs00.america.net (69.60.176.21) [AS4452] d...@america.net  13 ms
69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms
 4  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  12 ms  35 ms  17 ms
 5  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
dnsad...@globix.net [MPLS: Label 673 Exp 0]  15 ms  14 ms  25 ms
 6  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
dnsad...@globix.net  14 ms  14 ms  18 ms
 7  ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
dnsad...@globix.net  14 ms  12 ms  14 ms
 8  border11.tge3-3.qts-1.acs.pnap.net (64.94.3.113) [AS14745]
hostmas...@pnap.net  14 ms  14 ms  14 ms
 9  core1.te2-2-bbnet2.acs002.pnap.net (64.94.0.79) [AS14745]
hostmas...@pnap.net  14 ms core1.te2-1-bbnet1.acs002.pnap.net
(64.94.0.15) [AS14745] hostmas...@pnap.net  14 ms 12.86.102.5
(12.86.102.5) [] rm-hostmas...@ems.att.com  14 ms 10  12.86.102.5
(12.86.102.5) [] rm-hostmas...@ems.att.com  13 ms
23 ms  13 ms
11  cr1.attga.ip.att.net (12.122.141.2) [] rm-hostmas...@ems.att.com
[MPLS: Label 16745 Exp 0]  40 ms cr2.ormfl.ip.att.net (12.122.5.141)
[] rm-hostmas...@ems.att.com
[MPLS: Label 20348 Exp 0] More labels  40 ms More labels  40 ms
12  cr2.ormfl.ip.att.net (12.122.5.141) [] rm-hostmas...@ems.att.com
More labels  40 ms More labels  41 ms More labels  40 ms
13  cr2.nwrla.ip.att.net (12.122.30.77) [] rm-hostmas...@ems.att.com
[MPLS: Label 0 Exp 0] More labels  40 ms gar1.nwrla.ip.att.net
(12.123.153.85) [] rm-hostmas...@ems.att.com  38 ms  38 ms
14  gar1.nwrla.ip.att.net (12.123.153.85) [] rm-hostmas...@ems.att.com
50 ms  38 ms  38 ms
15  12.89.27.106 (12.89.27.106) [] rm-hostmas...@ems.att.com  43 ms
44 ms  44 ms
16  * * 12.89.27.105 (12.89.27.105) [] rm-hostmas...@ems.att.com
44 ms !A




bra...@brian-debian:~$ sudo traceroute-nanog -AO 157.130.26.166 traceroute
to 157.130.26.166 (157.130.26.166), 64 hops max, 40 byte packets
 1  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  4 ms
3 ms  6 ms
 2  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms
3 ms  3 ms
 3  rtrs00.america.net (69.60.176.21) [AS4452] d...@america.net  14 ms
13 ms  13 ms
 4  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms  13 ms  12 ms
 5  66.0.192.194 (66.0.192.194) [AS20141] d...@deltacom.net  13 ms  13 ms  15
ms
 6  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
dnsad...@globix.net [MPLS: Label 673 Exp 0]  30 ms
ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
dnsad...@globix.net  14 ms gig4-16.core2.suw1.qualitytech.com
(64.88.172.145) [AS20141] dnsad...@globix.net  34 ms
 7  ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
dnsad...@globix.net  19 ms  13 ms  13 ms
 8  core3.tge4-1-bbnet1.acs.pnap.net (64.94.0.3) [AS14745]
hostmas...@pnap.net  14 ms core3.tge4-1-bbnet2.acs.pnap.net (64.94.0.67)
[AS14745] hostmas...@pnap.net  14 ms  15 ms
 9  core3.tge4-1-bbnet2.acs.pnap.

nanog@nanog.org

[Brian Raaen]

I have sent a complaint to the AT&T abuse contact from my ARIN contact
address asking them to stop announcing the route.

-- 
-
Brian Raaen
Network Engineer
email: /bra...@zcorum.com/ 

Brian Raaen wrote:
> I appreciate the offline replies.  After doing some more research myself
> the issue appears to be related to the fact that AT&T is announcing the
> block directly.  I did show "ip bgp 72.14.76.0" in a couple routers and
> some showed the route originating in 701 (they were able to reach it)
> and others showed it originating in 7018 (and they could not reach it).
>
> Here is my question, since I am an ARIN admin contact for the IP block
> how is the best way to get AT&T to quit announcing the block.
>
>   
<>

nanog@nanog.org

[Brian Raaen]

I appreciate the offline replies.  After doing some more research myself
the issue appears to be related to the fact that AT&T is announcing the
block directly.  I did show "ip bgp 72.14.76.0" in a couple routers and
some showed the route originating in 701 (they were able to reach it)
and others showed it originating in 7018 (and they could not reach it).

Here is my question, since I am an ARIN admin contact for the IP block
how is the best way to get AT&T to quit announcing the block.

-- 
-
Brian Raaen
Network Engineer
email: /bra...@zcorum.com/ 

Brian Raaen wrote:
> I'm not sure where to take this issue.  The Regular AT&T NOC contacts
> are refusing to talk to me since I do not have a circuit ID, and do not
> seem to have any understanding about transiting issues.  I am unable to
> fully monitor and manage a router I control, as all traffic bound to its
> lan IP that transits through the AT&T network is blocked.  The Router is
> connected to a Verizon circuit, but any connection that transits through
> AT&T is blocked.  The ip in Question is from a direct ARIN allocation
> that I control.  I have attached a ping demonstrating that I am
> receiving an ICMP deny from an AT&T core router.  I have also attached a
> traceroute to both the offending IP and the WAN IP which appears to be
> working.
>
> bra...@brian-debian:~$ ping gw.bwtc.net
> PING gw.bwtc.net (72.14.76.1) 56(84) bytes of data.
> >From 12.89.27.105 icmp_seq=1 Packet filtered
> >From 12.89.27.105 icmp_seq=3 Packet filtered
> ^C
> --- gw.bwtc.net ping statistics ---
> 4 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3004ms
>
>
> bra...@brian-debian:~$ sudo traceroute-nanog -AO gw.bwtc.net
> [sudo] password for braaen:
> traceroute to gw.bwtc.net (72.14.76.1), 64 hops max, 40 byte packets
>  1  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms 
> 3 ms  3 ms
>  2  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms 
> 3 ms  4 ms
>  3  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms
> rtrs00.america.net (69.60.176.21) [AS4452] d...@america.net  13 ms
> 69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms
>  4  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  12 ms  35 ms  17 ms
>  5  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
> dnsad...@globix.net [MPLS: Label 673 Exp 0]  15 ms  14 ms  25 ms
>  6  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
> dnsad...@globix.net  14 ms  14 ms  18 ms
>  7  ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
> dnsad...@globix.net  14 ms  12 ms  14 ms
>  8  border11.tge3-3.qts-1.acs.pnap.net (64.94.3.113) [AS14745]
> hostmas...@pnap.net  14 ms  14 ms  14 ms
>  9  core1.te2-2-bbnet2.acs002.pnap.net (64.94.0.79) [AS14745]
> hostmas...@pnap.net  14 ms core1.te2-1-bbnet1.acs002.pnap.net
> (64.94.0.15) [AS14745] hostmas...@pnap.net  14 ms 12.86.102.5
> (12.86.102.5) [] rm-hostmas...@ems.att.com  14 ms
> 10  12.86.102.5 (12.86.102.5) [] rm-hostmas...@ems.att.com  13 ms 
> 23 ms  13 ms
> 11  cr1.attga.ip.att.net (12.122.141.2) []
> rm-hostmas...@ems.att.com [MPLS: Label 16745 Exp 0]  40 ms
> cr2.ormfl.ip.att.net (12.122.5.141) [] rm-hostmas...@ems.att.com
> [MPLS: Label 20348 Exp 0] More labels  40 ms More labels  40 ms
> 12  cr2.ormfl.ip.att.net (12.122.5.141) []
> rm-hostmas...@ems.att.com More labels  40 ms More labels  41 ms More
> labels  40 ms
> 13  cr2.nwrla.ip.att.net (12.122.30.77) []
> rm-hostmas...@ems.att.com [MPLS: Label 0 Exp 0] More labels  40 ms
> gar1.nwrla.ip.att.net (12.123.153.85) []
> rm-hostmas...@ems.att.com  38 ms  38 ms
> 14  gar1.nwrla.ip.att.net (12.123.153.85) []
> rm-hostmas...@ems.att.com  50 ms  38 ms  38 ms
> 15  12.89.27.106 (12.89.27.106) [] rm-hostmas...@ems.att.com  43
> ms  44 ms  44 ms
> 16  * * 12.89.27.105 (12.89.27.105) [] rm-hostmas...@ems.att.com 
> 44 ms !A
>
>
>
>
> bra...@brian-debian:~$ sudo traceroute-nanog -AO 157.130.26.166
> traceroute to 157.130.26.166 (157.130.26.166), 64 hops max, 40 byte packets
>  1  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  4 ms 
> 3 ms  6 ms
>  2  gw-alpha.america.net (69.60.176.65) [AS4452] d...@america.net  3 ms 
> 3 ms  3 ms
>  3  rtrs00.america.net (69.60.176.21) [AS4452] d...@america.net  14 ms 
> 13 ms  13 ms
>  4  69.60.160.8 (69.60.160.8) [AS4452] d...@america.net  13 ms  13 ms  12 ms
>  5  66.0.192.194 (66.0.192.194) [AS20141] d...@deltacom.net  13 ms  13
> ms  15 ms
>  6  gig4-16.core2.suw1.qualitytech.com (64.88.172.145) [AS20141]
> dnsad...@globix.net [MPLS: Label 673 Exp 0]  30 ms
> ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
> dnsad...@globix.net  14 ms gig4-16.core2.suw1.qualitytech.com
> (64.88.172.145) [AS20141] dnsad...@globix.net  34 ms
>  7  ten8-3.peer1.suw1.qualitytech.com (64.88.172.197) [AS20141]
> dnsad...@globix.net  19 ms  13 ms  13 ms
>  8  core3.tge4-1-bbnet1.acs.pnap.net (64.94.0.3) [AS14745]
> hostmas...@pnap.net  14 ms core

nanog@nanog.org

[Jay Hennigan]

Brian Raaen wrote:

I appreciate the offline replies.  After doing some more research myself
the issue appears to be related to the fact that AT&T is announcing the
block directly.  I did show "ip bgp 72.14.76.0" in a couple routers and
some showed the route originating in 701 (they were able to reach it)
and others showed it originating in 7018 (and they could not reach it).

Here is my question, since I am an ARIN admin contact for the IP block
how is the best way to get AT&T to quit announcing the block.


If they absolutely refuse to talk to you, have someone who is an AT&T 
customer open a ticket with them about being unable to reach your network.


I would suspect that the discussion here. may get their attention.

--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

nanog@nanog.org

[Brian Raaen]

I have not seen any changes yet, although I did get an automated
response from their abuse address that they received my message.  Also,
to answer another question I have not changed backbones in over two
years.  I largely suspect that this is an issue of a simple typo and not
anything malicious.

-- 
-
Brian Raaen
Network Engineer
email: /bra...@zcorum.com/ 


Gustavo Rodrigues Ramos wrote:
> Hi Brian, has someone from at&t contacted you or have you noticed any change?
>
> Thanks,
> Gustavo.
>
>
> On Thu, Sep 3, 2009 at 9:43 AM, Brian Raaen wrote:
>   
>> I have sent a complaint to the AT&T abuse contact from my ARIN contact
>> address asking them to stop announcing the route.
>>
>> --
>> -
>> Brian Raaen
>> Network Engineer
>> email: /bra...@zcorum.com/ 
>>
>> Brian Raaen wrote:
>> 
>>> I appreciate the offline replies.  After doing some more research myself
>>> the issue appears to be related to the fact that AT&T is announcing the
>>> block directly.  I did show "ip bgp 72.14.76.0" in a couple routers and
>>> some showed the route originating in 701 (they were able to reach it)
>>> and others showed it originating in 7018 (and they could not reach it).
>>>
>>> Here is my question, since I am an ARIN admin contact for the IP block
>>> how is the best way to get AT&T to quit announcing the block.
>>>
>>>
>>>   
<>

nanog@nanog.org

[Brian Raaen]

No is just seems to die in their core network.

Dorn Hetzel wrote:
> If you traceroute from someplace that sees the announcement from ATT,
> does it actually go anywhere beyond the core in ATT (as if they are
> sending it to any customer circuit of their) ?
>
> On Thu, Sep 3, 2009 at 10:23 AM, Brian Raaen  > wrote:
>
> I have not seen any changes yet, although I did get an automated
> response from their abuse address that they received my message.
>  Also,
> to answer another question I have not changed backbones in over two
> years.  I largely suspect that this is an issue of a simple typo
> and not
> anything malicious.
>
> --
> -
> Brian Raaen
> Network Engineer
> email: /bra...@zcorum.com/ 
> >
>
>
> Gustavo Rodrigues Ramos wrote:
> > Hi Brian, has someone from at&t contacted you or have you
> noticed any change?
> >
> > Thanks,
> > Gustavo.
> >
> >
> > On Thu, Sep 3, 2009 at 9:43 AM, Brian Raaen > wrote:
> >
> >> I have sent a complaint to the AT&T abuse contact from my ARIN
> contact
> >> address asking them to stop announcing the route.
> >>
> >> --
> >> -
> >> Brian Raaen
> >> Network Engineer
> >> email: /bra...@zcorum.com/ 
> >
> >>
> >> Brian Raaen wrote:
> >>
> >>> I appreciate the offline replies.  After doing some more
> research myself
> >>> the issue appears to be related to the fact that AT&T is
> announcing the
> >>> block directly.  I did show "ip bgp 72.14.76.0" in a couple
> routers and
> >>> some showed the route originating in 701 (they were able to
> reach it)
> >>> and others showed it originating in 7018 (and they could not
> reach it).
> >>>
> >>> Here is my question, since I am an ARIN admin contact for the
> IP block
> >>> how is the best way to get AT&T to quit announcing the block.
> >>>
> >>>
> >>>
>
>

-- 
-
Brian Raaen
Network Engineer
email: /bra...@zcorum.com/ 
Telephone /678-507-5000x5574/
<>

Single router for P/PE functions

[Serge Vautour]

Hello,

I'm pretty confident that a router can be used to perform P & PE functions 
simultaneously. What about from a best practice perspective? Is this something 
that should be completely avoided? Why? We're considering doing this as a 
temporary workaround but we all know temporary usually lasts a long time. I'd 
like to know what kind of mess awaits if we let this one go.

Thanks,
Serge



  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now
http://ca.toolbar.yahoo.com.

DENOG1 conference registrations are now open

[Marcus Stoegbauer]

Hi all,

the German Network Operators Group (DENOG) is holding its first meeting
on the 5th of November 2009 in Frankfurt, Germany.

Registrations are now open at http://meeting.denog.de/registration_en.html
Please note that you can benefit from our early bird rebate if you
register early. A full agenda will be available until the end of September.

A quick reminder: We are still accepting applications for presentations
or short lightning talks. If you are interested please read our CfP at
http://meeting.denog.de/cfp_en.html

Hope to see you in November,

   Marcus

Got this from Educause...

[Robert Mathews (OSIA)]

Apologies in advance, to those who, as administrators of EDU domains,
may have already received this from EDUCASE...

Finally, DNSSEC is going to make its way to ".edu"  Are we ready?   Has
resistance been obliterated?
Test-bed implementation..  Sept, '09
--
 Original Message 

Subject: Security of .edu Internet Domain to Increase

September 3, 2009, Washington, D.C.—EDUCAUSE and VeriSign announced
today the initiation of a
project to enhance Internet reliability and stability. By the end of
March 2010, the project will deploy a
security system known as Domain Name Security Extensions (DNSSEC) within
the .edu portion of the
Internet, which EDUCAUSE manages under a cooperative agreement with the
U.S. Department of
Commerce. When the project is completed, institutions whose domain names
end in .edu will be able to
incorporate a digital signature into those names to limit a variety of
security vulnerabilities.
 
The Domain Name System (DNS) is the part of the Internet that translates
names such as "educause.edu"
into numeric addresses (for example, 198.59.61.90). All Internet
applications—from electronic mail to online
banking—depend on the accuracy and integrity of this translation. Over
the years, Internet security experts
have discovered a variety of ways that DNS translation may be
compromised. The DNSSEC security system
limits the problem by allowing owners of domain names to provide a
digital signature that adds an extra level
of authentication to the translation process.
 
The project plan includes a test-bed implementation, targeted for
September 2009, to allow predeployment
testing by a number of selected campuses in a nonproduction environment.
Final deployment of DNSSEC
for .edu will build on the previously announced U.S. Department of
Commerce project to deploy DNSSEC
at the authoritative root zone of the Internet.

[  ]

NANOG47 - Program Committee will meet next week to review second round submissions

[Ren Provo]

Hi folks,

There are many interesting abstracts in the tool at
http://pc.nanog.org and we hope to see a few more presentations arrive
prior to next Wednesday.

Lightning talks will not be accepted until October.  That doesn't mean
you can't kick out that first draft to a friend for inspiration!

Election season is also drawing close.  The election timeline is now
online at http://www.nanog.org/governance/elections/2009elections/

Last but not least, the hotel group rate expires this month -
http://www.nanog.org/meetings/nanog47/hotel.php

Cheers, -ren

draft-iana-ipv4-examples

[Ron Bonica]

Folks,

The IETF has recently passed draft-iana-rfc3330bis-08. This draft
documents the fact that the following address ranges have been reserved
for documentation:

- 192.0.2.0/24 (TEST-NET-1)
- 198.51.100.0/24 (TEST-NET-2)
- 203.0.113.0/24 (TEST-NET-3)

In addition, some authors have used 128.66.0.0/16 (TEST-B) for example
purposes. There is no RFC that talks about this block, but my
understanding is that IANA/ARIN have marked it as reserved. If you
search the Internet you will find at least some number of examples and
firewall rule sets that use this block, but I have no good idea about
how widespread such usage is.

What should we do about this block? Some of the potential answers
include documenting its role, marking it as reserved but deprecating its
use in examples, and returning it to the free pool immediately (with a
warning sign about possible filtering problems).

Comments?

  Ron

83.222.0.0/19 Unroutable on Verizon

[Peter Beckman]

I can't reach 83.222.0.0/19 from Verizon, but I can via Cox Communications
Business Fiber as well as Level3.  Dies at a peering point it seems:

HOST: homeLoss%   Snt   Last   Avg  Best  Wrst StDev
  1. mph   0.0%200.7   0.6   0.5   0.7   0.1
  2. 10.1.41.890.0%202.3   3.6   1.7  26.4   5.6
  3. G2-0-3-891.WASHDC-LCR-08.ver  0.0%202.1   1.9   1.6   2.2   0.2
  4. so-1-1-0-0.RES-BB-RTR2.veriz  0.0%202.3   2.4   2.2   2.8   0.1
  5. 0.so-6-1-0.XL4.IAD8.ALTER.NE  0.0%202.8   2.8   2.6   3.0   0.1
  6. 0.xe-8-1-0.BR1.IAD8.ALTER.NE  0.0%205.1   8.4   3.0  40.3   9.4
  7. 64.212.107.1570.0%20  203.2  14.0   3.0 203.2  44.6
  8. ???  100.0200.0   0.0   0.0   0.0   0.0

Hop 7 alternates between 64.212.107.157 (GBLX) and 204.255.169.202 (MCI dba
Verizon) and dies after that. 83.222.32.0/19 seems to route correctly.

Can anyone else confirm?  Bad BGP Announcement?

Beckman
---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: 83.222.0.0/19 Unroutable on Verizon

[Christopher Morrow]

On Thu, Sep 3, 2009 at 5:20 PM, Peter Beckman wrote:
> I can't reach 83.222.0.0/19 from Verizon, but I can via Cox Communications
> Business Fiber as well as Level3.  Dies at a peering point it seems:
>
> HOST: home                        Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. mph                           0.0%    20    0.7   0.6   0.5   0.7   0.1
>  2. 10.1.41.89                    0.0%    20    2.3   3.6   1.7  26.4   5.6
>  3. G2-0-3-891.WASHDC-LCR-08.ver  0.0%    20    2.1   1.9   1.6   2.2   0.2
>  4. so-1-1-0-0.RES-BB-RTR2.veriz  0.0%    20    2.3   2.4   2.2   2.8   0.1
>  5. 0.so-6-1-0.XL4.IAD8.ALTER.NE  0.0%    20    2.8   2.8   2.6   3.0   0.1
>  6. 0.xe-8-1-0.BR1.IAD8.ALTER.NE  0.0%    20    5.1   8.4   3.0  40.3   9.4
>  7. 64.212.107.157                0.0%    20  203.2  14.0   3.0 203.2  44.6
>  8. ???                          100.0    20    0.0   0.0   0.0   0.0   0.0

it's actually being handed off to the next provider... so, maybe this
thread is mis-named? this looks like GBLX route filtering or traffic
filtering. From twtelecom I see this die inside 'retn.net' 111ms from
ashburn-ish. (so, in emea somewhere)

-chris

>
> Hop 7 alternates between 64.212.107.157 (GBLX) and 204.255.169.202 (MCI dba
> Verizon) and dies after that. 83.222.32.0/19 seems to route correctly.
>
> Can anyone else confirm?  Bad BGP Announcement?
>
> Beckman
> ---
> Peter Beckman                                                  Internet Guy
> beck...@angryox.com                                 http://www.angryox.com/
> ---
>
>

Re: 83.222.0.0/19 Unroutable on Verizon

[Cord MacLeod]

On Sep 3, 2009, at 2:20 PM, Peter Beckman wrote:

I can't reach 83.222.0.0/19 from Verizon, but I can via Cox  
Communications

Business Fiber as well as Level3.  Dies at a peering point it seems:


route-views.oregon-ix.net>sh ip bgp 83.222.0.0
BGP routing table entry for 83.222.0.0/19, version 14706715
Paths: (34 available, best #6, table Default-IP-Routing-Table)
  Not advertised to any peer
  1221 4637 3549 9002 25532
203.62.252.186 from 203.62.252.186 (203.62.252.186)
  Origin IGP, localpref 100, valid, external
  3549 9002 25532
208.51.134.254 from 208.51.134.254 (208.178.61.33)
  Origin IGP, metric 14088, localpref 100, valid, external
  3561 9002 25532
206.24.210.102 from 206.24.210.102 (206.24.210.102)
  Origin IGP, localpref 100, valid, external
  16150 9002 25532
217.75.96.60 from 217.75.96.60 (217.75.96.60)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 16150:63392 16150:65215 16150:65320
  3277 3267 25532
194.85.4.55 from 194.85.4.55 (194.85.4.16)
  Origin IGP, localpref 100, valid, external
  Community: 3277:3267 3277:65100 3277:65320 3277:65326
  3267 25532
194.85.40.15 from 194.85.40.15 (193.232.80.7)
  Origin IGP, localpref 100, valid, external, best
  2914 9002 25532
129.250.0.171 from 129.250.0.171 (129.250.0.79)
  Origin IGP, metric 308, localpref 100, valid, external
  Community: 2914:410 2914:2202 2914:3200
  3582 4600 11537 9002 25532
128.223.253.8 from 128.223.253.8 (128.223.253.8)
  Origin IGP, localpref 100, valid, external
  Community: 3582:567 4600:199
  6079 9002 25532
207.172.6.1 from 207.172.6.1 (207.172.6.1)
  Origin IGP, metric 0, localpref 100, valid, external
  2828 3561 9002 25532
65.106.7.139 from 65.106.7.139 (66.239.189.139)
  Origin IGP, metric 3, localpref 100, valid, external
  2905 702 9002 25532
196.7.106.245 from 196.7.106.245 (196.7.106.245)
  Origin IGP, metric 0, localpref 100, valid, external
   9002 25532
193.0.0.56 from 193.0.0.56 (193.0.0.56)
  Origin IGP, localpref 100, valid, external
  701 3549 9002 25532
157.130.10.233 from 157.130.10.233 (137.39.3.60)
  ^^^


  Origin IGP, localpref 100, valid, external
  812 174 3561 9002 25532
64.71.255.61 from 64.71.255.61 (64.71.255.61)
  Origin IGP, localpref 100, valid, external
  7660 2516 3549 9002 25532
203.181.248.168 from 203.181.248.168 (203.181.248.168)
  Origin IGP, localpref 100, valid, external
  Community: 2516:1030
  3257 3549 9002 25532
89.149.178.10 from 89.149.178.10 (213.200.87.91)
  Origin IGP, metric 10, localpref 100, valid, external
  Community: 3257:8012 3257:30070 3257:50001 3257:54900 3257:54901
  6079 9002 25532
207.172.6.20 from 207.172.6.20 (207.172.6.20)
  Origin IGP, metric 117, localpref 100, valid, external
  6453 3549 9002 25532
207.45.223.244 from 207.45.223.244 (66.110.0.124)
  Origin IGP, localpref 100, valid, external
  6453 3549 9002 25532
195.219.96.239 from 195.219.96.239 (195.219.96.239)
  Origin IGP, localpref 100, valid, external
  852 174 3549 9002 25532
154.11.11.113 from 154.11.11.113 (154.11.11.113)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 852:180
  1668 3561 9002 25532
66.185.128.48 from 66.185.128.48 (66.185.128.50)
  Origin IGP, metric 511, localpref 100, valid, external
  4826 9002 25532
114.31.199.1 from 114.31.199.1 (114.31.199.1)
  Origin IGP, localpref 100, valid, external
  852 174 3549 9002 25532
154.11.98.225 from 154.11.98.225 (154.11.98.225)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 852:180
  8075 9002 25532
207.46.32.34 from 207.46.32.34 (207.46.32.34)
  Origin IGP, localpref 100, valid, external
  2914 9002 25532
129.250.0.11 from 129.250.0.11 (129.250.0.51)
  Origin IGP, metric 393, localpref 100, valid, external
  Community: 2914:410 2914:2202 2914:3200
  2497 9002 25532
202.232.0.2 from 202.232.0.2 (202.232.0.2)
  Origin IGP, localpref 100, valid, external
  7018 3561 9002 25532
12.0.1.63 from 12.0.1.63 (12.0.1.63)
  Origin IGP, localpref 100, valid, external
  Community: 7018:5000
  3356 9002 25532
4.69.184.193 from 4.69.184.193 (4.68.3.50)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 3356:2 3356:22 3356:100 3356:123 3356:507 3356:2076  
65000:0

  286 3549 9002 25532
134.222.87.1 from 134.222.87.1 (134.222.86.1)
  Origin IGP, localpref 100, valid, external
  Community: 286:18 286:19 286:28 286:29 286:800 286:888 286:3049  
286:4017 3549:350 3549:4811 3549:31752

  6539 9002 25532
66.59.190.221 from 66.59.190.221 (66.59.190.221)
  Origin IGP, localpref 100, valid, external
  3303 9002 25532
164.128.32.11 from 164.128.32.11 (164.128.32.11)
  Origin IGP, localpref 100, valid, external
  Community: 3303:1004 3303:1006 3303:3054
  7500 2497 9002 25532
2

Re: 83.222.0.0/19 Unroutable on Verizon

[Joe Provo]

[comment: subject is irksome - "Unroutable"? That is meaningless]

On Thu, Sep 03, 2009 at 05:20:23PM -0400, Peter Beckman wrote:
> I can't reach 83.222.0.0/19 from Verizon, but I can via Cox Communications
> Business Fiber as well as Level3.  Dies at a peering point it seems:
> 
> HOST: homeLoss%   Snt   Last   Avg  Best  Wrst StDev
>   1. mph   0.0%200.7   0.6   0.5   0.7   0.1
[snip]

Presumably ICMP probes - those are frequently rate-limited as
counter-measures you realize?  And which Verizon? 701 clearly shows it
in its tables and packets go there. Since your mtr or whatever shows the
traffic reaching a GBLX address, so you likely want to reach out to them.

> Can anyone else confirm?  Bad BGP Announcement?

What does your table say? How does that compare to data in RIS, route-views,
etc?  Independent investigation with table data -if your concern is the
state of someone's "routing"- would help.

Cheers,

Joe

-- 
 RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

Re: 83.222.0.0/19 Unreachable on Verizon

[Peter Beckman]

Subject updated to be less wrong.

On Thu, 3 Sep 2009, Peter Beckman wrote:


I can't reach 83.222.0.0/19 from Verizon, but I can via Cox Communications
Business Fiber as well as Level3.  Dies at a peering point it seems:

HOST: homeLoss%   Snt   Last   Avg  Best  Wrst StDev
 1. mph   0.0%200.7   0.6   0.5   0.7   0.1
 2. 10.1.41.890.0%202.3   3.6   1.7  26.4   5.6
 3. G2-0-3-891.WASHDC-LCR-08.ver  0.0%202.1   1.9   1.6   2.2   0.2
 4. so-1-1-0-0.RES-BB-RTR2.veriz  0.0%202.3   2.4   2.2   2.8   0.1
 5. 0.so-6-1-0.XL4.IAD8.ALTER.NE  0.0%202.8   2.8   2.6   3.0   0.1
 6. 0.xe-8-1-0.BR1.IAD8.ALTER.NE  0.0%205.1   8.4   3.0  40.3   9.4
 7. 64.212.107.1570.0%20  203.2  14.0   3.0 203.2  44.6
 8. ???  100.0200.0   0.0   0.0   0.0   0.0

Hop 7 alternates between 64.212.107.157 (GBLX) and 204.255.169.202 (MCI dba
Verizon) and dies after that. 83.222.32.0/19 seems to route correctly.


 I've called both the Verizon NOC and UUNET NOC, talked to friendly people
 who told me nicely to go talk to someone else.  My next step will be to
 contact ip-...@verizonbusiness.com as per the netops NOC list.

 Any IPs in 83.222.0.0/19 that ARE reachable on L3 and Cox are not
 reachable on Verizon.  Please note I'm not doing traceroutes to 83.222.0.0
 or 83.222.0.0/19.  I'm tracing hosts that are known to be up and
 traceable, and are within this block.

 An interesting side note -- I can't get to retn.net either on Verizon, but
 can elsewhere, which is 81.222.33.89.

 As an end user smart enough to figure out why a website isn't loading, it
 is a GIANT PAIN and next to impossible to report a network issue when you
 are a non-customer, non-ISP employee.  This is why I posted this on NANOG,
 because I'm trying to promote dialog between people concerning the
 operation of IP networks.

 Verizon asked me to reboot my router.  I hung up.

Beckman
---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Power basics- any resources?

[Darren Bolding]

I need to teach an operations group (Systems, Network, Security, IT folks)
some basics of power as it applies to the team.  Normal things they will see
and should understand when they are planning on bringing equipment online
etc.
I have an idea of many things to talk about, particularly as they apply to
our environment, but I was hoping there might be some publicly available
slides or docs that I could take advantage of.

I'll be happy to share anything we come up with- though this may just be me
in front of a whiteboard.

Here are some of the questions I plan to cover:

What are amps, volts and watts?

What are Volt-Amps, and why do they matter?

How much can I load that circuit?

How does a breaker work?

Where are the breakers at our sites?

What should you do if a breaker trips?

How do we know how much load a device will place on a circuit?

How do we monitor power usage?

Basic safety.

Redundant power.


Thanks for any pointers!

-- 
--  Darren Bolding  --
--  dar...@bolding.org   --

Re: Request for a pointer - Linux modifying DSCP on replies?

[Darren Bolding]

I wanted to go ahead and reply back with what I figured out.
The easiest way to solve this problem turned out to be to utilize netfilters
CONNMARK module, which sadly is not available in some older but still used
linux kernels.

Syntax for this is as follows:
# Set outgoing DSCP on connections to same as incoming DSCP
-A PREROUTING -m dscp --dscp 1 -j CONNMARK --set-mark 1
-A POSTROUTING -m connmark --mark 1 -j DSCP --set-dscp 1
-A PREROUTING -m dscp --dscp 2 -j CONNMARK --set-mark 2
-A POSTROUTING -m connmark --mark 2 -j DSCP --set-dscp 2

And this goes on for all 63 possible non-zero markings.

This seems to have had negligible performance or memory impact on some very
busy hosts, so it seems like a viable solution.

--D

On Mon, Aug 17, 2009 at 4:08 PM, Darren Bolding  wrote:

> Steve,
> Perhaps it is outside the DS domain, and that is the issue.  It seems odd
> that the behavior with ICMP/Ping is different than that with TCP however.
>  Not sure which is technically correct, but I am going to follow up on some
> of the pointers I've gotten to try and learn that.  It just seems natural to
> me that connection oriented traffic would have the same markings on both
> sides of the conversation unless explicitly told otherwise.
>
> I would love to be able to mark the traffic at the edge of the DS domain- I
> do this at ingress from one location.  The challenge I am trying to solve is
> that the DS edge switch will not reliably know how to policy-route traffic
> unless it has been previously marked.
>
> To clarify, as in many other environments, we have stateful devices such as
> firewalls and load balancers.  I want to be able to route traffic
> that ingressed through one of these devices to egress through it as well.
>  This is entirely solvable by splitting equipment functionally (a cluster of
> servers and associated network equipment, real or virtual associated with a
> service) or by employing SNAT solutions.  However, for various reasons these
> solutions are not preferred in our environment, and I dare say I am not
> alone in that viewpoint.
>
> What I am trying to deploy now is a system where the stateful equipment (in
> this case a load balancer) has its traffic to the rest of the network tagged
> on ingress.  Since I am using Cisco 6500's with sup720's, I can classify and
> mark the traffic with a DSCP setting via PFC/DFC hardware.  I then inspect
> traffic at the layer-3 edge for the various pools of servers.  Depending on
> the DSCP marking of the packet, I change the next-hop.  Since this is
> implemented through an extended ACL for a route-map it is handled in
> hardware (a good thing).  Research shows that I can implement similar
> functionality in hardware on L3 switching gear from Juniper, Foundry, etc.
> so I am not boxing myself into a vendor.
>
> I don't believe Cisco supports using reflexive-acl's to apply policy
> routing, and even if they did, that would likely swamp our sup's CPU's, so I
> don't believe maintaining a stateful filter on the switch is viable.
>
> This all works as expected for Ping's and the ICMP replies.  It breaks down
> for TCP http/mysql connections.
>
> It sounds like the correct (per-spec) solution may be to have the Linux
> servers track the incoming connections DSCP setting and mark the outgoing
> packets related to those connections.  I am not at all certain this will not
> hit the servers CPU's more than desired or require additional
> connection-tracking resources than the ones we currently implement via
> iptables.
>
> Is there some other design option I am not considering?
>
> Thanks to those of you who have replied so far, it is at least a start down
> some additional paths of research for me!  It's been since the days of BSDI
> that I have been involved in system networking internals, so I have been at
> a loss who to even ask!
>
> --D
>
> On Mon, Aug 17, 2009 at 2:44 PM, Steve Miller  wrote:
>
>> Would not the end station be considered to be outside of the DS
>> domain?  It does not necessarily make sense (to me) for reply packets
>> to be marked unless they are appropriate classified and marked on the
>> return path at the point they re-enter the DS domain.
>>
>> I would imagine that iptables and the DSCP target would do what you
>> wanted, yes.  I'd consider classifying and marking traffic at whatever
>> switch you would consider to be at the edge of the DS domain
>> (connected to this server.)
>>
>> -Steve
>>
>> 2009/8/17 Darren Bolding :
>> > I believe this is operational content, but may well be better asked
>> > somewhere else.  I would love to have a pointer to another list/website.
>> > I am looking to do some policy routing based on DSCP marking, and I have
>> > this all working inside the networking equipment.  I DSCP mark some
>> packets
>> > at ingress and I policy-route others based on ACL's matching those DSCP
>> > markings.  This should allow me to solve some problems in a rather
>> elegant
>> > manner, if I do say so myself.
>> >
>> > And

Re: Power basics- any resources?

[David B. Peterson]

When it's ok to use a C14 to NEMA 5-15R cable and when it's really NOT  
ok..



On Sep 3, 2009, at 6:22 PM, Darren Bolding wrote:

I need to teach an operations group (Systems, Network, Security, IT  
folks)
some basics of power as it applies to the team.  Normal things they  
will see
and should understand when they are planning on bringing equipment  
online

etc.
I have an idea of many things to talk about, particularly as they  
apply to
our environment, but I was hoping there might be some publicly  
available

slides or docs that I could take advantage of.

I'll be happy to share anything we come up with- though this may  
just be me

in front of a whiteboard.

Here are some of the questions I plan to cover:

What are amps, volts and watts?

What are Volt-Amps, and why do they matter?

How much can I load that circuit?

How does a breaker work?

Where are the breakers at our sites?

What should you do if a breaker trips?

How do we know how much load a device will place on a circuit?

How do we monitor power usage?

Basic safety.

Redundant power.


Thanks for any pointers!

--
--  Darren Bolding  --
--  dar...@bolding.org   --

Re: Power basics- any resources?

[Stefan]

APC (http://www.apc.com) has lots of info Data Center related
(...support...), where you could find some good stuff.

HTH

On 9/3/09, Darren Bolding  wrote:
> I need to teach an operations group (Systems, Network, Security, IT folks)
> some basics of power as it applies to the team.  Normal things they will see
> and should understand when they are planning on bringing equipment online
> etc.
> I have an idea of many things to talk about, particularly as they apply to
> our environment, but I was hoping there might be some publicly available
> slides or docs that I could take advantage of.
>
> I'll be happy to share anything we come up with- though this may just be me
> in front of a whiteboard.
>
> Here are some of the questions I plan to cover:
>
> What are amps, volts and watts?
>
> What are Volt-Amps, and why do they matter?
>
> How much can I load that circuit?
>
> How does a breaker work?
>
> Where are the breakers at our sites?
>
> What should you do if a breaker trips?
>
> How do we know how much load a device will place on a circuit?
>
> How do we monitor power usage?
>
> Basic safety.
>
> Redundant power.
>
>
> Thanks for any pointers!
>
> --
> --  Darren Bolding  --
> --  dar...@bolding.org   --
>

-- 
Sent from my mobile device

***Stefan Mititelu
http://twitter.com/netfortius
http://www.linkedin.com/in/netfortius

Re: Power basics- any resources?

[Jorge Amodio]

Remind them that power does not come from "the wall", there are
many things they have to keep an eye on, and know where they
are and what not to touch and who can touch and when.

ie Transformers, transfer switches, dc power plants if you have them,
etc, etc.

My .02

Re: Single router for P/PE functions

[Erik Schmersal]

> Not only can they, it's done quite frequently. I just completed a
>> deployment of seven Juniper MX series routers in a dual ring configuration,
>> all acting as combination P/PE devices for a state government WAN backbone.
>> Works like a charm.
>>
>> Erik
>>
>>
>> On Thu, Sep 3, 2009 at 10:20 AM, Serge Vautour wrote:
>>
>>> Hello,
>>>
>>> I'm pretty confident that a router can be used to perform P & PE
>>> functions simultaneously. What about from a best practice perspective? Is
>>> this something that should be completely avoided? Why? We're considering
>>> doing this as a temporary workaround but we all know temporary usually lasts
>>> a long time. I'd like to know what kind of mess awaits if we let this one
>>> go.
>>>
>>> Thanks,
>>> Serge
>>>
>>>
>>>
>>>  __
>>> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
>>> favourite sites. Download it now
>>> http://ca.toolbar.yahoo.com.
>>>
>>>
>>
>

Re: Single router for P/PE functions

[William McCall]

Kinda depends on what you're doing exactly, but like Erik said, it certainly
possible and depending on your particular needs, it might not be much of an
issue at all.

Can you describe your scenario a bit more?

--WM

On Thu, Sep 3, 2009 at 10:20 AM, Serge Vautour wrote:

> Hello,
>
> I'm pretty confident that a router can be used to perform P & PE functions
> simultaneously. What about from a best practice perspective? Is this
> something that should be completely avoided? Why? We're considering doing
> this as a temporary workaround but we all know temporary usually lasts a
> long time. I'd like to know what kind of mess awaits if we let this one go.
>
> Thanks,
> Serge
>
>
>
>  __
> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
> favourite sites. Download it now
> http://ca.toolbar.yahoo.com.
>
>


-- 
William McCall, CCIE #25044

Re: Single router for P/PE functions

[Mikael Abrahamsson]

On Thu, 3 Sep 2009, Serge Vautour wrote:

I'm pretty confident that a router can be used to perform P & PE 
functions simultaneously. What about from a best practice perspective? 
Is this something that should be completely avoided? Why? We're 
considering doing this as a temporary workaround but we all know 
temporary usually lasts a long time. I'd like to know what kind of mess 
awaits if we let this one go.


Collapsing P/PE functions certainly saves CAPEX, the downside is that you 
might need to reload your PE (affecting customers) due to a core feature 
upgrade or bug fix, or the other way around. With separate P and PE 
functions and PEs being dual attached to two Ps, you can reboot P layer 
with minimal end customer impact.


I'd imagine that in smaller networks it makes more sense to collapse 
compared to larger network, because a smaller network has fewer customers 
to be affected by each router problem.


It's basically "put all the eggs in one basket" kind of issue, it's easier 
to carry around but you lose more when something happens.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: picking up server vendor in a global scope..

[Mehmet Akcin]

Thank you for all your responses..

I thought i would drop a short recap note for those who will be  
reading this in the future while searching the same information.

I have been recommended by various people who have personally dealt  
the relations with server vendors around the world and many have  
recommended Sun as a global choice. 2nd most popular in the answers  
were HP.

Mehmet