|
(Seulement disponible en anglais.)
Announcment of BGP Routes to the Customer
There are two options for the announcment of BGP routes from the IP-Plus network to the
customer:
- Full Global Routes
- Swiss (Local) Routes only
A direct BGP session is set up between the customer and the IP-Plus backbone, using the IP
addresses on each end of the serial (leased-line) connection as BGP neighbor addresses. In all
cases, this BGP session is used to (a) send the IP-Plus Swiss Routes to the customer and (b)
import the customer's routes into the IP-Plus BGP system.
Through the BGP routes learned over the direct BGP session, IP connectivity is established
between all of the IP-Plus network and the customer's network. Normally, if the customer has
chosen Global Connectivity, the IP-Plus then re-announces his routes into the global routing
system.
It is possible for the customer to 'fine-tune' the re-announcment of his routes into the
global routing system using a system of BGP community tags. This is may be necessary if the
customer is globally routed over two or more different ISPs. This requires a high level of
knowledge about the global Internet routing system. This is described in more detail later in
this document.
Full Global Routes is required for customer who want to optimise his routing over a larger part
of the Internet: the larger the domain over which the customer wants to specify a routing policy,
the larger the proportion of the full Internet routing table required. If he wants to optimise
his routing throughout the entire Internet, then the entire Internet routing table is required
from at least on ISP. The table is currently around 100,000 entries, and requires a high-end
router with at least 128 MByte of dynamic RAM.
IP-Plus BGP Architecture
Essentially, the IP-Plus BGP routing organises routes into groups called 'communities'. A
BGP route is put into a particular community by 'tagging' it when it is received in a BGP
announcment from a customer, a peer, or an upstream ISP. Membership of particular community
determines how the route will be re-announced to other networks. For example, routes imported
from Swiss peers are put into the 'peers' community. Routes in this community are never
re-exported to peers. This means that IP-Plus can never be used as a transit network between
different IP-Plus peers.
The most important IP-Plus communities are reperesented by Macros in the RIPE database. In
other words, if a particular AS is connected to IP-Plus, it is possible to see from the RIPE
database which IP-Plus community the routes from that AS are put into, and so what sort of
connectivity the AS has through IP-Plus.
The most important IP-Plus communities are:
- Peer - RIPE Macro
AS-SWCMPEERS
- Customers with Global Connectivity (additional to Swiss Connectivity) - RIPE Macro
AS-SWCMGLOBAL
The basic IP-PLus routing policy can be seen from the
AS3303 RIPE
entry. Essentially, peers (AS-SWCMPEERS) get connectivity only to customers (AS-SWCMGLOBAL). All
customers (AS-SWCMGLOBAL) get connectivity to peers and all other customers.
Route Filtering
IP-Plus uses 'dense' route filtering on all customer BGP connections. This means that routes
announced by the customer are filtered according to AS-Path and IP address (Prefix). For example,
IP-Plus will accept routes originated (according to BGP AS-path attribute) by the customer's
Autonomous System (AS). But if the customer is connected to another AS (for example, the customer
is running BGP to one of his own customers), and wants IP-Plus to accept these routes, then it
is necessary for the route filters on the IP-Plus customer port to be changed so that they accept
the other AS.
At the same time, even if a route has an AS-path attribute that matches the AS-Path filter, it
will only be accepted into the IP-Plus BGP system if it also matches a list of IP address
ranges ('Prefixes') which 'officially' belong to the customer's AS. IP-Plus accepts a route as
officially belonging to a customer's AS if there is a Route Object in the global Internet Routing
Registry (IRR) specifying that it does so. In Europe this will usually mean that there is a Route
Object in the RIPE database.
IP-Plus Operations constructs AS-Path and Prefix Filters based on the RIPE database - not on
information supplied by the customer. It is therefore essential for customers to maintain the
information in the RIPE database if they want IP-Plus to route their traffic in the way they
want it to be routed.
Currently, the creation of AS-Path and Prefix Filters from the RIPE database is done manually.
It is done first when the customer is connected to IP-Plus, and then updated only when the
customer notifies IP-Plus Operations that he is announcing new routes and requires the filters to
be changed. In other words, it is up to the customer to update the RIPE information, and then
notify IP-Plus Operations that the filters must be changed. This notification must be done using
the Change request.
IP-Plus does not accept any BGP route announcments from any source for:
- Address ranges less than /24 (single C-class)
- RFC1918 Private address space
BGP Communities
The IP-Plus backbone is itself multihomed to various Global, European and Swiss ISPs. Multihomed
customers can reach these networks through IP-Plus, and through their other BGP connections. For
example, IP-Plus is connected to both EBONE and AUCS for pan-European Connectivity. It may be
that a multihomed customer prefers to reach EBONE via another ISP, but want to reach AUCS through
IP-Plus.
It is not possible for IP-Plus to set up customer-specific routing. Using the example above,
it would not be possible for IP-PLus manually configure customer-specific routing policies in the
core routers in order to satisfy the customers wish to reach EBONE via another ISP and AUCS via
IP-Plus. If this possibility were made available to all customers then the resulting routing
policy would rapidly become totally unmanageable.
To overcome this problem, IP-Plus allows customers to control the way their own routes are
re-announced to other ISPs by setting specific BGP community strings when the routes are
announced to IP-Plus. Using our example, to prevent IP-Plus announcing the routes to EBONE, the
customer simply tags his BGP routes with the community '3303:2104'. This causes IP-PLus to
automatically block announcments of the route to EBONE. (A better policy would be to use the
community '3303:2004', which has the effect of prepending the string '3303 3303 3303' onto the
AS-path of announcments to EBONE. This means that the IP-PLus EBONE connection is a backup path
if the customer's preferred route to EBONE should fail).
The BGP communities that can be set by customers are published in the
RIPE Database entry for AS3303.
This concept can be taken one stage further: many of the upstream providers of IP-Plus also
allow thier route announcments to be controlled via communities. For example, both EBONE and
AUCS permit this. So, in theory, a customer could set community strings that control the routing
of their traffic to networks which are connected to EBONE and AUCS.
Note: Use of the BGP communities only signals the way a customer prefers to have his traffic
routed. Swisscom reserves the right to override communities set by the customer if it is
necessary to maintain the service levels to the bulk of IP-PLus customers. For example, if a
large customer suddenly and without warning used communities to steer a lot of traffic from
one IP-Plus link to another, and by doing so caused congestion, then IP-Plus Operations might
find it necessary to block the community string on routes imported from the customer.
Flap Dampening
BGP route flap dampening is employed within the IP-PLus network. Cisco default parameters are
used. Essentially this means that more than 2 BGP route withdrawals of a prefix within a timespan
of 1/2 hour can result in that prefix being removed from the IP-Plus routing tables for around
2 hours.
IP Addressing Issues
- If a multihomed customer requires PA addresses from Swisscom, the normal
address assignment rules apply.
- If a multihomed customer has IP-Plus PA addresses, and announces these to the
IP-Plus backbone via BGP, then IP-Plus will re-announce these specific routes on all it's BGP
session to other ISPs and customers, in parallel with the normal route to the entire PA block of
which the customer has a part.
- If a multihomed customer has IP-Plus PA addresses, and announces them via BGP
to another ISP, then IP-Plus will accept these specific routes if the other ISP then re-announces
them to IP-Plus.
- If a multihomed customer has PA addresses from another ISP, IP-Plus will
announce the specific routes on all it's BGP sessions to other ISPs and customers, but the
customer must understand that the global routing of his addresses is not dependent on Swisscom
alone - connectivity to regions of the Internet behind prefix-length filters may depend on the
other ISP. Therefore Swisscom alone cannot guarentee global connectivy.
- If a multihomed customer has PA addresses and then cancels the connection to
the ISP that assigned the PA addresses, then he must renumber to PA addresses from one of the
remaining ISPs that is providing him with Internet access.
- IP-Plus will not accept any routes, from any source, if they represent blocks
of PA space that are no longer routed over the ISP that assigned the PA addresses. The only
exception is when a 'grace period' is allowed in order to allow a customer to renumber. The
normal period is one month, and agreement of the ISP that assignmed the space is required.
- If the customer has a range of PI addresses less than 32 contiguous C-class
networks, he must understand that global Internet connectivity is not guarenteed.
Miscellaneous
- The customer must have his own autonomous system number. If he does not
already have one, then one must be obtained from RIPE using the form RIPE-147
http://www.ripe.net/ripe/docs/asnrequestform.html.
Generally RIPE will only assign AS numbers to networks that have a published multihomed routing
policy.
- Multihoming is not available with the IP-Plus Internet managed router option.
The customer must have his own router running the BGP4 protocol. The customer is responsible for
the definition and maintenance of his routing policy and the router configuration.
- IP-Plus support BGP with customer routers from Cisco Systems and Bay Networks.
The normal serial protocol used with Cisco is Cisco HDLC. The normal protocol used with Bay is PPP.
Router Configuration Examples (Cisco)
Configuration (customer side) for local direct BGP session. AS6837 is the customer-side
AS. 164.128.x.x is the IP address of the IP-Plus POP router. This configuration created the
BGP session to the local IP-Plus POP, announces the routes in the AS6837 BGP routing process
to IP-PLus, and imports the Swiss routes from IP-Plus into the AS6837 routing process.
!
router bgp 6837
neighbor 164.128.x.x remote-as 3303
!
Suppose the customer wants IP-Plus to prepend on announcments to EBONE. This means setting the
community string '3303:2004' on the local BGP Annoucements. Something like the following
configuration could be used...
!
ip bgp-community new-format
!
router bgp 6837
neighbor 164.128.x.x remote-as 3303
neighbor 164.128.x.x send-community
neighbor 164.128.x.x route-map to-as3303 out
!
route-map to-as3303 permit 10
set community 3303:2004 additive
!
Operations and Monitoring
- Changing BGP Route filters: All AS numbers and IP Address prefixes must
be correctly entered into the IRR (normally RIPE database). If new AS numbers and/or prefixes
are to be announced from the customer to IP-Plus, notify IP-Plus operations using the
Change request at least 2 days in advance of the time when the new routing is required.
- Problems with the IP-Plus service can be reported 24 hours per day, 7 days
per week to Customer Support (CSU).
Customer related BGP problems (ie, problems that are
not related to the IP-Plus infrastructure itself and do not affect multiple customers) are
progressed during normal business hours.
- As far as possible, IP-Plus BGP customers are encouraged to diagnose problems
themselves, and include diagnostic information they collect when reporting problems to IP-Plus.
In order to assist self-diagnosis, customers have access to an IP-Plus 'Looking Glass' service
which enables them to collect BGP routing information from inside the IP-Plus BGP routing system.
By collating BGP information from the IP-PLus Looking Glass with similar information from
Looking Glasses in other networks it is often possible for a BGP customer to identify the
likely source of a problem himself, which will often result in a speedier resolution. IP-Plus
maintains a list of diagnostic tools, such as Ping and Traceroute Servers, and BGP Looking
Glasses.
|
