=============================================================================
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
=============================================================================
EBONE 92 IP ROUTING MODEL
=========================
Tony Bates, ULCC.
<tbates@noc.ulcc.ac.uk>
And
Peter Lothberg, SWIPnet.
<roll@stupi.se>
April 8, 1992
Abstract
The goal is to implement, and put into production, a shared
infrastructure for open architecture protocols in Europe;
EBONE supports two achietectures, "OSI" and "TCP/IP" and this
document describes both the model and implementation in terms
of routing for achieving this.
Content
1 Introduction.
1.1 Topology.
1.2 Basic Concepts.
2 Basic definitions.
3 Inter EBS routing.
3.1 Ebone IGP.
3.2 Ebone IBGP.
3.3 EBS examples.
4 EBS to RBS routing.
4.1 Single EBS to RBS connection.
4.1.1 Routing announcments towards the region from Ebone
4.1.2 Routing announcments towards Ebone
4.2 Other Scenarios
4.2.1 RBS to RBS routing
4.2.2 Routing for an RBS connected to more than one EBS.
4.2.3 Routing for a region with multiple RBS connections.
4.3 RBS examples.
5 Ebone to US routing.
5.1 Policy regarding Primary routes to the US.
5.2 Routing announcments towards ebone.
5.3 Routing announcements towards NSFnet.
5.4 Using Ebone as a backup to the US.
5.5 EBS to US examples.
5.6 Proposed next step for US - Europe routing.
6 References.
7 Appendix.
A Ebone description.
B EBS configuration guidelines.
C RBS configuration guidelines.
D US connectivity and backup guidelines.
E Tutorial on BGP and OSPF.
F Proposal for Ebone objects in RIPE database.
1. Introduction
This document describes an initial routing implementation to be used within
EBONE [1]. [1] defines two distinct systems to be used within the
EBONE framework, The "Regional Boundary System" (RBS) and the "EBONE
Boundary System" (EBS).
It will cover Inter EBS routing.
Routing between the Ebone Kernel and the continental US and routing between
an EBS and its respective RBS.of both the basic concepts and topology within
EBONE. However, it is recommended that there is an understanding of [1] prior
to reading this document.
1.1 Basic concepts.
The EBONE infrastructure complies to the generalised model of an open
networking multi-architecture backbone and uses two technical concepts
within it's model:
- the EBONE Boundary Systems (EBSs);
and:
- the Regional Boundary Systems (RBSs).
The EBSs are linked in such a way so as to create a resiliant backbone. The
RBSs provide backbone access for regional networks (Autonomous systems) via
a link to an EBS or multiple EBSs.
1.2 Basic Topology.
The basic topology of EBONE is that of a pentagon which makes up the EBONE
kernel. At each corner of the pentagon is situated an EBS which connects
to two other EBS's. At each EBS an unspecified number of connections will
be made to RBS's. At three of the EBS there exists a link to the USA.
The Ebone topology is not "definite" but changes has to be carefully
evaluated.
Figure 1 shows this in some graphic form.
/-- RBS
/--- RBS
/---- RBS
LINK 1 /----- RBS
USA <-------------- EBS
/ \
/ \
/ \
/ \
/ \
/ \
/ \
LINK 2 / \
USA <--------- EBS EBS
/| |\
RBS ----- / | | \------- RBS
RBS -----/ | | \------ RBS
RBS ----/ | | \----- RBS
| KERNEL |
| |
| |
| |
| |
EBS---------------EBS
/ / \
EBS --/ / \----- RBS
/
/
/
LINK 3 /
USA <----------------------------/
Figure 1.
For a more detailed looked at the topology please refer to [2].
2. Basic Definitions
Throughout this document certain definitions are assumed.
BGP is used to reference the routing protocol used on the border between
two autonomous systems (AS). It is the routing protocol used for inter
AS routing. It can be viewed as either the Border Gateway Protocol (BGP3)
(RFC1267 - [3]) , the Exterior Gateway Protocol (EGP) (RFC904 [4]).
The recommendation is to use BGP3 wherever possible for IP. See Appendix E.
For OSI IS-IS [7] will be used as a boarder gateway protocol.
** To make Ebone work, and the task of maintaining the network it is a
** absolute need that the Ebone kernel is keept isolated from any regional
** IGP. Routing has to be injected into Ebone from a region, it cannot
** be generated in a Ebone internal system!
** This is not politics, it was learned the hard way when we implemented
** the EBS/RBS configuration in Stockholm. Once working, it makes network
** managemnt a pice of cake. -Peter
IGP references the interior gateway protocol used inside an autonomous
system and within the Ebone kernel itself. It contains such
features as dynamic load sharing and subnet information. Initially Ebone
will use cisco systems IGRP protocol (cisco ref ??? [5]). When a stable
implementation of the Open Shortest Path First (OSPF) protocol (RFC1247 [6])
is available it will be used. For OSI the cisco OSI-IGRP will be used as
an interim soulution.
The term "cheapest" is taken to mean the closest and fastest path through
Ebone, as viewed by the EBS and based on the IGP information it receives
from its respective neighbors.
The term Autonomous System (AS) is used in its classic sense here. As a set of
routers or switches under a single technical administration. In routing
terms it will use an interior gateway protocol and some sort of common
metrics. It may sometimes in reality have more than one IGP running.
However, the fact is that to other ASs it is seen a single coherant interior
routing plan with a consistent view of its reachable networks. When talking
to other ASs it will use an exterior routing protocol (our BGP definition
above).
3. Inter EBS routing.
3.1 Ebone IGP.
Ebone itself will act as a single AS. Two IGP protocols are used, IBGP
and IGRP. There is a full mesh if IBGP peerings between all EBS systems,
so they will have a consistent way of the sorrounding networks. The IBGP
contains all the routing for networks external to the Ebone core.
IGRP are run to keep track of the paths between the EBS systems, but does
not have any information about external networks. IGRP information are
more trusted than IBGP, so false information in the IGRP will make the
packet forwarding to malfunktion, while the IBGP has correct information.
The AS path from region A to region B will only see Ebone once, A-Ebone-B.
The IGRP protocol itself will take care of finding the cheapest route through
Ebone to any EBS that connects a given European network. This will be done
on the basis of its metric.
Initially not all the Ebone links will be of the same bandwidth and
some slight tuning of the IGP metrics may be needed to avoid possible
non-optimal routing from taking place.
(IBGP are used for administration while IGRP are used for packet forwarding.)
Routing within the Ebone kernel is effectively "open" from the point of
view that no access control will be put on EBS routing announcements either
in-bound or out-bound to the Ebone kernel. For control purposes and pragmatic
reasons access control will take place at the EBS-RBS interface based on
information in the RIPE database [4].
The Ebone IBGP will carry routing information for all Ebone internal networks.
It is important to implement OSPF based routing as fast as possible so as to
minimise the bandwidth consumed in routing updates and the time taken for
routing information to converge following a topology change within the
IGP.
Carrying of CLNP routing is achieved by using ISO-IGRP as an interim solution.
3.2 EBONE IBGP
It is possible to use BGP for Intra AS routing to maintain a coherant
view of BGP derived routes. When used in this way we use the term IBGP. If
we use BGP3 as our BGP we can use IBGP as well as and IGP within the
the backbone. This will give us added functionality of avoiding routing loops
and path AS path information within the backbone.
Practically this is done by having a full mesh of IBGP sessions between all
EBS systems, the BGP derived route in any EBS will be the view the EBS that
connects to the RBS that has the destionation as its neighbour. The IGP has
the responsibility to find the chepest path to that EBS.
One of the cases where this important is when a region is having
connections to more than one EBS.
3.3 Inter EBS example.
Appendix B gives an example of a possible EBS configuration. It covers the
details of inter EBS configuartion. The configuration examples are all based
upon the cisco systems gateway software.
4. EBS to RBS routing
For this discussion we assume the model given in section 3. From any EBS
Ebone is seen as an AS. EBS to RBS routing is done on the basis of BGP.
As such EBS to RBS routing is inter AS routing. In many ways Inter AS
routing can be more complex than intra AS routing. Problems can occur when
there are back-door routes between regions and also when a region is connected
to more than one EBS. The basic case of a single EBS to RBS connection is
first examined. Followed by more complex scearios.
4.1 Single EBS to RBS connection.
For simplicity we look at routing as directional here taking each case
seperately.
4.1.1 Routing announcments towards the region from Ebone
The EBS peers with the RBS using BGP and redistributes relevant routes
from the Ebone IBGP. In addition to europeon routes the EBS will provide
routing to the NSFnet backbones as described below. It is recomended to
use them as default networks in the RBS along with the Ebone backbone
networks. Routes for non AUP networks are also carried, to ensure that
they will use the correct paths and allow for policy based routing
external to Ebone.
In the the single EBS to RBS set-up the RBS can request to only receive
the default networks. If BGP is being used AS path details will be given
too along with the networks stating how these networks were derived.
This makes it possible for the RBS to perform policy based routing.
4.1.2 Routing announcments towards Ebone
The RBS should announce all networks that belong to the region to the EBS.
Regions that have their own links to other regions should avoid announcing
them to the EBS, as long as they do not have a bi-lateral backup arrangement
for Ebone traffic with the transit region.
Acces control will be done on in-bouund annoucemants received by the EBS
using the RIPE database [8], [9]. It is recommended that the RBS uses
some form of out-bound access filter for sensible routing.
4.2 Other Secnarios
4.2.1 RBS to RBS routing
Inter RBS connections are primarily not a Ebone matter. However,
some guidelines could be useful for a smooth integration with Ebone.
When an RBS acts as a secondary access point for traffic from another
region. AS paths announced towards Ebone have to be correct, both
representing the current topology of the network and maintain consistency
with the RIPE database. For more details see configuration examples.
4.2.2 Routing for an RBS connected to more than one EBS.
The Ebone IBGP will take care of finding the shortest AS path to that region
and the IGRP will take the cheapest path to the EBS next to the chosen RBS.
If desired by the region, it can make use of the AS path received from the EBS.
4.2.3 Routing for a region with multiple RBS connections.
A region must take care not to redistribute routes derived from one RBS
connection across to any other RBS connection within its region.
It is recommended that the region adopts IBGP or atleast OSPF as it's IGP.
This gives the most functionality in that IBGP or OSPF as an IGP can carry AS
path information derived from the BGP. It is up to the region to decide how
it wishes to make best use of it's multiple connections to Ebone.
4.3 RBS examples.
Appendix C shows examples of all the above scenarios relevent to EBS to RBS
configurations. All configuaration examples are based upon cisco systems
gateway software.
C.1 Simple RBS to EBS with a region that uses IGRP and RIP.
C.2 RBS that talks to both another regional RBS and a EBS.
C.3 Using a router to turn IGRP<->BGP as a temporary kludge.
5. Ebone to US routing.
The routing implementation for traffic between the continental US and Europe
is a problem that has to be solved step by step. It needs co-ordination from
both sides. Deployment should be in several phases, where this document
describes the first and gives some guidleines for step2.
The following issues must be taken into account:
o Make use of a US link for PRIMARY access only where a bi-lateral
agreement exists.
o Maintain the current topology and connectivity wherever possible.
o Avoid cross Ebone transit traffic.
o Make use of Ebone for efficient backup of US links.
o Avoid heavy routing traffic.
o Avoid European routing via any of the US links.
It should be noted that point one is a decision made by the Ebone executive
and it will be seen that this has some impact on which EBS an RBS may decide to
connect to.
To make things simpler we view the US links as all connecting directly to the
NSFnet backbone. In fact in reality this is not the case but hopefully
it will be seen that this will not effect the implementation. Routing can
be looked at seperately in the same "from and towards" Ebone concept as
above.
5.1 Routing announcements towards NSFnet.
The EBS that connects to an NSFnet backbone router (NSS/ENSS)
announces all networks from Ebone that use that link with BGP,
which will have been derived on reachability information from the
Ebone IBGP. A network allowed on a certain link that is not reachable
shall not be announced. One way of implementing this is by filtering
the Ebone IBGP and advertise these routes to the NSFnet backbone.
There will be a separate AS (as today) for each link.
The NSFnet controls its routing by using a static database. So
although it receives European network announcements from each
of the peering EBS's it will construct an AS path selection on the
basis of the cheapest route to the destination network.
Hence, a simple matrix can be produced depending on which EBS
your network is connected to. The matrix tabled below is based upon the
issues given in section 5. The impact of this is that when connecting to
an EBS as a region your intercontinental traffic will flow a certain
way without any exception. Therefore an RBS must understand clearly the
routing used in the matrix below. The matrix is based very much with
a pragmatic and resource approach in mind. As such certain existing
agreements on use of US links may NOT be possible.
Key: LINK1 ~ KTH <-> CORNELL (NSS10) [512 Kbps]
LINK2 ~ ULCC <-> FIX-E (NSS9) [384 Kbps]
LINK3 ~ CERN <-> CORNELL (NSS10) [1.544 Mbps]
EBS connected to | PATH selection |
-----------------+-------------------------+
Stockholm | LINK1 | LINK2 | LINK3 |
London | LINK2 | LINK1 | LINK3 |
Montpellier* | LINK3 | LINK2 | LINK1 |
Geneva | LINK3 | LINK2 | LINK1 |
Amsterdam | LINK3 | LINK1 | LINK2 |
-----------------+--------+-------+--------+
* - Mediterrian area.
5.2 Routing announcments towards ebone. (traffic to US)
On an EBS that is connected to a US link, or an US-RBS-EBS configuration
announce T1 and T3 networks as orginating in the AS that peers with the EBS.
This implemention should be done such as if the peering with the NSS drops,
the announcment should also go away.
The EBS uses the T1 (network 129.140.0.0) and the T3 (network 140.222.0.0)
networks as default networks.
The IGP metric of US routes will be incremented for each EBS the routing
information passes. So from any given EBS a packet destinated to the US
will take the cheapest path through Ebone. This will of course mean that
some assymmetric US routing might take place.
When the EBS recives a packet that has to be routed it will be forwarded
according to the IGP informationusing the cheapest path.
If the destination network is not on a Ebone connected RBS or if the
destination is unknown it will take the cheapest path through Ebone to a
EBS that has a US connection. If the destination network is unreachable,
then the NSS will reject it and return a ICMP Network Unreachable message
to the packet originator.
5.3 Routing announcements towards NSFnet. (traffic from US)
As the world does not have any politics or AUP we asume that such problems
are taken care of elswere.
The EBS announces all Ebone routes with BGP through the system(s) that
connects the EBS to the NSS. NSFnet internal table driven routing takes
care of using the intercontinental link that ends in the EBS that has the
cheapest path to the destination.
5.4 Using Ebone as a backup to the US.
While all links are operational the traffic flow will follow the
current (920219) traffic pattern for those that are connected to
a EBS that has a US link.
Regions connected to a EBS without a US connection will follow
the routing mechanism as set out in the above matrix.
Again assymmetric routing will take place. Routing from Europe to US will
take place according to the cheapest route to the default network as given
by the Ebone IGP. This is only possible because the NSFnet accepts traffic
inbound on any NSS.
5.5 EBS to US examples.
?????!?!??!?!?!?
5.6 Proposed next step for US - Europe routing.
Implementing BGP carrying full AS paths between US and Ebone is a step
that we need to take during 1992. Is it possible to use BGP metrics to
balance the fact that the NSFnet is a T3 network, wile Ebone is only
1/4 E1.
This would make a dynamic selection
of paths. Another logical step would be to have a Ebone point of precence
in the US and its own bandwidth to transit continetal US to reach
destinations on the west-coast and Hawaii, Japan, Australia, New-Zeeland
etc.
6. References.
[1] Ebone-92 Proposal. Kit Miles.
[2] Ebone Line and site installation plan. Bernhard Stockman.
[3] BGP3. RFC1267.
[4] EGP2. RFC 904.
[5] Introduction to IGRP. Charles Hedrick.
[6] OSPF2. RFC 1247. John Moy.
[7] IS-IS. ISO 8473.
[8] Ripe Databases. ripe-w02, Rob Blockzijl.
[9] Proposed new Ebone routing objects in Ripe database. Bates, Lothberg.
7. Appendix.
APPENDIX A
Will add in the refernece of the Ebone installation.
APPENDIX B
EBS configuration guidelines.
interface Ethernet 0
description Ebone stub in sthlm
ip address 192.121.154.17 255.255.255.240
no mop enabled
!
interface Serial 0
description US-Washington link to ICMnet
ip address 192.121.154.241 255.255.255.240
bandwidth 768
delay 5000
!
interface Ethernet 1
description 123456789012345678901234567890123456789012345678901234567890
no ip address
shutdown
!
interface Serial 1
description London link to Mercury/ULCC
ip address 192.121.154.33 255.255.255.240
!
interface Ethernet 2
description Peters test RBS
ip address 192.108.209.1 255.255.255.0
bandwidth 1984
!
interface Serial 2
description SWIPnet RBS connection to HUB-3
ip address 130.244.7.1 255.255.255.248
bandwidth 1984
!
!
autonomous-system 1755 ;If we talk EGP this is needed
!
router igrp 1755 ;Ebone kernel IGRP
network 192.121.154.0 ;only on the Ebone network
passive-interface Serial0 ;not used on US link
!
router bgp 1755 ;BGP process
network 192.121.154.0 ;only the Ebone netwirk is I
neighbor 192.121.154.18 remote-as 1755 ;IBGP with EBS-2
neighbor 192.121.154.20 remote-as 1102 ;BGP with the Kludge region
neighbor 130.244.7.2 remote-as 1257 ;BGP to Swipnet region
neighbor 192.108.209.2 remote-as 1756 ;BGP to the test region
neighbor 192.121.154.242 remote-as 701 ;BGP to ICM/Alternet
neighbor 192.121.154.242 distribute-list 5 out ;Don't announce US to US
neighbor 130.244.7.2 distribute-list 20 in ;Ripe registerd networks
neighbor 192.108.209.2 distribute-list 21 in ;for each region
!
ip default-network 129.140.0.0 ;deafult routing
ip default-network 140.222.0.0 ;for any unknown destination
!
ip domain-name ebone.net
ip name-server 192.36.125.2
ip name-server 192.36.143.3
snmp-server community public ro
snmp-server community ebone rw
access-list 5 deny 129.140.0.0
access-list 5 deny 140.222.0.0
access-list 5 permit 0.0.0.0 255.255.255.255
access-list 20 permit 192.108.204.0
access-list 20 permit 192.108.205.0
access-list 20 permit 192.108.206.0
access-list 20 permit 192.108.207.0
access-list 20 permit 192.108.200.0
access-list 20 permit 192.108.201.0
access-list 20 permit 192.108.202.0
access-list 20 permit 192.108.203.0
access-list 20 permit 192.108.196.0
access-list 20 permit 192.108.197.0
access-list 20 permit 192.108.198.0
access-list 20 permit 192.36.143.0
access-list 20 permit 192.108.199.0
access-list 20 permit 192.108.195.0
access-list 20 permit 192.108.212.0
access-list 20 permit 192.108.213.0
access-list 20 permit 192.108.214.0
access-list 20 permit 192.108.215.0
access-list 20 permit 192.108.208.0
access-list 20 permit 192.108.209.0
access-list 20 permit 192.108.210.0
access-list 20 permit 192.108.211.0
access-list 20 deny 0.0.0.0 255.255.255.255
access-list 21 permit 192.36.115.0
access-list 21 permit 192.36.226.0
access-list 21 permit 192.36.215.0
access-list 21 permit 192.36.35.0
access-list 21 permit 192.108.213.0
access-list 21 permit 192.16.146.0
....
.....
access-list 21 permit 192.16.124.0
access-list 21 permit 140.150.0.0
access-list 21 permit 141.192.0.0
access-list 21 permit 192.121.7.0
access-list 21 permit 192.66.150.0
access-list 21 deny 0.0.0.0 255.255.255.255
banner motd
This is EBS-1 on Ebone in Stockholm Sweden
For operational problems contact staff@swip.net or telephone +46 20 92 50 50
hostname EBS-1
APPENDIX C
RBS configuration guidelines.
C.1 Simple RBS to EBS with a region that uses IGRP and RIP.
!
interface Ethernet 0
ip address 192.36.143.2 255.255.255.0
!
interface Serial 0
ip address 192.108.201.1 255.255.255.0
bandwidth 14
!
interface Ethernet 1
ip address 192.108.207.1 255.255.255.0
!
interface Serial 1
ip address 192.108.205.2 255.255.255.0
bandwidth 1900
!
interface Serial 2
ip address 192.108.209.2 255.255.255.0
bandwidth 2048
!
interface Serial 3
ip address 192.108.206.2 255.255.255.0
bandwidth 168
!
interface Serial 4
no ip address
shutdown
!
interface Serial 5
no ip address
shutdown
!
!
!
router bgp 1756 ;the as of my region
network 192.36.143.0 ;a list of networks i have in my
network 192.108.206.0 ;IGP, that i want to announce with
network 192.108.205.0 ;BGP to ethe EBS
network 192.108.209.0
network 192.108.196.0
network 192.108.197.0
network 192.108.195.0
network 192.108.200.0
network 192.108.198.0
network 192.108.199.0
network 192.108.201.0
neighbor 192.108.209.1 remote-as 1755 ;this is the session to the EBS
!
router rip ;local ethernet has RIP, yeeck!
default-metric 2
network 192.36.143.0
redistribute static ;dubble yeeck!
passive-interface Serial0
!
router igrp 1756 ;this is the igrp used in my
network 192.108.201.0 ;regional network
network 192.198.207.0
network 192.108.205.0
network 192.108.206.0
!
ip default-network 129.140.0.0 ;when no explicit route is avaliable
ip default-network 192.121.154.0 ;pass traffic to a higher level.
ip default-network 192.121.154.0 ;this is the Stockholm EBS network
!
snmp-server community public RO
snmp-server community Ebone RW
!
hostname Stupi-RBS
!
end
C.2 RBS that talks to both another regional RBS and a EBS.
!
!
interface Ethernet 0
ip address 192.36.125.15 255.255.255.0
ip broadcast-address 0.0.0.0
!
interface Serial 0
ip address 130.244.3.9 255.255.255.248
bandwidth 10
!
interface Ethernet 1
ip address 130.237.210.15 255.255.255.0
no ip proxy-arp
!
interface Serial 1
no ip address
shutdown
!
interface Ethernet 2
ip address 192.36.148.26 255.255.255.240
!
interface Serial 2
no ip address
shutdown
!
interface Ethernet 3
ip address 130.244.3.241 255.255.255.248
Description: Point-To-Point ethernet to Sunet
!
..
..
!
interface Serial 11
ip address 130.244.7.2 255.255.255.248
bandwidth 2048
Description: 2.048 to EBS-1
!
!
autonomous-system 1257
!
router igrp 1257 ;this is our igrp for regional
network 130.244.0.0 ;routing
network 192.36.148.0
network 192.36.125.0
distance 98 ;if more than one IGRP are running
redistribute static ;prefer our own routes over others.
passive-interface Serial11 ; and don't send IGRP to the EBS
!
router bgp 1257
network 130.244.0.0
network 192.36.148.0
network 192.36.125.0
network 192.108.206.0
network 192.16.143.0
network 132.196.0.0
network 134.138.0.0
network 192.71.236.0
network 192.121.204.0
network 192.36.19.0
network 192.36.220.0
network 192.36.221.0
network 192.16.141.0
network 192.71.15.0
network 192.71.168.0
..
..
network 192.36.188.0
network 192.71.247.0
neighbor 130.244.3.242 remote-as 1653 ;RBS to RBS (Link to Sunet)
neighbor 130.244.7.1 remote-as 1755 ;RBS to EBS
neighbor 130.244.7.1 distribute-list 3 out ;do not announce T1 and T3
!
router igrp 1653 ;this is Sunet routing
network 130.244.0.0
network 130.237.0.0
passive-interface Serial11 ;stay off the EBS
!
ip default-network 129.140.0.0 ;default routing
ip default-network 192.121.154.0 ;EBS networks
!
!
!
snmp-server community Ebone RW 1
snmp-server community public RO 1
!
access-list 3 deny 129.140.0.0
access-list 3 deny 140.222.0.0
access-list 3 permit 0.0.0.0 255.255.255.255
C.3 Using a router to turn IGRP<->BGP as a temporary kludge.
!
interface Ethernet 0
description Ebone stub in sthlm
ip address 192.121.154.20 255.255.255.240
no ip proxy-arp
!
interface Serial 0
description amsterdam link
ip address 192.121.158.18 255.255.255.240
bandwidth 256
!
interface Ethernet 1
no ip address
shutdown
!
!
autonomous-system 1102
!
router igrp 1755 ;this sits on the Ebone ethernet
network 192.121.154.0 ;but is interacting as a RBS
network 192.121.158.0
passive-interface Serial0 ;Dont give igrp 1655 to Amsterdam
!
router bgp 1102 ;announce what we hear from
distribute-list 21 out igrp 1102 ;Amsterdam with BGP 1102 to the EBS
network 192.121.154.0
network 192.16.126.0
network 192.121.158.0
redistribute igrp 1102
neighbor 192.121.154.17 remote-as 1755 ;peer with Stockholm EBS-1
!
router igrp 1102 ;Turn BGP derivated routes into IGRP
distribute-list 20 out ;the RIPE access-list
default-metric 10000 2000 255 100 1500 ;with those metrics
network 192.121.158.0
redistribute bgp 1102 metric 1000
neighbor 192.121.158.17
passive-interface Ethernet0
!
ip default-network 129.140.0.0
!
banner motd
This is EBS-4 on Ebone
For operational problems contact staff@sunet.se or telehone +46 8 24 11 41
hostname EBS-4
APPENDIX D
US connectivity and backup guidelies.
APPENDIX E
Tutorial on BGP and OSPF. P Lothberg
The intent of this small tutorial is not to cover neither BGP3 or OSPF
in deep, but to give a summarized breefing on the subject, in order to
help the naive reader to more easy understand the Ebone routing model.
BGP,
---
BGP is a Inter-domain protocol, designed to be used as an domain to domain
routing protocol.
BGP is designed to be able to handle policy based routing, detect routing
loops and has the possibilitie of using metrics so that intelligent routing
decisions may be made by the routers. BGP does not impose topology
restrictions like EGP does since it has the mechanism of detecting routing
loops. BGP carries AS path information which *might* allow for policy based
routing. BGP does incremental update which consume less resource of bandwidth,
CPU of routers than periodic update routing protocols such as EGP. BGP is
today slowly replacing EGP in large networks.
Although designed as an interdomain protocol, BGP may be used both
within and between domains. Two BGP neighbors communicating between
domains much reside on the same physical network. BGP routers within
the same domain communicate with one another for two reasons:
- to ensure that they have a consistent view of the domain
- to determine which BGP router within that domain will serve
as the connection point to/from certain external domains
Running BGP within a IGP are given the term IBGP, and most routers that
implements BGP have this facility and maintain their BGP routing tables
separated from the IGP and forwarding tables.
Some domains are transit networks, in other words, some domains carry
network traffic that did not originate within and is not destinated for
them. BGP must interact with whatever intra-domain routing protocols used
within these domains. Ebone is such a transit network, no routes is
generated within the domain, it only transfers routing between its boarders.
These interactions, while beyond the scope of this document, are detailed
in the BGP protocol specification. OSPF is one of the few IGP protocols
that have the hooks to be able to "avoid" the use of both a IBGP and
IGP within a network that are transit, but there are no implementations
comercially avaliable, yet.
BGP update messages consist of network number/domain path pairs. The domain
path contains the string of domains through which the specified network may
be reached. These update messages are sent over the TCP reliable transport
mechanism.
The initial data exchange between two routers is the entire BGP routing
table. Incremental updates are sent out as the routing tables change.
Unlike some other routing protocols, BGP does not require periodic refresh
of the entire routing table. Instead, routers running BGP retain the latest
version of each peer routing table. Although BGP maintains a routing table
with all feasible paths to a particular network, it only advertises the
primary (optimal) path in its update messages.
The BGP metric is an arbitrary unit number specifying the "degree of
preference" of a particular path. These metrics are typically assigned by the
network administrator through configuration files. Degree of preference may
be based on any number of criteria, including domain count (paths with
smaller domain count are generally better), type of link (is the link stable?,
fast? reliable?), and other factors.
OSPF
----
OSPF Open Shortest Path First, is a intra-domain hierarcical routing protocol.
Information on attached interfaces, metrics used, and other variables are
included in OSPF routing updates. This information is flooded throughout
the routing area. As OSPF routers accumalate link state information, they
are able to calculate the shortest path path to each node. Updates are
only required when a link state changes. "Hello"messages act as keepalives to
let routers know that other routers are still functional.
Additional OSPF features include equal cost multi-path routing and routing
based on upper-layer type of service (TOS) requests. TOS-based routing
supports those upper-layer protocols that can specify particular types of
service. For example, an application might specify that certain data is
urgent. If OSPF has high priority links at its disposal, these may be used
to transport the urgent datagram.
OSPF supports one or more metrics. If only one metric is used, it is
considered to be arbitrary, and TOS is not supported. If more than one
metric is used, TOS is optionally supported through the use of a separate
metric (and, therfore, a separate routing table) for each of the eight
combinations created by the three IP TOS bits (the "delay", "throughput"
and "reliable" bits).
For example, if the IP TOS bits specify low delay, low throughput and
high reliability, OSPF calculates routes to all destinations based on
this TOS designation. Obviously, this calculations can be extremely resource
intensive.
APPENDIX E
Ebone objects in RIPE database, proposal, T. Bates and P. Lothberg 1992 03 15
In order guarantee the rubustnes of the Ebone core against errounous
routing information beeing propagated some kind of checking of routing
information supplied by the EBS from an RBS has to be done.
This is NOT intended for enforcing any policy (any policy has to be
implemented by the RBS), just as a housekeeping tool.
In order to avoid dubbeling the work performed by the RIPE NCC, ie maintain
an Ebone routing database in pararell with the RIPE NCC database our
proposal is to add this information into the RIPE database. Besides
the savings in work, we think it will motivate networkers in Europe
to update their information in the RIPE database.
To ease the operations Ebone and create tools for troubleshooting some
additional information is needed for a given network.
- The AS number where this network number belongs.
- A list of via wich AS numbers peering with an EBS this network
is reachable, in priority order.
Example:
net: 192.108.200.0
con: Ripe|Nfs|swip|Ebone
as: 1257
path: 1257|1654
Net and Con together with all existing information, no change.
AS, is the as where this network belongs, the normal case is the region
where it is connected. (Region in the term some collection of network(s)
connected to an RBS.)
Path, is a list of AS numbers belonging to RBSs peering directly with
and EBS that has connectivity to the network and has agreed to transit
trafic. In the case of multiple connections to Ebone, they has to
implement the same policy as the primary path. Otherwise we will have
black wholes instead of true redundancy.
192.108.200.0 are within the Swipnet AS (1257) and as the Swipnet-RBS
peers direct with the Stockholm EBS, 1257 is the prefered way out from
Ebone to this destination. Swipnet and Sunet (1654) has a bi-lateral
agreement of backing eachother, so they talk IBGP between themself
outside Ebone so that in the routing from the Sunet RBS all the
1257 routes will appear (and vice versa), but with a longer AS-path
than the one throgh the Swipnet RBS.
If 192.108.200.0 are announced from any other AS peering with Ebone,
this is in error and shold be discarded. This is acomplished by generating
a inbound routing filter list for the EBSs based on information derivied
from the RIPE database.
A suggestion is that this table updates will take place two times a week,
mondays and thursdays, to allow one workday after each change.
A databese over Regions, their ASes and contact persons would also be
a usefull tool.