skip to content

IT Help and Support

University Information Services
 

Typically, institutions have a PoP switch with two uplinks to UDN backbone routers. The routers provide the gateway / default router address for end-user hosts or an institutional border router; a First Hop Redundancy Protocol (FHRP), running between the routers, allows this gateway address to move to the other of these routers, should the active one fail. With this mechanism, institutions need not make any special configuration to have a redundant connection to the UDN.

However, this arrangement has a number of shortcomings which can be undesirable to institutions with larger, more distributed networks:

  • There is a reliance on the PoP switch as a single piece of equipment which can fail and affect an entire institution.
  • A single IP uplink to the UDN can only be presented at one physical location (where the PoP switch is).
  • Which links are used for which traffic cannot be prioritised or selected.
  • Multicast on static routed links does not function correctly, due to an incompatibility between the FHRP used on the UDN and PIM-SM.

To address these issues, the UDN is introducing a BGP dynamic routing service. This service allows the UDN and institutional routers to exchange routing information and dynamically reroute traffic in the event of the failure of a link or router, even via a completely different connection to the UDN, at another site.

In addition to addressing most of the above issues, BGP allows cooperating institutions to back up each other's connections in two ways:

  • A manual backup arrangement whereby one institution can advertise the IP ranges of another for a temporary period. In the event of a problem at the primary site, the secondary site can provide connectivity to an off-site backup server. This can be for some, all, or even one, IP address.
  • Institutions can link their networks together and offer backup connectivity to each other. Traffic will normally use the primary connections but failover to the link between institutions, in the event of either failing. Traffic between the institutions will normally not go via the UDN (however, all this can dynamically controlled by the institutions).

In the above situations, all institutions involved must run BGP, even if the arrangement is not reciprocal.

Contents

A word of caution

IMPORTANT NOTE! BGP is a complex protocol and requires a significant degree of expertise to configure, maintain and diagnose faults. Institutions making use of this service must understand that the responsibility of managing their BGP connection lies with them and general advice or assistance cannot be given by University Information Services (UIS).

The information given here is not intended as an introduction or guide to BGP but an explanation of how it's implemented on the UDN for institutional connections. Institutions wishing to make use of BGP must ensure they undertake all appropriate research, training and testing prior to implementation.

Equipment supporting BGP can be expensive to buy and/or maintain. Institutions should ensure they have such equipment on appropriate support contracts to resolve issues. If changes in the UDN configuration expose problems with institutional equipment, it is the responsibility of the institutional network manager to diagnose the fault and take appropriate action.

If there are significant problems in operating a particular BGP peering, the service will be withdrawn and the institution must transition back to a static connection.

In short, if the information here doesn't make sense, BGP is probably not suitable for deployment in your institution!

Service developments

In addition to the above, it may be determined that changes must be made to the BGP service to accommodate unforeseen problems or additional features, especially as the service is new.

Whilst every effort will be made to introduce these in a compatible way and no changes should be made which break existing connections without warning, institutions must be aware that they may be required to revisit their configuration, in light of service developments, and make updates in a timely fashion.

Hierarchy of BGP on the UDN

The UDN peers using BGP with EastERN (the East of England Education and Research Network, part of Janet) for its connection to the UK academic network and on to the internet. This peering provides the UDN with its default route (0.0.0.0/24 for IPv4 and ::/0 for IPv6) via AS786 (Janet).

As the UDN only peers with one upstream provider - Janet - the UDN itself is AS64602, a private AS allocated by Janet. This AS is stripped from the paths to UDN prefixes, when they are advertised to networks outside Janet.

This arrangement is similarly provided within the UDN to institutions: institutional networks using BGP will be allocated a UDN-wide private AS number (ASN) from the range 65100-65199. Institutions can advertise prefixes over multiple peerings to the UDN, or even via AS paths through each other, but only the UDN global prefixes will be advertised to Janet, directly from AS64602.

