- NANOG - lists.nanog.org

Tricky BGP into IGP Question
by Tim Wolfe 24 Jan '01

24 Jan '01

What is the preferred way to get transit customers routing information into your IGP so that BGP will announce the route to it's neighbors. 1===2a===2b====3 | 4 1 is the customer, announcing to 2a, who propogates 1's route to 2b and to 4. 2b will not announce the route to 3 as it doesn't have a route in it's routing table for 1's route. I was thinking about redistributing bgp into my igp using a route-map based on as-path filter, but that seems somewhat kludgy. What are you all doing to accomplish this or am I just missing something here? Thanks, --Tim ============================================= Timothy M. Wolfe CCNA, NSA Sr. Security Engineer tim(a)ignw.com InfoGroup Northwest 541.485.0957 x108 =============================================

3 2

Re: Tricky BGP into IGP Question
by Danny McPherson 24 Jan '01

24 Jan '01

I this 'trick' you're looking for is that of disabling BGP synchronization (i.e., 'no synchronization' in IOS parlance). Putting external things in your IGP is a really BAD idea, BTW. -danny > What is the preferred way to get transit customers routing information into > your IGP so that BGP will announce the route to it's neighbors. > > 1===2a===2b====3 > | > 4 > > 1 is the customer, announcing to 2a, who propogates 1's route to 2b and to > 4. 2b will not announce the route to 3 as it doesn't have a route in it's > routing table for 1's route. I was thinking about redistributing bgp into > my igp using a route-map based on as-path filter, but that seems somewhat > kludgy. What are you all doing to accomplish this or am I just missing > something here?

1 0

Broadwing Fiber cut, El Paso, TX
by Majdi S. Abbas 24 Jan '01

24 Jan '01

Broadwing is working on repairing a fiber cut in El Paso, TX. Their master ticket is 3677, with a current ETA of 6 hours. Expect lots of down-haul connectivity. --msa

1 0

Re: clue for the clueless please
by Ryan O'Connell 23 Jan '01

23 Jan '01

On Tue, Jan 23, 2001 at 01:59:41PM -0000, Peter Galbavy wrote: > Yes, we intentionally (for some other reason during testing) set the MTU on > the p2p link to 554 - oops. Will get it switched back... Still wondering > though - if a normal dial-up has a lower than 1500 MTU, why would they work. Sounds almost certainly like an MTU problem. Try www.bt.com, if that fails then it's pretty much definite. Microsoft are a bit silly for setting the DF bit on outbound packets, firewalls at web hosting facilities that block all ICMP are even more silly. Why on earth Microsoft, who must know about this problem, block ICMP on their kit I don't know... Most if not all dialup has an MTU of 1500. -- Ryan O'Connell - <ryan(a)complicity.co.uk> - http://www.complicity.co.uk I'm not losing my mind, no I'm not changing my lines, I'm just learning new things with the passage of time

3 2

clue for the clueless please
by Peter Galbavy 23 Jan '01

23 Jan '01

This is a Microsoft Passport / Hotmail access question, so if these are alien to you, please move on... Before anyone has a go at me, I have looked on their web site(s) and cannot find any policies or pointers that are outside "forgotten password" land etc. We have turned up a new customer for BGP multihoming with a new IP block from RIPE (217.71.224/20) and in testing we are having problems getting to certain sites. Normally I would attribute this to no reverse DNS (yet), but for Hotmail it is getting weird. The reverse DNS issue is in hand and is awaiting DNS servers to be up etc. The Hotmail issues (and maybe some other sites we have not yet got to) appear to be IP block related. Do "they" do some sort of geographical redirection or filtering based on IP block or AS number ? Testing from another IP (OK, the nearend point-to-point address on one of the routers) which also does not have reverse DNS but is in an older IP block, in a different AS works fine. The problem is the redirection from authentication -> mailbox. It just hangs. Tested with multiple browsers (lynx included ;) and all the same. And pointers would be greatly appreciated. -- Peter Galbavy Knowledge Matters Ltd. http://www.knowledge.com/

2 1

Re: Involuntary outages may start at 7am PST
by Henry R. Linneweh 23 Jan '01

23 Jan '01

PG&E is caught in its own self created mess. When Australia deregulated they were paying $89.00 per megawatt hour, part of the selling off of assets, in the frame of the contract it was stipulated that they would be able to buy power back from the buyer at a fixed rate the was predictable, and per that agreement there power costs dropped to $16.00 and $17.00 per megawatt hour. PG&E on the other hand had that option and decided to forgo it and buy on the spot market same with Southern California Edison. A major miscalculation. Next but not least there is the power exchange where power can be purchased at a better rate than from PG&E. There is plenty of juice on the grid, just not enough competitive marketing alignment to make it greater public knowledge. Anyway I am pooped out and I need some sleep so I will stop here for now. Roeland Meyer wrote: > > From: Nathan Stratton [mailto:nathan@robotics.net] > > Sent: Monday, January 22, 2001 7:27 PM > > > > On 22 Jan 2001, Sean Donelan wrote: > > > > > Have any Internet providers or private data centers announced any > > > voluntary "good neighbor" measures such as wider > > temperature and humdity > > > limits, lights-out operation, off-peak use of heavy > > electrical demands > > > for laser printers, etc. > > > > Don't take this the wrong way, but frankly I would not be > > happy if my colo > > providers started implementing wider temperature and humdity > > limits. I pay > > large amounts of money for colo and I want what I am paying > > for. This mess > > was caused by California regulators and very very greedy PG&E > > who gambled > > on lower rates and lost. PG&E should be forces to liquidate > > other out of > > state assets and buy power at the market. > > Unfortunately, you are wrong. PG&E is caught between a rock and the > generators. Generator cost has been gouged up over 700% and PG&E is forced > to maintain prices. There is plently of capacity if the generator companies > want to bring it online. Obviously, they don't, because they have a pretty > good blackmail hand right now. -- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | | working group | | Resilient Packet Transport | |--------------------------------| Henry R. Linneweh

