Re: Location of upstream connections & BGP templates
--- steve@ibctech.ca wrote: From: Steve Bertrand <steve@ibctech.ca> layered. My thinking is that my 'upstream' connections should be moved out of the core, and onto the edge. My reasoning for this is so that I What do other providers do? Are your transit peers connected directly to the core? I can understand such a setup for transit-only providers, but -------------------------------------------- Border, core, access. Border routers only connect the core to the upstreams. They do nothing else. No acls, just prefix filters. For example, block 1918 space from leaving your network. Block other bad stuff from leaving your network too. Allow in only what you're expecting from the upstream; again 1918 space, etc. They can fat finger like anyone else. Core is for moving bits as efficiently as possible: no acls; no filters. Connect downstream BGP customers to access routers that participate in the iBGP mesh. Filter them only allowing what they're supposed to advertise. They'll mess it up a lot if they're like my customers by announcing everything under the sun. Filter what you're announcing to them. You can fat finger just as well as anyone else. ;-) scott
Border/Core/Access is great thinking when your a sales rep for a vendor that sells under power kit. No reason for it any more. -jim On Wed, Feb 17, 2010 at 8:38 PM, Scott Weeks <surfer@mauigateway.com> wrote:
--- steve@ibctech.ca wrote: From: Steve Bertrand <steve@ibctech.ca>
layered. My thinking is that my 'upstream' connections should be moved out of the core, and onto the edge. My reasoning for this is so that I
What do other providers do? Are your transit peers connected directly to the core? I can understand such a setup for transit-only providers, but --------------------------------------------
Border, core, access.
Border routers only connect the core to the upstreams. They do nothing else. No acls, just prefix filters. For example, block 1918 space from leaving your network. Block other bad stuff from leaving your network too. Allow in only what you're expecting from the upstream; again 1918 space, etc. They can fat finger like anyone else.
Core is for moving bits as efficiently as possible: no acls; no filters.
Connect downstream BGP customers to access routers that participate in the iBGP mesh. Filter them only allowing what they're supposed to advertise. They'll mess it up a lot if they're like my customers by announcing everything under the sun. Filter what you're announcing to them. You can fat finger just as well as anyone else. ;-)
scott
On 2010.02.17 19:41, jim deleskie wrote:
Border/Core/Access is great thinking when your a sales rep for a vendor that sells under power kit. No reason for it any more.
Hi Jim, Unfortunately, I have a mix of EOL Cisco gear in my network, along with other random custom-built software routers, HP Procurve switches etc. To be honest, I am very pleased with what I've learnt over the course of the last two years with my network re-design/build. In my environment, the layered approach is working exceptionally well (and my sales skills would have me recommend a different ISP at the drop of a dime if they could provide what I couldn't ;) Primarily, my transition has led me down the BCP 38 path (and it's associated techniques/side-effects, specifically automated S/RTBH), which aside from IPv6, is the most important thing I believe that I could have accomplished during that time. It would, however, be interesting to learn how the former drawbacks of flat networks have evolved, and what new technologies make them successful once again. Thanks, Steve
Of course all designs are limited to the budget you have to build the network :) On Wed, Feb 17, 2010 at 9:20 PM, Steve Bertrand <steve@ibctech.ca> wrote:
On 2010.02.17 19:41, jim deleskie wrote:
Border/Core/Access is great thinking when your a sales rep for a vendor that sells under power kit. No reason for it any more.
Hi Jim,
Unfortunately, I have a mix of EOL Cisco gear in my network, along with other random custom-built software routers, HP Procurve switches etc.
To be honest, I am very pleased with what I've learnt over the course of the last two years with my network re-design/build. In my environment, the layered approach is working exceptionally well (and my sales skills would have me recommend a different ISP at the drop of a dime if they could provide what I couldn't ;)
Primarily, my transition has led me down the BCP 38 path (and it's associated techniques/side-effects, specifically automated S/RTBH), which aside from IPv6, is the most important thing I believe that I could have accomplished during that time.
It would, however, be interesting to learn how the former drawbacks of flat networks have evolved, and what new technologies make them successful once again.
Thanks,
Steve
On 2010.02.17 20:45, jim deleskie wrote:
Of course all designs are limited to the budget you have to build the network :)
Heh, yeah, but it's unbelievable what one can learn on an eBay diet when they put their entire heart, soul and dedication into it! Steve
Absolutely. I've worked on networks where I'm was amazed on someday we held it all together, but that is truly when you learn the most. -jim On Wed, Feb 17, 2010 at 9:46 PM, Steve Bertrand <steve@ibctech.ca> wrote:
On 2010.02.17 20:45, jim deleskie wrote:
Of course all designs are limited to the budget you have to build the network :)
Heh, yeah, but it's unbelievable what one can learn on an eBay diet when they put their entire heart, soul and dedication into it!
Steve
On 2010.02.17 20:48, jim deleskie wrote:
Absolutely. I've worked on networks where I'm was amazed on someday we held it all together, but that is truly when you learn the most.
I'm very, very happy that there are people out there who can actually see that... Steve
Ditto Sent from my iPhone On Feb 17, 2010, at 7:38 PM, "Scott Weeks" <surfer@mauigateway.com> wrote:
--- steve@ibctech.ca wrote: From: Steve Bertrand <steve@ibctech.ca>
layered. My thinking is that my 'upstream' connections should be moved out of the core, and onto the edge. My reasoning for this is so that I
What do other providers do? Are your transit peers connected directly to the core? I can understand such a setup for transit-only providers, but --------------------------------------------
Border, core, access.
Border routers only connect the core to the upstreams. They do nothing else. No acls, just prefix filters. For example, block 1918 space from leaving your network. Block other bad stuff from leaving your network too. Allow in only what you're expecting from the upstream; again 1918 space, etc. They can fat finger like anyone else.
Core is for moving bits as efficiently as possible: no acls; no filters.
Connect downstream BGP customers to access routers that participate in the iBGP mesh. Filter them only allowing what they're supposed to advertise. They'll mess it up a lot if they're like my customers by announcing everything under the sun. Filter what you're announcing to them. You can fat finger just as well as anyone else. ;-)
scott
On 2010.02.17 19:38, Scott Weeks wrote:
--- steve@ibctech.ca wrote:
layered. My thinking is that my 'upstream' connections should be moved out of the core, and onto the edge. My reasoning for this is so that I
What do other providers do? Are your transit peers connected directly to the core? I can understand such a setup for transit-only providers, but --------------------------------------------
Border, core, access.
Border routers only connect the core to the upstreams. They do nothing else. No acls, just prefix filters. For example, block 1918 space from leaving your network. Block other bad stuff from leaving your network too. Allow in only what you're expecting from the upstream; again 1918 space, etc. They can fat finger like anyone else.
This was my thought. However... no fat-finger accidents using Team Cymru in conjunction with my internal RTBH triggers with uRPF enabled on every single 'edge' interface ;) This was the basis of my original question. I want to keep this setup at edge-only, and don't want to have to apply it within the core gear.
Core is for moving bits as efficiently as possible: no acls; no filters.
...which is what I visualize, and essentially want.
Connect downstream BGP customers to access routers that participate in the iBGP mesh. Filter them only allowing what they're supposed to advertise. They'll mess it up a lot if they're like my customers by announcing everything under the sun. Filter what you're announcing to them. You can fat finger just as well as anyone else. ;-)
I guess I see 'border' and 'access' as the same. Fat-fingering is important to me. My pref-list is created long before I turn up a BGP session to a client, and the peering is tested internally before I allow them to advertise anything (or I advertise anything to them). At this point, I only have one _true_ peer that advertises their space directly to me, and it is tied down to the last bit. I even informed them that I will perform max path, so they will drop if they break it. Not scalable for multiple clients, but I've learnt a lot. I need to learn now how to scale, which is why the second half of my question dealt with templates. One template, less chance for me to fat-finger :) Cheers, STeve
participants (4)
-
James Jones -
jim deleskie -
Scott Weeks -
Steve Bertrand