When running BGP on a connection, first hop redundancy will be disabled, leaving the networks to use BGP to manage redundancy and fail over as an intrinsic part of the protocol.

Removal of the PoP switch

Usually the driver behind moving to BGP for an institution is to eliminate the PoP switch as a single point of failure in the connection of an institution to the UDN, replacing it with two separate links to different locations and equipment at an institution (the 'dual institutional router link' scenario, below).

When removing a PoP switch, it is important to note that VLANs will no longer be available to an institution on their UDN connection. Instead, the various IP ranges used by them will need to be routed across the BGP peering links and split out by the institutional router(s) onto separate VLANs locally, as well as any additional required configuration such as access controls, DHCP relaying and multicast support.

VLANs are often used to support various University-wide sides services, including the University Telephone Network, University Wireless Service and Building Management System (BMS). Which are in use at a particular site varies per institution.

A full list of these VLANs and the details of what is required to support to them are provided on the infrastructure service networks page. Institutions will need to verify they can support the full range of services required across their link.

If this is not possible, institutions can elect to retain their PoP switch and have their link subnets delivered as VLANs through it, although this won't necessarily eliminate the PoP as a single point of failure, unless a second PoP is also utilised. It should be noted that failover times will likely also be significantly increased as a link failure will not immediately be detected by a device on the other side of a switch.

The UDN charges for institutions without a PoP are different, reflecting the lack of need for an extra piece of hardware to deployed at a customer site.

Example configurations

A number of example configurations are presented below, along with reasons for choosing them. The example configurations include:

In practice, there are many more possible configurations which can be a hybrid or extension of the ones presented here. Institutions should discuss their requirements with the UIS Networks group, if they are unsure.

Single institutional router link

In the simplest case, a single institutional router can peer with two UDN routers. This is useful where the institution wishes to take advantage of BGP's ability to resolve one or more of the following issues:

  • To allow an institution to temporarily advertise the prefixes of another (during an invoked DR situation).
  • When running a connection without a PoP switch.
  • To allow multicast to work where an institutional router is used (to solve the incompatibility between the FHRP and PIM-SM).

For a single router, the following will be allocated:

  • A pair of VLANs with IPv4 / IPv6 (as appropriate) link subnets (/30 for IPv4 and /126 for IPv6). These are unlikely to be the same VLANs / subnets as might be used for an existing static routed link (which would use a /29 or larger, to accommodate a FHRP).  The addresses used for these subnets must not be used for anything other than establishing the peerings with the UDN as they can change as connections are moved or with other developments on the UDN: they must not be used for outside NAT or used as a regular address allocated to the institution.
  • A UDN-wide private AS number for the institution, in the range 65100-65199.

If the institution has a PoP switch, the institution must confirm which port(s) on the PoP the link VLANs are to be fed to and how they are to be presented.

The institution should then set up its end of the peering, with the UDN router ends of the link subnets as the neighbour addresses. The peering will be eBGP (exterior BGP) over a single-hop between AS64602 and the institution's AS.  No password is used on this peering.

Where this arrangement is used to allow one institution to advertise the prefixes of another, the following must be noted:

  • This is intended to support temporary situations (such as a DR scenario) rather than a long-term method of reassigning addresses. Institutions cannot, in general, transfer ranges between each other and should contact the UIS Networks group about reassignment, if this is required: BGP must not be used as a mechanism to achieve this.
  • It is the responsibility of the institutions to ensure that they do not both advertise the same prefix, at the same time, with different source ASs: the institution providing the DR service must not advertise prefixes when they are not required.

Dual institutional router link

Where an institution wishes to remove its border router as a single point of failure, the peerings to the UDN routers can be separated out onto different institutional routers:

In this situation, it is likely that the institution will need to run an iBGP (interior BGP) peering between their two routers connecting to the UDN, to distribute the routing information learnt from the UDN between them. An Interior Gateway Protocol (IGP) and FHRP may also be required, to manage redundancy within the institutional network.

