CESNET2 Network BGP Design and Optimization

CESNET technical report 25/2010

Václav Novák

Received 2. 12. 2010

Other formats: PDF, EPUB

Abstract

The paper deals with the design and implementation of CESNET2 IP/MPLS backbone BGP routing topology and it's optimization. The current BGP routing design of CESNET2 backbone doesn't match the actual network architecture, topology and technology changes. This document will cover the main BGP protocol features (IPv4/IPv6 unicast and multicast families) currently operated by backbone routers. The main objectives are to improve CESNET2 network stability, iBGP protocol convergence time, simplify BGP configurations and increase network services availability for customer networks connected to CESNET2.

Keywords: routing, BGP, MPLS, DWDM, multicast, MSDP

1  Current CESNET2 BGP Network Design

The IP/MPLS CESNET2 network layer follows the optical transmission topology based on DWDM technology. In the core GigaPoPs (Praha, Brno, Olomouc and Hradec Králové)there are located ROADM nodes of the main DWDM ring together with the core P routers and edge PE routers of IP/MPLS network layer (P routers are marked as red, see Figure 1). In the other GigaPoPs we operates edge PE routers only (marked as blue). There are dual-connected to neighboring core P routers.

CESNET2 runs hybrid unicast IPv4/IPv6 using PE/6PE technology in dual-stack mode. The IPv4 and IPv6 multicast topologies are non-congruent with the IPv4 and IPv6 unicast ones (unicast packets are MPLS-switched whereas multicast ones is transported as pure IP). CESNET2 network supports EoMPLS and VPLS services as well.

The current CESNET2 physical topology is shown in Figure 1. The main GigaPoPs Praha and Brno are distributed into two locations in these cities (Praha I., Praha II., Brno I. and Brno II.). The typical backbone circuits capacity is 10 Gbps with intra-PoP 40 Gbps connections in Praha and Brno. There are 10GE LAN PHY used only, while the 40 Gbps connection is POS OC-768/STM-256. Jumbo frames MTU 9202 are configured and supported on all backbone interfaces. The most of core P and edge PE routers are Cisco OSR7609 and 7606 series which runs 12.2(33)SRE2 IOS version. In GigaPoPs Praha I. and Brno II. the new terabit routing systems Cisco CRS-1/16 supporting Secure Domain Routers (SDRs) technology have been installed. Using the SDR we divided single physical routing systems into multiple logical routers. There are core P and edge PE logical routers configured (core P routers R119 and R122 and edge PE routers R118 and R121). All CRS-1/16 logical routers runs IOS-XR version 3.8.1.

As the IGP routing protocol for the IP/MPLS core, CESNET uses OSPFv2 and OSFPv3 . The backbone traffic is controlled by OSPF metric assigned to backbone interfaces. Rapid/subsecond convergence of IP/MPLS core using the BFD (Bidirectional Forward Detection) protocol for OSPF/LDP sessions is implemented there.

[Image]

Figure 1. Current CESNET2 physical topology.

The IPv4 multicast is natively distributed within the IP/MPLS network topology. There are PIM-SM (PIM Sparse-mode) configured on all network interfaces. IPv4 multicast uses the Anycast RP (Rendezvous Point) concept with two RP configured on R115 and R98 routers. The RP IPv4 address prefix /32 is announced by the internal OSPF200 process. MSDP (Multicast Source Directory Protocol) is configured between both RP to announce registered multicast sources to these RP's. On all P and PE backbone routers there is iMGBP (internal Multiprotocol BGP) configured (BGP address-family ipv4 multicast section) to provide Unicast RPF (Reverse Path Forwarding) check for PIM messages. The internal backbone is default-free and there is no unicast IPv4 default-route send to core P routers (core P routers don't run IPv4/IPv6 unicast BGP). To ensure correct RPF check on edge PE routers we configured higher administrative distance for iMGBP. There is distance bgp 15 150 150 <external routes to AS, internal routes to AS, local routes> configured for the BGP address-family ipv4 multicast section to prefer multicast routes over BGP unicast routes for multicast sources.

IPv6 multicast is natively distributed as IPv4 multicast inside the IP/MPLS network topology. IPv6 multicast BGP sessions (BGP address-family ipv6 multicast) are configured between dedicated IPv6 loopback addresses of all core P and PE routers . IPv6 multicast topology uses embeded RP based on RFC 3956 [3].

