redistribute bgp considered harmful
Should the Service Provider version of routing software include the redistribute bgp command? Other than CCIE labs, I haven't seen a real-world use for redistributing the BGP route table into any IGP. If the command was removed (or included a Are your sure? question) what would the affect be on ISPs, other than improving reliability by stopping network engineers from fubaring a backbone?
Date: Fri, 4 Oct 2002 18:01:15 -0400 (EDT) From: Sean Donelan <sean@donelan.com> Sender: owner-nanog@merit.edu
Should the Service Provider version of routing software include the redistribute bgp command? Other than CCIE labs, I haven't seen a real-world use for redistributing the BGP route table into any IGP.
If the command was removed (or included a Are your sure? question) what would the affect be on ISPs, other than improving reliability by stopping network engineers from fubaring a backbone?
Is it possible that anyone running an ISP or NSP would be dumb enough to ever do this? (rhetorical question, I know the real answer.) While I would not like to see it removed (some where, some time, someone will have a reason to want this), I suppose an "Are you sure?" would not hurt, there are a great many commands that can prove similarly disastrous. I'm not sure why this one needs it for than others. On the whole, I really don't care for this sort of hand-holding for people who claim to be engineers. It's annoying and I doubt it buys much. The "engineer" who did this in error probably THINKS he wants to do it and would simply reply "yes". R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
On Fri, 4 Oct 2002, Sean Donelan wrote:
Should the Service Provider version of routing software include the redistribute bgp command? Other than CCIE labs, I haven't seen a real-world use for redistributing the BGP route table into any IGP.
I don't think it's the business of anyone outside an AS whether this AS redistributes BGP into an IGP. This can sometimes be useful. I'd be much happier to see redistributing IGPs into BGP being removed. But I guess the people that use this for legitimate reasons won't like this so much. But not allowing BGP -> IGP -> BGP might be a good one. On the other hand, someone who is determined to screw up could do BGP -> IGP on one router and IGP -> BGP on another.
If the command was removed (or included a Are your sure? question) what would the affect be on ISPs, other than improving reliability by stopping network engineers from fubaring a backbone?
One customer I have would need to invest to upgrade their layer 3 switch to support BGP in addition to OSPF.
Iljitsch van Beijnum <iljitsch@muada.com> wrote:
But not allowing BGP -> IGP -> BGP might be a good one. On the other hand, someone who is determined to screw up could do BGP -> IGP on one router and IGP -> BGP on another.
I've seen that done. And usefully. The case involved an AGS+ (BGP speaking) and IGS (with too little memory to run anything later than IOS 8.3, but after the PALs required to do memory upgrades on IGSs had been discontinued by Cisco) and a peering across a serial link, but could just as easily happen with today's routers -- eg, two small ISPs peering over a Cisco 827. Any feature can be useful, but you just have to be very careful and very aware of what you're doing and why it is evil. If you can carefully select the routes via, say, nexthop, filter them correctly and know what ASN to insert them into, then you can use an IGP to transport routes between two ASNs (or more, if you match various nexthops and use them to insert into different ASNs). Imagine ISP A and ISP B are BGP-speakers with only a small amount of peering traffic, and an asymmetric flow (say ISP B is a small, modem customer only ISP, and ISP A have a bit of content and a slightly larger customer base). Now say ISP A and ISP B peer for some reason, and ISP A uses BGP as their only interstate routing protocol, so they need the routes to appear in their BGP table. ISP B could be using a Cisco 827 (RIPv2 only) to connect to ISP A's ADSL product via L2TP. ISP A could be putting ISP B into a VRF and then forwarding them off to a small router (eg, an old 1000-series, with an IOS before BGP was removed from them[1]), which they peer via BGP back to their regular network (having configured it in ISP B's ASN), and insert the routes (after filtering) from RIPv2 into BGP. And before you say no ISP would be crazy enough to peer with a 1003 and 827 in the peering path, I refer you to http://peer.sensation.net.au/ (a NAP using 33k and 56k modems, or 'NAPette' as the organizer calls it). Of course, this is probably a good argument -not- to support IGP into BGP distribution, because someone might use it for something like the above! :-) David. [1] example router thrown in because it lines up so well with the dodgyness of the example usage :-) besides, 1003s look cool [substitute any other 1000-series.
On Mon, 7 Oct 2002, David Luyer wrote:
But not allowing BGP -> IGP -> BGP might be a good one. On the other hand, someone who is determined to screw up could do BGP -> IGP on one router and IGP -> BGP on another.
I've seen that done. And usefully.
But it's just too dangerous.
Any feature can be useful, but you just have to be very careful and very aware of what you're doing and why it is evil. If you can carefully select the routes via, say, nexthop, filter them correctly and know what ASN to insert them into, then you can use an IGP to transport routes between two ASNs (or more, if you match various nexthops and use them to insert into different ASNs).
The trouble is that it is way too easy to screw it up. Even if you think you are doing everything right, unexpected results can ensue. For instance, not so long ago I discovered that our favorite router vendor starting with a C doesn't offer any way to change filters without leaking routes. Old config: router bgp 123 neighbor 4.5.6.7 prefix-list a out And then I typed: router bgp 123 neighbor 4.5.6.7 prefix-list b out Doing this triggered upstream max prefixes two out of three times, so routes that weren't allowed by either the old _or_ the new filter managed to slip through.
Imagine ISP A and ISP B are BGP-speakers with only a small amount of peering traffic, and an asymmetric flow (say ISP B is a small, modem customer only ISP, and ISP A have a bit of content and a slightly larger customer base).
Now say ISP A and ISP B peer for some reason, and ISP A uses BGP as their only interstate routing protocol, so they need the routes to appear in their BGP table.
Ok, but what about the BGP -> IGP redistribution? This part doesn't seem necessary here. In this case ISP A seems to use BGP for interior purposes (as many networks do these days) so it seems unlikely they also redistribute BGP into the IGP, which was mainly done long ago.
ISP B could be using a Cisco 827 (RIPv2 only) to connect to ISP A's ADSL product via L2TP.
ISP A could be putting ISP B into a VRF and then forwarding them off to a small router (eg, an old 1000-series, with an IOS before BGP was removed from them[1]), which they peer via BGP back to their regular network (having configured it in ISP B's ASN), and insert the routes (after filtering) from RIPv2 into BGP.
Wouldn't configuring a tunnel between BGP-capable routers in each AS be much simpler?
Of course, this is probably a good argument -not- to support IGP into BGP distribution, because someone might use it for something like the above! :-)
I rest my case. (-: Iljitsch
I tend to favour allowing features rather than restricting them, if paranoia is needed then perhaps a confirm prompt? Dont forget tho BGP is used for things other than Internet routing eg VPN, VRF and in those cases I can imagine such redistributions being beneficial. Steve On Mon, 7 Oct 2002, David Luyer wrote:
Iljitsch van Beijnum <iljitsch@muada.com> wrote:
But not allowing BGP -> IGP -> BGP might be a good one. On the other hand, someone who is determined to screw up could do BGP -> IGP on one router and IGP -> BGP on another.
I've seen that done. And usefully. The case involved an AGS+ (BGP speaking) and IGS (with too little memory to run anything later than IOS 8.3, but after the PALs required to do memory upgrades on IGSs had been discontinued by Cisco) and a peering across a serial link, but could just as easily happen with today's routers -- eg, two small ISPs peering over a Cisco 827.
Any feature can be useful, but you just have to be very careful and very aware of what you're doing and why it is evil. If you can carefully select the routes via, say, nexthop, filter them correctly and know what ASN to insert them into, then you can use an IGP to transport routes between two ASNs (or more, if you match various nexthops and use them to insert into different ASNs).
Imagine ISP A and ISP B are BGP-speakers with only a small amount of peering traffic, and an asymmetric flow (say ISP B is a small, modem customer only ISP, and ISP A have a bit of content and a slightly larger customer base).
Now say ISP A and ISP B peer for some reason, and ISP A uses BGP as their only interstate routing protocol, so they need the routes to appear in their BGP table.
ISP B could be using a Cisco 827 (RIPv2 only) to connect to ISP A's ADSL product via L2TP.
ISP A could be putting ISP B into a VRF and then forwarding them off to a small router (eg, an old 1000-series, with an IOS before BGP was removed from them[1]), which they peer via BGP back to their regular network (having configured it in ISP B's ASN), and insert the routes (after filtering) from RIPv2 into BGP.
And before you say no ISP would be crazy enough to peer with a 1003 and 827 in the peering path, I refer you to http://peer.sensation.net.au/ (a NAP using 33k and 56k modems, or 'NAPette' as the organizer calls it).
Of course, this is probably a good argument -not- to support IGP into BGP distribution, because someone might use it for something like the above! :-)
David.
[1] example router thrown in because it lines up so well with the dodgyness of the example usage :-) besides, 1003s look cool [substitute any other 1000-series.
SD> Date: Fri, 4 Oct 2002 18:01:15 -0400 (EDT) SD> From: Sean Donelan SD> Should the Service Provider version of routing software SD> include the redistribute bgp command? Other than CCIE labs, SD> I haven't seen a real-world use for redistributing the BGP SD> route table into any IGP. ! allow-dangerous bgp-into-igp allow-dangerous igp-into-bgp ! Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
Sean, See Inline... ----- Original Message ----- From: "Sean Donelan" <sean@donelan.com> To: <nanog@merit.edu> Sent: Friday, October 04, 2002 6:01 PM Subject: redistribute bgp considered harmful
Should the Service Provider version of routing software include the redistribute bgp command? Other than CCIE labs, I haven't seen a real-world use for redistributing the BGP route table into any IGP.
Certainly a case can be made for the use of the redistribute bgp command when it comes to route-reflection and confederations. I know of a couple enterprises that make use of the command in order to maintain consistent route information throughout their core(which happens to run eigrp). As well, depending on the size of the enterprise this could prove to be a valuable asset.
If the command was removed (or included a Are your sure? question) what would the affect be on ISPs, other than improving reliability by stopping network engineers from fubaring a backbone?
I think the command itself provides the same funcionalty as cisco "backdoor" command in that it allows for the mistakes made by man, since computer(routers) don't make mistakes..:-) This really come down to the orginal design of the network and if the "requirements" were completely identified before implementation, unlike the real world scanerio which is normally the opposite. Nigel
On Friday, Oct 4, 2002, at 18:01 Canada/Eastern, Sean Donelan wrote:
Should the Service Provider version of routing software include the redistribute bgp command? Other than CCIE labs, I haven't seen a real-world use for redistributing the BGP route table into any IGP.
If the command was removed (or included a Are your sure? question) what would the affect be on ISPs, other than improving reliability by stopping network engineers from fubaring a backbone?
Participants at the NZIX, the original exchange point in New Zealand hosted by the University of Waikato, used to exchange routes using OSPF. And BGP and RIP and IGRP. Those were the days. In order to export our routes to other exchange participants, we redistributed BGP routes into a dedicated exchange OSPF process, and we had some careful redistribution going on in the other direction to harvest the NZIX routes into BGP for use within our AS. The NZIX has been shut down for quite a while now, so this is not a reason for retaining the ability to commit such heinous crimes against nature. However, I do remember that a "redistribute bgp" under "router ospf" did precisely nothing on the IOS loads we were using at the time, unless there was also a "bgp redistribute-internal" command in the config. So if this works the way I remember it working, it seems like there might already be an "are you sure" mechanism in place, in IOS at least. There are some words about this on CCO: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/ 121cgcr/ip_r/iprprt2/1rdbgp.htm#xtocid17
bgp redistribute-internal
To allow the redistribution of iBGP routes into an interior gateway protocol such as IS-IS or OSPF, use the bgp redistribute-internal command in router configuration mode. To remove the bgp redistribute-internal command from the configuration file and restore the system to its default condition where the software does not allow the redistribution of iBGP routes into Interior Gateway Protocols (IGPs), use the no form of this command.
Joe
participants (8)
-
David Luyer -
E.B. Dreger -
Iljitsch van Beijnum -
Joe Abley -
Kevin Oberman -
Nigel Taylor -
Sean Donelan -
Stephen J. Wilcox