1 0

Re: UUNET peering policy
by smd＠clock.org 23 Jan '01

23 Jan '01

| Arguably the "first" peering battle was whether UUnet had to pay for access | to the College Park NSS in 1989-90, which predates the CIX. No, Dave, that's only the first commercial peering battle. There are plenty of earlier fights that would not have been on anything remotely like com-priv, and were not nearly as polite as the dialogues between Rick and Al... Sean. (who used to put the NA into NANOG, but not any more :-) )

1 0

Maintenance Windows for Networks Spanning Multiple Time Zones
by tex＠delamancha.org 22 Jan '01

22 Jan '01

Folks, I am looking for input from other providers as to how they handle maintenance windows when their networks span multiple time zones. I would imagine that common windows are not expected to span more than 3 or 4 timezones due to the difficulty of finding a large enough block of time that works for all of the time zones in that window. So, what do you folks do? -tex

1 0

Re: Wierd Route (fwd)
by Richard A. Steenbergen 22 Jan '01

22 Jan '01

On Mon, Jan 22, 2001 at 12:12:47PM -0600, Jon Stanley wrote: > > I still fail to understand. If I am correct, AS3908 and AS209 are > somehow related in that Qwest was required to sell off all long haul > circuits that go into the former USWest territory. I wasn't aware > that this impacted the Qwest IP backbone as well, however this has > been brought to my attention. What I don't understand is why AS3908 > can't aggregate before advertising to C&W, which then goes into AS209. c&w only? As seen from route-server.eodus.net: Network Next Hop Metric LocPrf Weight Path *>i63.145.64.84/30 209.1.40.52 1000 0 2548 1 3908 i *>i63.145.64.212/30 209.1.40.52 1000 0 2548 1 3908 i *>i63.145.65.32/30 209.1.40.52 1000 0 2548 1 3908 i *>i63.145.65.76/30 209.1.40.52 1000 0 2548 1 3908 i ... *>i64.47.0.117/32 209.1.40.51 1000 0 1 3908 14995 ? *>i64.47.0.164/32 209.1.40.51 1000 0 1 3908 14995 ? etc etc etc 64.47.0.117 = l0.mcr1.n1.lax4.broadbandoffice.net 64.47.0.164 = l0.mcr2.dcae.broadbandoffice.net loopbacks? If for whatever reason qwest feels the need to leak their /30's and /32's to bbn, it could at least be no-export. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: Wierd Route
by John Osmon 22 Jan '01

22 Jan '01

Beware of things that still call themselves 'Qwest' when you see a traceroute touch the 14 state (former) US West territory. Qwest sold all of its "Long Distance Assets" in the region to Touch America, a wholly owned telecommunications subsidiary of The Montana Power Company. Folks in the 14 state region that used to buy transit from AS209 now get that transit from AS3908. If you sit and hunt, you can find many cases where traceroutes will show that AS1 and/or AS3561 lies between different addresses where in-addr's resolve to qwest.net. Probably not all that useful of an exercise though... John On Mon, Jan 22, 2001 at 03:05:20AM -0500, Joe Budion wrote: > > This one takes the cake for weirdest route I've ever seen: > > #3 sl-gw5-kc-5-0-0.sprintlink.net (144.232.132.45): TTL Exceeded, ttl=253, > 41 ms > #4 sl-bb20-kc-0-0.sprintlink.net (144.232.23.1): TTL Exceeded, ttl=252, 40 > ms > #5 sl-bb20-fw-13-0.sprintlink.net (144.232.9.254): TTL Exceeded, ttl=251, 50 > ms > #6 Unavailable (144.232.18.162): TTL Exceeded, ttl=250, 50 ms > #7 dal-core-02.inet.qwest.net (205.171.25.49): TTL Exceeded, ttl=249, 50 ms > #8 hou-core-01.inet.qwest.net (205.171.5.169): TTL Exceeded, ttl=248, 50 ms > #9 hou-edge-07.inet.qwest.net (205.171.23.14): TTL Exceeded, ttl=247, 50 ms > #10 a6-0-6.crtntx1-ba2.bbnplanet.net (4.24.147.21): TTL Exceeded, ttl=241, > 80 ms > #11 p10-0.crtntx1-br2.bbnplanet.net (4.24.10.189): TTL Exceeded, ttl=242, 81 > ms > #12 p2-0.crtntx1-cr8.bbnplanet.net (4.24.8.198): TTL Exceeded, ttl=241, 80 > ms > #13 p5-0.toucham.bbnplanet.net (4.24.117.66): TTL Exceeded, ttl=240, 100 ms > #14 den-edge-18.inet.qwest.net (205.171.16.34): TTL Exceeded, ttl=239, 101 > ms > #15 Unavailable (63.145.64.62): TTL Exceeded, ttl=238, 150 ms > #16 SLCNTWEB01 (63.237.115.200): Echo Reply, ttl=110, 150 ms > > Statistics: Out 14, in 14, loss 0%, times (min/avg/max) 40/76/150 ms > > joe > -- John Osmon "bash awk grep perl sed df du, du-du du-du, john(a)osmon.net vi troff su fsck rm * halt LART LART LART!" -- the Swedish BOFH

1 0