Institutions must ensure that their two internal routers do not lose contact with each other and rely on the UDN to provide connectivity between them. If this situation must be handled, it may be preferable to operate the two halves of the institutional network as separate ASs, perhaps with an internal connection between them, as described below.

The UDN does not require any special configuration when switching from peering with a single router over two links, to two routers with a single link to each and interconnected.

Inter-institution backup link

Two internal ASs can be connected together and peer directly with each other, as well as to the UDN:

This is useful in two main situations:

  • Two institutions wish to back up each other's connections to the UDN.
  • A single institution has two sites and wishes to cope with a loss of connectivity directly between them by routing traffic via the UDN backbone.
  • The two institutions exchange a significant amount of data with each other and wish to install a fast interconnect to avoid this traffic passing over the UDN. If the direct link is unavailable, traffic will fall back to crossing the UDN.

There are a number of points to bear in mind:

  • To permit advertisements from cooperating parties, the UDN will need to be aware of which institutions are backing up which others. Note that this arrangement need not be reciprocated (e.g. St Botolph's College can provide backup to Mincington College, but there is no need for Mincington College to back up St Botolph's College).
  • The prefixes advertised by the two ASs must be distinct: a particular prefix must only originate in a single AS and must not overlap with those advertised by another.
  • All institutions must ensure filtering and firewalling is handled correctly to allow traffic to enter/leave via the link to the other institution, including traffic transiting one institutional network from the UDN to get to the other.
  • The institutions involved must be aware that problems with a cooperating party can have an impact on their own network connectivity and should have a suitable level of mutual trust. In emergency situations, the UDN can be reconfigured to block incorrect information from the rogue party, but this should not be viewed as a normal solution and may take time to implement.

Once this arrangement is set up, institutions can select the normal and backup paths used for any particular prefix by adjusting the advertisements between them and to the UDN. For example, an inter-institutional link could be used just for traffic directly between the institutions and not as a general backup link to the UDN.

As with a dual institutional router link, more complex institutional networks (with multiple routers) may also require that iBGP and an IGP is used. This does not affect connectivity with the UDN.

Traffic logging, accounting and emergency response

Regardless of which path traffic takes, UDN traffic accounting and charging applies at the IP prefix level and is not affected by which institution's physical link is used (for example, if St Botolph's College's direct link to the UDN fails and routes via Mincington College, traffic will still be correctly attributed and charged to St Botolph's College).

That said, problematic traffic may reroute via other institutions and the transit institutional network may be affected by emergency filters or blocks applied on the UDN, although these are usually constrained to the true source as far as is possible.

Peering policies

The following section describes the details of the eBGP peering policies between the UDN and institutions.

Inbound to the UDN from the institutional network

The UDN will filter routing information advertised by institutions over the eBGP peering:

  • The prefixes received must be ones belonging to the institutional AS, or one of the institutions which it is providing a backup service for (either in a DR scenario or as a transit AS).
  • The AS paths contain only the ASNs of networks permitted through this connection (in the case of a single institution, this is just the ASN of that institution; where inter-institution backup links are used, these will contain the ASNs of the partner institutions).
  • A peering will be shut down if it receives an excessive number of prefixes - typically this is over 15 for IPv4 and over 10 for IPv6, but will be raised as needed (e.g. if an institution is backing up another, or has a large number of its own prefixes). If an institution is unsure, they should contact the UIS Networks group before adding more prefixes.

Institutions must not assume that the UDN routers will filter out all invalid information and should apply their own filters to remove small internal routes or institution-private ranges. The normal situation should be that no routes are being filtered: the UIS Network Systems group will contact institutions where routes are being removed by inbound filters.