1.1  Commodity IP connectivity

Commodity IPv4/IPv6 connectivity is provided by Telia IC upstream provider (AS 1299), see Figure 2. The main connection is 10GE (rate-limited to 3,6 Gbps on the Telia IC side) terminated on R118 internet peering router. The backup 10 Gbps connection to second Telia IC router is connected to R114 internet peering router. There is an AS prepend one times AS 2852 for CESNET2 outbound routes and local preference 50 for inbound routes. Telia IC announces global routing tables to CESNET2, e.g. about the 329 000 IPv4 BGP routes. They are exchanged between the internet peering routers R118 and R114 only and not distributed into the CESNET2 backbone. The full BGP internet routing between the internet peering routers R118 and R114 needs very good BGP protocol tuning for better routing convergence and stability. The IPV6 unicast connectivity is provided on the backup connection only. There are about 3 000 IPv6 unicast routes. The IPv6 backup unicast is provided by the connection to the GÉANT3 network.

The inbound routes are additionaly marked by BGP community 2852:111.

[Image]

Figure 2. CESNET2 external BGP routing and policy.

1.2  NIX.CZ peerings

Both R118 and R114 peerings routers run peerings with the NIX.CZ (Czech Internet Exchange Point). There are main and backup IPv4/IPv6 unicast BGP peers with each peering partner configured on these peering routers there. We have configured up to four BGP sessions with some IPS's (which operates two peering routers as well). MED is used to control inbound traffic and to load balance it between both NIX.CZ 10GE access lines. NIX.CZ peering with the following IPv4/IPv6 address 194.50.100.x/2001:7f8:14::x:y. Is being used The inbound routes are marked by BGP community 2852:666 and higher local-preference 150.

1.3  GÉANT3 connectivity

Currently, GÉANT3 (pan-European research network) connectivity is realized via the 10GE LAN PHY local connection on R115 peering router. There are IPv4/IPv6 unicast and multicast BGP sessions configured. Inbound routes are controlled by BGP community filters based on GÉANT3 community tagging (see RIPE, AS 20965). All GÉANT3 inbound routes are tagged with higher local-preference 150 to by preferred by CESNET2. The backup connection is terminated on the R118 peering router with lower local-preference 50.

1.4  TWAREN peering

Direct 1 Gbps connection to TWAREN (Taiwan research network) is terminated on the R115 peering router. This L2 connection is limited to 622 Mbps. There are BGP IPv4/IPv6 unicast and IPv6 multicast sessions configured. TWAREN inbound routes are tagged by BGP community 2852:888 and higher local-preference 150.

1.5  AMS-IX peering

The 1 Gbps direct connection to AMS-IX (Amsterdam Internet Exchange Point) terminates on R115 internet peering router. Inbound prefixes are tagged by higher local-preference 150 and BGP community 2852:777. There are BGP IPv4/IPv6 unicast sessions configured only.

1.6  CBF (Cross-Border Fiber) peerings

CESNET2 network operates CL DWDM (CzechLight technology) equipped optical lines to Austria (ACOnet NREN), Slovakia (Sanet NREN) and to Poland (Pionier NREN), see Figure 2. There are dedicated 10Gbps channels for peerings with these NRENs terminated on peering routers R98 in Brno and R96 in Ostrava. All the private peering participants share access to the national peering centers (NIX.CZ, VIX, SIX) as well via peering parners. CESNET2 network announce ACOnet, Sanet and Pionier IPv4/IPv6 BGP routes to NIX.CZ. CESNET2 routes are announced to VIX, Sanet and Pionier peering partners in Poland. To simplify routing policy we negotiated BGP community tagging for inbound prefixes:

Internal CESNET2 prefixes are tagged by the BGP community 2852:2852 and prefixes of other NRENs to be announced to NIX.CZ by an additional community 2852:1666. All the inbound prefixes from NRENs are tagged by higher local-preference 150. There are more BGP communities for Pionier peering, based on their private peerings in Poland. There is no Internet Exchange Point (IXP) in Poland instead to other countries.

1.7  CESNET2 internal BGP (iBGP) peering

CESNET2 network operates IPv4/IPv6 unicast and multicast iBGP (internal BGP) on all edge PE routers (see Figure 3). There are three independent RR's (route reflectors) with unique BGP cluster-id:

