Re: transit across the ixs
you might be amused to write a bit of code to see if your ix peers are giving you next-hops of other provider(s). it is clear that a number of providers are selling transit across the ixs. not at all cool.
Note that CIX does this by default at PAIX and on PB-SMDS. Not that those are major exchanges by Randy's likely definition. The only time we force next-hop-self is if the peer deliberately asks the exchange operator for port filtering, or if we're otherwise explicitly requested by a BGP peer send routes with next-hop-self. -- Paul Vixie <paul@vix.com>
you might be amused to write a bit of code to see if your ix peers are giving you next-hops of other provider(s). it is clear that a number of providers are selling transit across the ixs. not at all cool. Note that CIX does this by default at PAIX and on PB-SMDS. Not that those are major exchanges by Randy's likely definition. The only time we force next-hop-self is if the peer deliberately asks the exchange operator for port filtering, or if we're otherwise explicitly requested by a BGP peer send routes with next-hop-self.
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. randy
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
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.
no, but it is non-trivial added burden for the noc. we don't do that. does not scale.
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.
i.e. our noc has to contact the third party noc. half the folk on mae-x seem not to even have nocs. does not scale.
How do you debug problems with a multihomed customer on the end of a serial link when you can't see their config?
they have a vested interest in debugging their problem and are going to be available when the problem site is in trouble because they are the site with the problem.
In another thought, what if the "offender" is not a transit customer, but the same provider.
that's why we listen to meds at exchanges.
Is this bad? You agreed to peer with them. Does your peering agreement restrict them to one router as the source?
yup. randy
On Wed, Feb 17, 1999 at 06:51:20AM -0800, Randy Bush wrote:
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.
no, but it is non-trivial added burden for the noc. we don't do that. does not scale.
I would agree. Folks doing this are being very silly with their configuration, the added load to their direct port should be expected, as they are providing transit, the fact that they can cheat a bit and not have their router take the switching load is just a nice thing.
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.
i.e. our noc has to contact the third party noc. half the folk on mae-x seem not to even have nocs. does not scale.
These people either should unplug, or not be peered with, it's unfortunate that the small folks like this are ruining it for themselves because they don't have a real NOC.
Is this bad? You agreed to peer with them. Does your peering agreement restrict them to one router as the source?
yup.
route-map my-exchange-point-peers-in permit 10 set ip next-hop peer-address - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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. --randy
It sounds like Verio (a) didn't know about CIX's next-hop policy at PAIX and (b) is about to ask for it to be changed. Any CIX member who wants to see the CIX router as the next-hop for all PAIX-reachable routes should just ask for that behaviour. After all it's not like the GIGAswitch has buffering limitations or HOL blocking or anything bad like that. The CIX router at PAIX has been called "like a route server" and except for the "1280" that gets put into transit paths, that's just about true. (There is just enough SMDS and private connection traffic to make it false, though.)
participants (5)
-
Jared Mauch -
Leo Bicknell -
Paul A Vixie -
Paul Vixie
-
Randy Bush