There are no restrictions on the lengths of prefixes which can be advertised - for example, a /32 loopback IP address route could be sent. However, institutions should avoid sending an excessive number of routes without good reason - in general, just the aggregate prefixes for the institution should be sent, unless specific prefixes are required for steering traffic. Also note the limit on the number of prefixes which may be sent, as described above.

Institutions must route all prefixes that they advertise across their peering: if an aggregate prefix is generated from internal subprefixes, unused addresses in that aggregate must be blackholed: they must NOT be routed back to the UDN and cause a traffic loop.

Institutions with prefixes matching those advertised to Janet

A small number of institutions have prefixes which match those advertised by the UDN to Janet directly (e.g. the Department of Engineering have 129.169.0.0/16). For such institutions, there are some complications regarding how their routing is advertised to Janet. When such an institution requests the BGP service, this issue will be discussed further with them.

For institutions which only advertise part of a global prefix (e.g. a /24 inside 131.111.0.0/16), this situation does not apply and no special configuration is required.

Outbound from the UDN to the institutional network

The UDN will advertise two or three main classes of route over the eBGP peering with the institutional border router(s):

  • The default route (0.0.0.0/0 for IPv4, ::/0 for IPv6) via the UDN and Janet (AS path: 64602 786). In the event that the Janet connection is unavailable (e.g. the link is down or the UDN border router is unavailable) this route will cease to be advertised (leaving the institutional network with no route to addresses outside the UDN).
  • The routes to UDN prefixes, both global and UDN-wide private (AS path: 64602). Currently, there are 13x IPv4 prefixes and 1x IPv6 prefix but this may change. Unused address space in these prefixes will be blackholed by one of the UDN routers.
  • Institutions with an inter-institution backup link will also receive the routes from the other institution(s), with the UDN as a transit network in the AS path.
    • Note that this does not apply to institutions which are just providing a DR service (where a prefix will be advertised by another AS, when the DR arrangements are invoked).

Institutions will not receive a full UDN routing table as it is both large (well over 1,000 routes) and unnecessary.

Traffic path control

The UDN employs equal-cost multipath routing (ECMP), whereby traffic is shared amongst a number of available best paths across the backbone. At the present time, this is set to a maximum of two, although this should not be relied upon and may be altered in future (most likely increased).

In most cases, institutions can advertise all prefixes across all peerings equally and BGP will select up to the maximum number of best paths to route traffic to an institution. For an institutional network connected directly to the UDN through one or more routers, this will typically result in the link(s) which have the longest uptime being selected. Where an institution has another connection to the UDN, through an inter-institution backup link, the direct connection from the UDN will be preferred due to it having the shortest AS path.

However, a particular path should not be relied upon, unless explicit preferences are given. Reasons why institutions may wish to prioritise links explicitly include:

  • An institution with multiple sites, each with their own router and using distinct address ranges but a single AS, may prefer to have the appropriate prefixes routed directly to each site (from the nearest UDN router), but still provide failover via each site, if one of the site uplinks becomes unavailable.
  • If the institutional network has traffic policies or equipment (such as a firewall) which require that traffic flow is symmetric and predictable, it may be necessary to force a particular route.

In these situations, the UDN BGP implementation supports several ways of indicating preferred inbound paths, all configurable by the institution and can be changed at any time, as well as be mixed. In order of priority (highest first):

  1. Longest-prefix matching
  2. Community-based preferences
  3. MED-based preferences
  4. AS path length

It must be noted that outbound route selection is the responsibility of the institutional network and can be undertaken using any appropriate method – BGP local preference, IGP costs/metrics or policy-based routing (PBR – perhaps using the source address). In general, the UDN requires that traffic flow is symmetrical, and traffic may be blocked if it attempts to enter the UDN across a link that is not preferred for that source address. Institutions can employ ECMP for outbound routes to increase available bandwidth, if desired.

Longest-prefix matching

As with any IP routing mechanism, a longer prefix will be used in preference to a shorter one. This can be useful for institutions with multiple sites, wishing to steer traffic over their corresponding links, where each uses distinct address space.