Other edge PE routers and P routers are configured as RRC's (route reflector clients). There is no redistribution from IGP processes to iBGP on edge PE routers. We use static network statements in BGP processes tagged with the community 2852:2852 only. There is no global routing tables announcement to the CESNET2 backbone. The internet peering routers R118 and R114 sends the default-route to internal neighbors (with different metric for backup). Inbound routes from other peerings are distributed to other edge PE routers.

CESNET2 has to announce the following AS 2852 prefixes to external peers: 78.128.128.0/17, 92.122.240.0/20, 146.102.0.0/16, 147.32.0.0/15, 147.228.0.0/14, 147.251.0.0/16, 158.194.0.0/16, 158.196.0.0/16, 160.216.0.0/16, 193.84.32.0/20, 193.84.160.0/20, 193.84.192.0/19, 195.113.0.0/16 and 195.178.64.0/19.

The most important university and metropolitan academic networks use private ASN's 65xxx assigned by CESNET2 and runs eBGP against CESNET2 routers. CESNET2 prefixes aggregations are generally provided by edge PE routers. Other prefixes are aggregated by internet peering routers R118, R114, R115, R98 and R96. Because of the prefix aggregations provided by the route reflectors, the more specific internal route towards the route reflector clients can be suppressed. It can invoke suboptimal routing, because packets can be forwarded first towards one of the aggregation routers. To solve this problem, we use “unsuppress-map” for the iBGP peers towards the route reflector clients.

[Image]

Figure 3. CESNET2 iBGP routing topology from R93 router perspective.

Figure 3 shows the CESNET2 routing topology and the RR's placement on peering routers from the R93 edge PE router perspective. There are some obsolete iBGP peers with other routers. The unification of iBGP peers is also needed. All the configured iBGP peers for IPv4/IPv6 unicast and multicast are summarized in Section A.1. Private IPv4 addresses and specified IPv6 addresses are shown there for documentation purposes based on RFC 3849 [1] only, not the really configured addresses. There is exception for iBGP peers with the R110 router, which operates as RTBH (Remotely Triggered Black Filtering) router. The peers with this router have configured different peer-session and peer-policy. RR's accepts the routes from the trigger, but didn't send any prefixes towards to RTBH. We use the RTBH for IPv4 only, because there is no IPv6 RPF support in HW for 7600 series routers, which CESNET2 network operates. When we configure IPv6 RPF in SW on this platform, there is a high risk to switch all IPv6 packet by SW only and thus overload most of backbone routers.

2  CESNET2 iBGP optimization

The current assignment of the route reflector functionality to the internet peering routers within the CESNET2 iBGP network architecture is not satisfactory today. The routers CPU performance isn't enough to fast converge eBGP and iBGP routing tables. There is especially the lack of CPU performance of the Cisco 7609 routers (R114 and R98) which are heavily loaded by traffic forwarding and NetFlow v9 exports. The BGP routing tables convergence time is usually up to 4 minutes, which is very long time for overall network convergence.

There may be an improvement to separate the forwarding and control planes by installing dedicated routers with the CPU's for iBGP route-reflection functions. These routers will not forward any users traffic, so their CPU's will not be overloaded by forwarding. The advantage of this solution is better scalability, performance and stability. There will be also separated eBGP and iBGP routing policies and more transparent BGP routers configurations (peer templates, route-policy templates and others). To have sufficient redundancy we planned to install two independent route reflector routers in the main GigaPoPs Praha and Brno, see Figure 4. They are placed on R124 in Brno II. and R125 in Praha I. (marked as yellow) and dual-connected to core P routers. The route reflectors are modular Cisco ASR1002 routers with the ESP-5G CPU's and 1GE network interfaces. This platform could be extended by 10GE interfaces when needed and can be upgraded to more powerful CPUs as well. It runs IOS version 12.2(33) XNE2.

[Image]

Figure 4. CESNET2 dedicated route reflectors.

A common question was whether different or identical BGP cluster-id's should be configured on each route reflector. For redundancy, configuration and operational management reasons we preferred an unique cluster-id per route reflector, e.g. cluster-id 11 for RR1 and cluster-id 12 for RR2. The generic BGP configuration is:

