[23074] in North American Network Operators' Group
Re: transit across the ixs
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Feb 17 09:46:25 1999
From: Leo Bicknell <bicknell@ufp.org>
In-Reply-To: <m10D7Es-0008G5C@rip.psg.com> from Randy Bush at "Feb 17, 99 05:42:06 am"
To: randy@psg.com (Randy Bush)
Date: Wed, 17 Feb 1999 09:33:02 -0500 (EST)
Cc: paul@vix.com, nanog@merit.edu
In a previous e-mail, Randy Bush said:
> cool beans. employment security for level-3s at the noc. makes it really
> fun to debug when packets come from places different where routes go. good
> job.
Aw, come on Randy. It's not like it's rocket science. The routes
do go there, after all. A "show ip bgp w.x.y.z" on the TC router will
show your router as the next hop. The routes go right there, it's just
you're not on that end of the world. How do you debug problems with
a multihomed customer on the end of a serial link when you can't see their
config?
In another thought, what if the "offender" is not a transit customer,
but the same provider. That is:
+----------+
| +----Router 1
| Switch |
You-----+ +----Router 2
+----------+
Now, Router 1 and Router 2 are the same AS, and in fact the same
provider. You only peer with router 1, but they dump the routes to router 2,
and don't set "next hop self".
Is this bad? You agreed to peer with them. Does your peering agreement
restrict them to one router as the source?
--
Leo Bicknell - bicknell@ufp.org
Systems Engineer - Internetworking Engineer - CCIE 3440
Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