For example, if the following routes are advertised over two peerings:

Peering 1 Peering 2
172.27.89.0/24
172.27.89.0/26 172.27.89.64/26

This will cause traffic to each /26 to be routed over the appropriate links; the path for traffic to the remaining block (172.27.89.128/25) will be undefined. In the event of one of the peerings failing, the /24 advertised by the other link will match the /26 route which has gone down and traffic routed via that.

Community-based preferences

Advertisements of the same prefixes across different peerings can be prioritised by attaching a BGP community to them: the UDN has four special communities which can be used to influence routing decisions. In order of preference, highest first:

  1. 64602:1 - the highest priority, to be preferred over all others
  2. (no community) - 'normal' priority
  3. 64602:2 - a lower priority
  4. 64602:3 - an even lower priority
  5. 64602:4 - the lowest priority, to be used only when no better route is available

Institutions with inter-institution links must arrange with their partner institution to ensure that communities are correctly propagated through the link and on to the UDN.

Only one of the above communities should be used at any time.  If multiple priority-based communities — either specified (such as the ones used for blackholing traffic) or unspecified — the behaviour is undefined.

MED-based preferences

This is the standard way of influencing routing to an upstream provider network - the Multi Exit Discriminator (MED) value is set to indicate a metric for the route (lower is more preferred; the default of 0 is highest, so it can only be lowered).

However, while MED values are supported by the UDN, the community-based or AS path length methods are recommended as they can cross transit ASs more easily and scale better.

AS path lengths

For an inter-institution backup link, with institutions backing each other up at all times, the shortest AS path will operate by default, given everything else being equal, and route traffic across the shortest number of ASs to the destination AS, even if this means more router hops. For example, traffic originating from the UDN (including an institution not using BGP) will prefer crossing several routers on the UDN backbone to get directly to an institutional network, rather than transiting an institutional network directly connected to the source router and using an inter-institution link.

One way of selecting a preferred path is for a router to artificially pad out the AS path by repeating its ASN several times. For example, if an institution with AS65103 has two links directly to the UDN, it could advertise the same route with path "65103" through one and "65103 65103" through the other: the former would be preferred.

Padding an AS path is supported by the UDN, provided all the ASNs used within it are permitted on a particular peering and the path itself is valid.

Remotely triggered black hole facility

The UDN and Janet both support a remotely triggered black hole (RTBH) facility, triggered by peers advertising prefixes with BGP communities. This is useful when institutions are suffering an attack to a small number of addresses which results in a large amount of traffic that overloads their uplinks to the UDN, or to the UDN from Janet: the traffic to those addresses can be blackholed upstream of the institutional network (or even inside Janet, before it reaches the UDN) and avoid it reaching to them.

For low-volume attacks, it is recommended that traffic be blocked using regular access control lists. In particular, note that the blackhole service will stop ALL traffic TO a particular IP address: it cannot block specific ports, nor traffic from specific source addresses.

The two communities supported are:

Community Effect Recommended use scenarios
64602:665 Blackhole traffic at the UDN-Janet border

The institution wants to block traffic to this address from external (Janet/internet) sources but leave it otherwise accessible from inside the UDN.

If the amount of traffic is disruptive to the operation of the UDN, and/or its connections with Janet, 64602:667 should be considered instead (see below).

64602:666 Blackhole traffic on the UDN

The amount of attack traffic is greater than an institution (or its uplinks) can handle, but the amount does not present a problem to the UDN and its connection to Janet.

The attacking hosts are (at least partly) inside the UDN.

64602:667 Blackhole traffic on Janet The amount of attack traffic detrimentally affects the UDN and/or its uplinks to Janet, or Janet itself. If just this community is used (not in conjunction with 64602:666) then the addresses covered by the prefix will continue to be available from within the UDN.
65535:666 Blackhole traffic on the UDN