!
router bgp 2852
 bgp router-id 10.205.8.5
 no bgp default ipv4-unicast
 bgp cluster-id 11
 bgp log-neighbor-changes
 bgp deterministic-med
 bgp update-delay 240
 bgp graceful-restart restart-time 120
 bgp graceful-restart stalepath-time 360
 bgp graceful-restart
 bgp bestpath med missing-as-worst
!

For route reflectors RR we have configured peer-sessions and peer-templates:

For route reflector clients RRC we have configured peer-sessions and peer-templates:

The peer-session and peer-policy configuration example is here:

!
router bgp 2852
 template peer-policy IPv4-RRC
  route-reflector-client
  advertisement-interval 0
  soft-reconfiguration inbound
  send-community both
 exit-peer-policy
!
!
 template peer-session IPv4-default
  remote-as 2852
  password 7 123F094F5....804...3D7034
  update-source Loopback0
  timers 10 30
 exit-peer-session
 !

The detailed tables of peer-sessions and peer-policy assignments for route reflector configurations are shown in Section A.2 and A.3.

To improve scalability and BGP convergence we modified both TCP window and input queue sizes together with enabling path MTU discovery:

The configuration on the route reflectors is here:

!
ip tcp window-size 65535
ip tcp path-mtu-discovery
!
interface GigabitEthernet0/0/0
 description R119
 hold-queue 1500 in
!

Current IP MTU being used for BGP TCP session is here:

!
R125-prg-RR1#sh bgp ipv4 uni neighbors | incl max data
Datagrams (max data segment is 9138 bytes):
Datagrams (max data segment is 9138 bytes):
Datagrams (max data segment is 9138 bytes):
<deleted>

Several BGP timers can be used to tune the BGP convergence:

IBGP TimersDefault ValuesConfigured Values
Advertisement-interval5 sec0 sec
Keepalive60 sec10 sec
Holdtime180 sec30 sec
Scan-time60 sec60 sec

Table 1. iBGP timers setting.

We reduced all these timers except Scan-time, because it's reduction could cause excessive CPU utilization of routing-reflector.

Next one parameter to be tuned is BGP update delay. The BGP process has 2 main operating modes:

The BGP update-delay timer is the time between the first BGP peer coming up and the BGP process transition from RO to RW mode. By default this timer is set to 120 sec. To avoid the suboptimal routing when update are send before all BGP peers are up this timer needed to be tuned a larger value. We configured this timer to 240 sec., because peering routers takes more than 120 sec. to converge after first peer up.

3  Conclusion

The dedicated routers with the route reflectors functionality deployment improved the iBGP routing performance, stability and scalability. Two independent route reflectors are sufficient for redundacy.

We also tuned the TCP parameters of iBGP sessions and basic iBGP timers to have better convergence time. There are more parameters and BGP protocol options to be improved based on its implementation in running versions of IOS or IOS-XR software. One of them is BFD (Bidirectional Forwarding Detection) for BGP protocol. This BGP protocol enhancement wasn't possible implement, because the current version of IOS-XR doesn't support it. We also plane to use it after IOS-XR after upgrades in future.

References

[1] HUSTON, G.; LORD, A.; SMITH, P. IPv6 Address Prefix Reserved for Documentation. RFC 3849, IETF, July 2004.
[2] NOVÁK, V; ADAMEC, P. CESNET2 Network Deployment. In LHOTKA, L.; SATRAPA, P. (ed.). Networking Studies: Selected Technical Reports. Praha: CESNET, 2007, p. 3–14. ISBN 978-80-239-9285-4.
[3] SAVOLA, P.; HABERMAN, B. Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. RFC 3849, IETF, July 2004.

Appendix A  Route Reflector Configuration Summary

A.1  Internal BGP peerings

