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?
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.
Date: Fri, 4 Oct 2002 18:01:15 -0400 (EDT)
From: Sean Donelan
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.
!
allow-dangerous bgp-into-igp
allow-dangerous igp-into-bgp
!
Eddy
Sean,
See Inline...
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:
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
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.
> 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