This community is functionally identical to 64602:666, above, except that it cannot be used in conjunction with any other community.

This community is defined in RFC7999 by the IETF to provide a standard method to signal blackhole routes.

Prefixes can be advertised with one or both of the 64602-based communities, as appropriate, without the need to contact UIS Networks in advance.  The prefixes may be a single host or a wider block.

If these communities are used along with any others — either specified (such as the ones for route priorities) or unspecified by the UDN — the behaviour is undefined.

Institutions invoking these blocks should advise CSIRT and UIS Networks as soon as practical. They are not intended as a long-term solution, but are useful to resolve immediate operational issues.

If institutions are unfamiliar with the process for setting these up, UIS Network Systems can manually add or remove them on the UDN itself.

Redundancy, maintenance and faults

When using BGP to link to the UDN, redundancy is achieved by running multiple BGP peerings between institutional routers and UDN routers. In the event of the failure of one of these routers, or the link between them, routing should switch to an alternative path within a short period of time (a few seconds at most).

In addition to faults, equipment can be taken out of service for reconfiguration, software upgrades or hardware replacement. For the UDN equipment, this will normally happen during one of the advertised 'at risk' periods (usually between 8am and 9am on a weekday morning). Notice of specific, short maintenance activities will not normally be advertised as no loss of service should be experienced due to the intrinsic redundant configuration.

However, sometimes equipment may be taken out of service for a major upgrade, or be unavailable due to equipment failure outside supported hours, resulting in one of the paths being unavailable for an extended period. Planned outages of significant length will be advertised so affected institutions can ensure their connection is ready for the changes.

It is also understood institutions may also wish to perform similar activities and this may result in links/peerings being dropped and redundancy not being available during these periods. Institutions should aim to keep these maintenance periods as short as possible and notify UIS's Networks division in advance so UDN maintenance which might affect the remaining active path(s) will not overlap.

It is important that, in the normal situation, an institution's connection is fully redundant, for all services, across both paths, to support the above practices.

Miscellaneous

Router IDs and loopback addresses

Routers which are connected to multiple subnets are often given a loopback address to anchor services which require a permanently-available IP address (for example, the management interface or iBGP peering address). The IPv4 loopback address is also often used as BGP router ID for both IPv4 and IPv6.

  • For institutions with a single router, it may be adequate to avoid the need for a dedicated loopback address and use the router's IPv4 address on an internal subnet.
  • For more complex institutional networks, with multiple routers and internal subnets, dedicated loopback addresses may be required. If an institution requires additional IPv4 address space for loopback addresses, a small block of UDN addresses can be requested; for IPv6, there is sufficient space within an institutional /48.

Regardless of what address is chosen for the router ID, it must come from UDN IPv4 address space allocated to the institution.

IPv6

The UDN BGP service fully supports IPv6, on feature parity with IPv4.

If IPv6 support is required, a separate peering using IPv6 neighbour addresses is required (thus, the new link subnets will require IPv6 addresses, in addition to IPv4). Address families must be exchanged across a peering using the same transport protocol (i.e. an IPv4 peering can only be used to exchange IPv4 routes; an IPv6 peering only IPv6 routes).

Multicast

The multiprotocol extensions to BGP (commonly called MBGP) are used to distribute Reverse Path Forwarding (RPF) routes for multicast, as part of the IPv4 multicast and IPv6 multicast address families. When a peering is set up on the UDN, multicast routes will automatically be enabled and advertised/accepted in line with the equivalent unicast policies.

If the institutional router is not set up to support the multicast address families this will be detected and the multicast RPF routes will not be exchanged. However, the peering will operate without issue for unicast: this is an acceptable and supported configuration.

Please note that enabling multicast on an established BGP peering will likely cause the peering to restart, with an interruption to routing, so should be done at a suitable time (although note that IPv4 and IPv6 are separate peerings, so enabling IPv6 multicast will only restart the IPv6 peering and not affect IPv4).