RouterLoopbackLoopbackIPv4 peerIPv4 peerIPv6 peerIPv6 peer
IPV4IPv6unicastmulticastunicastmulticast
R8410.202.8.3 2001:DB8::4:84 R118, R115, R98 R118, R115, R98R115, R98R118, R115, R98
R9210.202.8.62001:DB8::4:92 R118, R115, R98 R118, R115, R98 R115, R98R118, R115, R98
R9310.202.8.7 2001:DB8::4:93 R118, R115, R98 R118, R115, R98 R115, R98R118, R115, R98
R9410.202.8.9 2001:DB8::4:94 R118, R115, R98 R118, R115, R98 R115, R98R118, R115, R98
R9510.202.8.11 2001:DB8::4:95 R118, R115, R98 R118, R115, R98 R115, R98R118, R115, R98
R9610.202.8.212001:DB8::4:96 R118, R115, R98 R118, R115, R98 R115, R98R118, R115, R98
R9710.202.8.192001:DB8::4:97 R118, R115, R98 R118, R115, R98 R115, R98R118, R115, R98
R9810.202.8.262001:DB8::4:98 N/A – RR3, R115R118, R115R115R118, R115
R9910.202.8.132001:DB8::4:99 R118, R115, R98R118, R115, R98R115, R98R118, R115, R98
R10010.202.8.15 2001:DB8::4:100 R118, R115, R98R118, R115R115, R98R118, R115, R98
R10710.202.8.12001:DB8::4:107N/A – PR118, R115, R98N/A – PR118, R115, R98
R10810.202.8.10 2001:DB8::4:108N/A – PR118, R115, R98N/A – PR118, R115, R98
R10910.202.8.202001:DB8::4:109N/A – PR118, R115, R98N/A – PR118, R115, R98
R11010.205.8.32001:DB8::4:110R118, R115, R98N/A – RTBHN/A – RTBHN/A – RTBH
R11110.205.8.47 2001:DB8::4:111R118, R115, R98R118, R115, R98R115, R98R118, R115, R98
R11210.202.8.52001:DB8::4:112R118, R115, R98R118, R115, R98R115, R98R118, R115, R98
R11310.202.8.22 2001:DB8::4:113R118, R115, R98R118, R115R115, R98
R11410.202.8.82001:DB8::4:114R118, R115, R98R118, R115, R98R115, R98R118, R115, R98
R11510.202.8.4 2001:DB8::4:115R118, R115, R98N/A – RR2, R98R98R118, R115, R98
R11610.205.8.28 2001:DB8::4:116R118, R115, R98R118, R115, R98R115, R98
R11710.202.8.122001:DB8::4:117R118, R115, R98R118, R115, R98R115, R98R118, R98
R11810.202.8.162001:DB8::4:118N/A – RR1, R115, R98N/A – RR1, R98R115, R98R118, R115, R98
R11910.202.8.172001:DB8::4:119N/A – PR118, R115, R98N/A – PR118, R115, R98
R12110.202.8.242001:DB8::4:121N/A – PR118N/A – PR118
R12210.202.8.252001:DB8::4:122R118R118, R115, R98R118, R115

A.2  Address Family and Peer Sessions

RouterNeighbor IPAF IPv4AF IPv6P/PEInternetTemplate
ucastmcastucastmcastpeering
R11010.205.8.3ynnnRTBHIPv4-default
R11610.205.8.28yyynPEIPv4-default
R11110.205.8.47yyynPEIPv4-default
R8410.202.8.3yyynPEIPv4-default
R11510.202.8.4yyynPEyIPv4-default
R11210.202.8.5yyynPEIPv4-default
R9210.202.8.6yyynPEIPv4-default
R9310.202.8.7yyynPEIPv4-default
R11410.202.8.8yyynPEyIPv4-default
R9410.202.8.9yyynPEIPv4-default
R9510.202.8.11yyynPEIPv4-default
R11710.202.8.12yyynPEIPv4-default
R9910.202.8.13yyynPEIPv4-default
R10010.202.8.15yyynPEIPv4-default
R11810.202.8.16yyynPEyIPv4-default
R9710.202.8.19yyynPEIPv4-default
R9610.202.8.21yyynPEyIPv4-default
R11310.202.8.22yyynPEIPv4-default
R12110.202.8.24yyynPEIPv4-default
R9810.202.8.26yyynPEyIPv4-default
R10710.202.8.1ynPIPv4-default
R10810.202.8.10ynPIPv4-default
R11910.202.8.17ynPIPv4-default
R10910.202.8.20ynPIPv4-default
R12210.202.8.25ynPIPv4-default
R842001:DB8::4:84 nyPEIPv6-default
R1152001:DB8::4:85nyPEyIPv6-default
R922001:DB8::4:92nyPEIPv6-default
R932001:DB8::4:93 nyPEIPv6-default
R942001:DB8::4:94 nyPEIPv6-default
R952001:DB8::4:95 nyPEIPv6-default
R962001:DB8::4:96 nyPEyIPv6-default
R972001:DB8::4:97 nyPEIPv6-default
R982001:DB8::4:98 nyPEyIPv6-default
R992001:DB8::4:99 nyPEIPv6-default
R1002001:DB8::4:100 nyPEIPv6-default
R1072001:DB8::4:107nyPIPv6-default
R1082001:DB8::4:108nyPIPv6-default
R1092001:DB8::4:109nyPIPv6-default
R1112001:DB8::4:111nyPEIPv6-default
R1122001:DB8::4:112nyPEIPv6-default
R1132001:DB8::4:113nyPEIPv6-default
R1142001:DB8::4:114nyPEyIPv6-default
R1162001:DB8::4:116nyPEIPv6-default
R1172001:DB8::4:117nyPEIPv6-default
R1182001:DB8::4:118nyPEyIPv6-default
R1192001:DB8::4:119nyPIPv6-default
R1212001:DB8::4:121nyPEIPv6-default
R1222001:DB8::4:122nyPIPv6-default

