[ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure
Jason Schiller (schiller@uu.net)
jason.schiller at mci.com
Thu Apr 13 11:27:20 EDT 2006
Scott,
The important question is not if this is actually available in IOS, but
rather if it is actually available in a version of IOS that service
providers are actually willing to run...
As for constraining the routes that are used for next-hop resolution, I
would suggest that this be as flexible as any other route-map, ACL, or
policy.
Lastly, *all* router vendors need to support this functionality in order
to have a consistant forwarding behavor.
Cisco calls this "BGP Selective Next-Hop Route Filtering".
http://www.cisco.com/en/US/products/ps6441/products_configuration_guide_chapter09186a00805387d7.html#wp1113697
Configuring BGP Selective Next-Hop Route Filtering: Examples
"The following example shows how to configure BGP selective next-hop route
filtering to avoid using a BGP prefix as the next-hop route. If the most
specific route that covers the next hop is a BGP route, then the BGP route
will be marked as unreachable. The next hop must be an IGP or static
route.
router bgp 45000
address-family ipv4 unicast
bgp nexthop route-map CHECK-BGP
exit
exit
route-map CHECK-BGP deny 10
match source-protocol bgp 1
exit
route-map CHECK-BGP permit 20
end
"
This functionality is available ONLY in 12.4T or IOS XR. I have asked for
this functionality in 12.0S, and to ensure this functionality is supported
in IPv6 as well. I was told it would be highly unlikely to be back ported
to 12.0S. Since this is currently a show stopped for me I never followed
up if the command works for IPv6 or not.
Juniper calls this "resolution ribs"
http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-routin
g/frameset.htm
http://www.juniper.net/techpubs/software/junos/junos75/swconfig75-routing/html/routing-generic-config18.html#1032268
"You can configure a routing table to accept routes from specific routing
tables. You can also configure a routing table to use specific import
policies to produce a route resolution table to resolve routes."
To configure route resolution, include the resolution statement:
resolution {
rib routing-table-name {
import [ policy-names ];
resolution-ribs [ routing-table-names ];
}
}
"
However, until all routing vendors support this functionality it has
limited usefulness. Take the case of an all Juniper Core and an all Cisco
edge. Destination is reachable through best path to edge-router-1 and
non-best path to edge-router-2. Source is connected to
edge-router-3.
Depending on the topology and the BGP tie breaker, edge-router-2 may or
may not announce the non-best path to the core. If the tie breaker is MED
for example, then edge-router-2 will no announce a path to the core as the
iBGP route from edge-router-1 will be better and will supress the
annnouncement. If the tie breaker is say IGP distance, or router ID, then
edge-router-2 will announce a path into the core.
In the case where edge-router-2 does not announce a path you have black
holing for up to 3 mins. (BGP hold time) untill the iBGP neighbor times
out. During this time traffic is black holed.
In the case where edge-router-2 does announce a path to the core, then the
core will have the best and the non-best path to the destination. The
edge routers will only have the pull-up or less specific route with a
next-hop of the nearest core router. This will cause edge-router-3 to
send traffic towards the core. The core will have the new best path
and will forward to edge-router-2. Edge-router-2 will still have the old
best route with a next-hop of edge-router-1's loopback. Edge-router-1 is
reachable through the pull-up (aggregate) route, and traffic will be
forwarded to the core. Thus traffic will loop for up to 3 mins (BGP hold
time).
I was attempting to persue an ARIN policy as wide spread vendor adoption
in a code that is useful seems unlikely to have a timely
solution. Without this policy, many of my customers who demand fast
fail-over for their time sensitive applications (such as VoIP) will
continue to believe that IPv6 is just not ready for "prime-time" and will
not use IPv6 for production services.
Furthermore, 2006-2 was also attempting to address other security concerns
that can be resolved by having a second non-contigous aggregate. Router
configuration to limit BGP next-hop resolution does not address the
security concerns.
So the question I have is if it is really worth persuing all of these
vendors to get this functionality in a useful code, if the the policy is
still going to move forward on only the security needs?
I guess my second question is if people are in favor of this policy to
solve only the security needs?
___Jason
==========================================================================
Jason Schiller (703)886.6648
Senior Internet Network Engineer fax:(703)886.0512
Public IP Global Network Engineering schiller at uu.net
UUNET / Verizon jason.schiller at verizonbusiness.com
The good news about having an email address that is twice as long is that
it increases traffic on the Internet.
On Thu, 13 Apr 2006, Scott Leibrand wrote:
> Date: Thu, 13 Apr 2006 07:55:00 -0400 (EDT)
> From: Scott Leibrand <sleibrand at internap.com>
> To: "Harold Ritter (hritter)" <hritter at cisco.com>
> Cc: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal 2006-2: Micro-allocations for
> Internal Infrastructure
>
> On 04/12/06 at 10:56pm -0400, Harold Ritter (hritter) <hritter at cisco.com> wrote:
>
> > Modify BGP implementations so they only consider host routes (/128) as
> > valid routes to resolve the BGP next-hop. This way, if a router goes
> > down and its loopback interface address disappears from the IGP, its BGP
> > neighbors will immediately be able to react by invalidating all BGP
> > prefixes having this address as their BGP next-hop, which leads to a new
> > BGP best path being selected. This should also be configurable to accept
> > a less specific prefix to cope with cases where /128 prefixes are not
> > injected in the IGP under normal conditions.
>
> Sounds like a workable solution to me... But...
>
> > This solution as been applied and tested with ipv4 and is also
> > applicable to ipv6.
>
> Is this actually available in IOS (for either IPv4 or IPv6)? If not, how
> long would it take to get it tested and made available?
>
> -Scott
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>
More information about the ARIN-PPML
mailing list