Multicast traffic itself is not routed by BGP and is covered separately.

Soft reconfiguration and graceful restart

The UDN routers support soft reconfiguration and have this enabled on the peerings to institutional routers. Institutions are strongly recommended to do the same, to avoid interruptions to connectivity when a peering is adjusted (for example, to add new prefixes or permit backup arrangements).

In addition, the UDN routers will advertise and respond to graceful restart for routers that support this to allow the control plane to restart (perhaps following a software update), whilst the forwarding plane continues to forward traffic.

Procedure

Institutions wishing to use BGP to connect to the UDN must ensure they've read and understood all of the information on this page, in particular the word of caution.

Requesting the BGP service

Once the institution wishes to proceed, the institution should contact the UIS Network Systems group, giving a general description of what their requirements are, and the eventual topology, including the following:

  • Which physical site(s) they would like their peerings to be presented at (this will typically be the same location as the existing PoP switch).
  • Which port(s) on the PoP the links are to be presented on (it is likely, for an existing connection, that the BGP link will involve the PoP switch, at least in the first instance).
  • If the institution wishes to (eventually) remove the UDN PoP switch.  If this is desired then note that additional VLANs beyond the main data VLAN, each with special requirements may need to be handled — the UIS will supply a list of affected VLANs.
  • Which prefixes (both IPv4 and IPv6) the institution will want to advertise over the link.
  • If a temporary test prefix is required during setup (typically this would be the case if there are no spare ranges in the institution's existing connection).
  • If any other institutions are to be involved in the peering (e.g. an inter-institution backup link).
  • The timescale involved in deployment, including if certain prefixes will move at different times.

The UIS will then:

  • Determine which UDN routers will be at the UDN end of the links.
  • Allocate the institution UDN-wide private ASN.
  • Allocate the VLAN IDs and IP subnets for the link subnets (the latter determining the UDN- and institution-end peering addresses).
  • Register the UDN ends' IP addresses in the IP Register database.
  • Set up the peering on the UDN routers, in the shut down state and configured to reject all received prefixes but advertise all appropriate prefixes.

The institution should then set up its end of the peering in the shut down state, including registering the IP addresses of its routers in the IP Register database.

Activating the peering

To bring the peering online:

  1. The UIS will configure its end of the peering, accepting the initial prefixes (most likely one or more test prefixes and not any of the existing prefixes in service) and advertising the UDN and default routes.  The peerings will typically be presented as two VLANs on the existing PoP.
  2. The institution configures its end of the peering and advertises the test prefixes.
  3. At this point, the test prefix(es) should be live on the network and any appropriate tests can be done to verify routing, firewalling, failover, prioritisation, etc.
  4. When the institution is ready to route their prefixes via BGP, the UIS and institution will arrange a time to coordinate, within a short window (a few seconds):
    1. The UIS stops routing the prefixes to be moved, via the existing means (directly-routed, statically-routed, etc.) and drops the filter on the BGP connection, preventing those prefixes from being advertised.
    2. The institution advertises the prefixes via BGP.
  5. Once complete, the old VLAN or link will be shut down and can be removed from the network, if all the prefixes routed across it have been moved.

Step 4 can be repeated in stages, to migrate the various prefixes gradually.

In addition to the above, the institution will need to make any appropriate changes to its institutional network to handle the migration. In particular, if there will be a state where some traffic is going via the BGP link and some via an existing link, any firewall or routing changes to allow that to take place. This is the responsibility of the institution.

Prices

The BGP service incurs an installation cost and an annual charge and is alternative to the PoP charges:

 

Annual Charge

New Installation

Crossgrade Installation

BGP (2x 1G or 10G)

£3,694 £8,862 £552

Circuit relocation
(per link, one-off charge)

- £1,630 -

All prices are subject to VAT, where applicable.
Prices last updated 11th January 2023.

Last updated: 30th January 2023