A.3  Peer Templates Summary

RouterNeighbor IPIPv4 templateIPv4 templateP/PEInternet
unicastmulticastunicastmulticastpeering
R11010.205.8.3IPv4-RTBHN/AN/AN/ARTBH
R11610.205.8.28IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R11110.205.8.47IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R8410.202.8.3IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R11510.202.8.4IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APEy
R11210.202.8.5IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R9210.202.8.6IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R9310.202.8.7IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R11410.202.8.8IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APEy
R9410.202.8.9IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R9510.202.8.11IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R11710.202.8.12IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R9910.202.8.13IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R10010.202.8.15IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R11810.202.8.16IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APEy
R9710.202.8.19IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R9610.202.8.21IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APEy
R11310.202.8.22IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R12110.202.8.24IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APE
R9810.202.8.26IPv4-RRCIPv4-RRC-MCIPV6-RRCN/APEy
R10710.202.8.1IPv4-RRCIPv4-RRC-MCIPV6-RRCN/AP
R10810.202.8.10N/AIPv4-RRC-MCN/AN/AP
R11910.202.8.17N/AIPv4-RRC-MCN/AN/AP
R10910.202.8.20N/AIPv4-RRC-MCN/AN/AP
R12210.202.8.25N/AIPv4-RRC-MCN/AN/AP
R842001:DB8::4:84 N/AN/AN/AIPv6-MC-RRCPE
R1152001:DB8::4:85N/AN/AN/AIPv6-MC-RRCPEy
R922001:DB8::4:92N/AN/AN/AIPv6-MC-RRCPE
R932001:DB8::4:93 N/AN/AN/AIPv6-MC-RRCPE
R942001:DB8::4:94 N/AN/AN/AIPv6-MC-RRCPE
R952001:DB8::4:95 N/AN/AN/AIPv6-MC-RRCPE
R962001:DB8::4:96 N/AN/AN/AIPv6-MC-RRCPEy
R972001:DB8::4:97 N/AN/AN/AIPv6-MC-RRCPE
R982001:DB8::4:98 N/AN/AN/AIPv6-MC-RRCPEy
R992001:DB8::4:99 N/AN/AN/AIPv6-MC-RRCPE
R1002001:DB8::4:100 N/AN/AN/AIPv6-MC-RRCPE
R1072001:DB8::4:107N/AN/AN/AIPv6-MC-RRCP
R1082001:DB8::4:108N/AN/AN/AIPv6-MC-RRCP
R1092001:DB8::4:109N/AN/AN/AIPv6-MC-RRCP
R1112001:DB8::4:111IPv6-MC-RRCPE
R1122001:DB8::4:112IPv6-MC-RRCPE
R1132001:DB8::4:113IPv6-MC-RRCPE
R1142001:DB8::4:114IPv6-MC-RRCPEy
R1162001:DB8::4:116IPv6-MC-RRCPE
R1172001:DB8::4:117IPv6-MC-RRCPE
R1182001:DB8::4:118IPv6-MC-RRCPEy
R1192001:DB8::4:119IPv6-MC-RRCP
R1212001:DB8::4:121PE
R1222001:DB8::4:122nyP
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz