IPv4 Network Configuration
| IPv4 Subnetwork Address | Broadcast Address | |
|---|---|---|
| Vlans Oeiras | ||
| EmpA2 | 192.168.1.248/30 | 192.168.1.251/30 |
| EmpB2 | 192.168.1.252/30 | 192.168.1.255/30 |
| Datacenters | ||
| Datacenter Lisboa | 10.2.128.0/17 | 10.2.128.255/17 |
| Datacenter Oeiras | 10.2.0.0/18 | 10.2.63.255/18 |
| Datacenter Aveiro | 10.2.64.0/18 | 10.2.127.255/18 |
| P2P networks | ||
| Aveiro <-> EmpA1 | 10.0.128.0/30 | 10.0.128.3/30 |
| Aveiro <-> EmpB1 | 10.0.128.4/30 | 10.0.128.7/30 |
| Lisboa <-> Oeiras | 10.0.128.8/30 | 10.0.128.11/30 |
| Oeiras <-> EmpC | 10.0.128.16/30 | 10.0.128.19/30 |
| Ethernet Core | 10.0.0.0/17 | 10.0.127.255/17 |
| netD1 | 192.168.1.0/25 | 192.168.1.255/25 |
| Corporates | ||
| Corporate Client A1 | 110.1.1.0/25 | 110.1.1.127/25 |
| Corporate Client A2 | 110.1.1.128/25 | 110.1.1.255/25 |
| Corporate Client B1 | 111.1.1.0/25 | 111.1.1.127/25 |
| Corporate Client B2 | 111.1.1.128/25 | 111.1.1.255/25 |
| Corporate Client C | 112.1.1.0/24 | 112.1.1.255/24 |
| ISP-PT2 AS40000 | --------------- | --------------- |
| netL1 | 65.0.1.0/24 | 65.0.1.255/24 |
| ISP-ES AS20000 | --------------- | --------------- |
| netM1 | 190.100.1.0/24 | 190.100.1.255/24 |
| netM2 | 190.200.1.0/24 | 190.200.1.255/24 |
| Internet Core | --------------- | --------------- |
| Internet Core | 2.2.2.0/24 | 2.2.2.255/24 |
| External BGP peering links | --------------- | --------------- |
| Madrid <-> Lisboa2 | 5.4.4.0/30 | 5.4.4.3/30 |
| Madrid <-> Porto | 5.4.4.4/30 | 5.4.4.7/30 |
| Lisboa1 <-> Lisboa2 | 5.4.4.8/30 | 5.4.4.11/30 |
| Lisboa1 <-> Madrid | 5.4.4.12/30 | 5.4.4.15/30 |
| Routers | IPv4 Address |
|---|---|
| EmpB1 | 192.168.2.1/32 |
| Aveiro | 192.168.2.2/32 |
| Lisboa2 | 192.168.2.3/32 |
| Oeiras | 192.168.2.4/32 |
| EmpA1 | 192.168.2.5/32 |
| Porto | 192.168.2.6/32 |
| EmpA2 | 192.168.2.7/32 |
| EmpB2 | 192.168.2.8/32 |
| EmpC | 192.168.2.9/32 |
The network core of the ISP-PT2 runs:
- BGP: to maintain a (large) database of routes to all networks, which enables the ISP to route the received packets accordingly
- OSPF: used to support the creation of MPLS LSPs (Label-Switched Paths) inside the core. The OSPF process used has the ID=1 and it will not have any knowledge about routes to external networks. The datacenter networks are the only exception where they will be connected to the ISP and running the same OSPF process.
ISP-PT2 connects with external ASs and private ASs using eBGP and inside the network core runs iBGP. ISP-PT2 is a multi-homed transit AS so it routes traffic from external ASs (20000 and 40000 in this case).
Because the ISP-PT2 network core only has 4 routers, an iBGP full mesh can be used. For larger BGP networks route reflectors are used to avoid an iBGP full mesh.
Private AS
The AS65400 is a private AS. This means that the AS number 65400 of all route updates, that originate from AS65400, sent to external ASs has to be removed from the AS-PATH attribute. The private AS number remains in the route updates inside the providers network, only being removed by the ASBRs connected to external ASs. The following command was used in the routers Lisboa2 and Porto:
neighbor <interface-ip> remove-private-as all
Client networks
The connections between the client networks and the ISP-PT2 run OSPF, with each having a different process id from the network core:
- Corporate A has OSPF process 2
- Corporate B has OSPF process 3
Each OSPF process is then redistributed to BGP, on the ASBRs, for it to learn the routes towards the client networks.
The clients have a default route towards the providers edge router in order to communicate with external networks.
Network netD
This network is used to connected multiple clients to the same router interface of the providers edge router. To run an OSPF process for each client in the same interface, sub-interfaces needed to be created along with the correspondent vlans:
- f1/0.2: 192.168.1.249, vlan 2 (for EmpA2)
- f1/0.3: 192.168.1.253, vlan 3 (for EmpB2)
!! sub-interface for EmpA2, vlan 2
Oeiras(config)# int f1/0.2
Oeiras(config)# encapsulation dot1Q 2
Oeiras(config)# ip address 192.168.1.249 255.255.255.252
!! sub-interface for EmpB2, vlan 3
Oeiras(config)# int f1/0.3
Oeiras(config)# encapsulation dot1Q 3
Oeiras(config)# ip address 192.168.1.253 255.255.255.252
MP-BGP routing constraints
a) IP traffic towards the Internet should be always routed via ISP-PT1
For the traffic towards the Internet Core to be routed via ISP-PT1, the Local Preference attribute was used along with a route-map. This attribute allows the configuration of a prefered exit of traffic leaving the the current AS and the route-maps performs filtering in order to only apply the local preference to routes with destination in the Internet Core.
Lisboa2(config)# ip prefix-list internet-destination seq 10 permit 2.2.2.0/24
Lisboa2(config)# route-map route-through-lisboa2 permit 10
Lisboa2(config-route-map)# match ip address prefix-list internet-destination
Lisboa2(config-route-map)# set local-preference 200
!! empty clause
Lisboa2(config)# route-map route-through-lisboa2 permit 20
Lisboa2(config)# router bgp 1000
Lisboa2(config-router)# address-family ipv4 unicast
Lisboa2(config-router-af)# neighbor 5.4.4.9 route-map route-through-lisboa2 in
Every route being advertised by Lisboa2 router that is towards the Internet Core will have local preference 200. The local preference is shared between all iBGP peers (the EmpC router won't receive this local preference value in the route updates because it runs eBGP with the ISP-PT2). This way when routes to the Internet Core are analysed by the iBGP routers, the ones with the next-hop to Lisboa2 are going to be prefered:
Porto#show ip bgp
BGP table version is 31, local router ID is 192.168.2.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i2.2.2.0/24 192.168.2.3 0 200 0 40000 i
* 5.4.4.5 0 0 20000 i
(...)
The same procedure was used to accomplish the requirements b1) and b2).
b1) IP traffic towards all AS20000 networks, should be preferably routed via Lisboa2 from Oeiras
Oeiras(config)# ip prefix-list as20000-destination seq 10 permit 190.100.1.0/24
Oeiras(config)# ip prefix-list as20000-destination seq 20 permit 190.200.1.0/24
!! Route-map to send traffic through porto
Oeiras(config)# route-map route-through-lisboa2 permit 10
Oeiras(config-route-map)# match ip address prefix-list as20000-destination
!! default local preference is 100
Oeiras(config-route-map)# set local-preference 110
Oeiras(config)# route-map route-through-lisboa2 permit 20
!! Update neighbor relationships with the route-map
Oeiras(config)# router bgp 1000
Oeiras(config-router)# address-family ipv4 unicast
Oeiras(config-router-af)# neighbor 192.168.2.3 route-map route-through-lisboa2 in
b2) IP traffic towards all AS20000 networks, should be preferably routed via Porto from Aveiro
Aveiro(config)# ip prefix-list as20000-destination seq 10 permit 190.100.1.0/24
Aveiro(config)# ip prefix-list as20000-destination seq 20 permit 190.200.1.0/24
!! Route-map to send traffic through porto
Aveiro(config)# route-map route-through-porto permit 10
Aveiro(config-route-map)# match ip address prefix-list as20000-destination
!! default local preference is 100, so a bigger number needs to be specified
Aveiro(config-route-map)# set local-preference 110
Aveiro(config)# route-map route-through-porto permit 20
!! Update neighbor relationships with the route-map
Aveiro(config)# router bgp 1000
Aveiro(config-router)# address-family ipv4 unicast
Aveiro(config-router-af)# neighbor 192.168.2.6 route-map route-through-porto in
c) IP traffic for remote SIP proxy 2 (to network netL1) must be routed via Porto using the direct peering link to ISP ES
To send traffic from SIP Proxy 2 network to netL1 according to the requirement, policy-based routing was used. It's applied to the packets received by Lisboa2 router (interface f2/0), that come from the SIP Proxy 2 network and destined to netL1.
!! extended ACL used for specifying the destination address
Lisboa2(config)# ip access-list extended 101
Lisboa2(config-ext-nacl)# permit ip 112.1.1.0 0.0.0.255 65.0.1.0 0.0.0.255
Lisboa2(config)# route-map SIP2-to-netL1-through-Porto permit 10
Lisboa2(config-route-map)# match ip address 101
!set ip next-hop 192.168.2.6
Lisboa2(config-route-map)# set ip next-hop 10.0.0.2
Lisboa2(config)# route-map SIP2-to-netL1-through-Porto permit 20
!! apply route-map to the interface where the packets from the SIP proxy 2 network are received
Lisboa2(config)# int f2/0
Lisboa2(config-if)# ip policy route-map SIP2-to-netL1-through-Porto
The Porto router also needs to be configured to prevent the traffic from going back to the Lisboa2 router:
Porto(config)# ip access-list extended 101
Porto(config-ext-nacl)#permit ip 112.1.1.0 0.0.0.255 65.0.1.0 0.0.0.255
Porto(config)# route-map SIP2-to-netL1-through-Porto permit 10
Porto(config-route-map)# match ip address 101
Porto(config-route-map)# set ip next-hop 5.4.4.5
Porto(config)# route-map SIP2-to-netL1-through-Porto permit 20
!! apply route-map to the interface where the packets from the SIP proxy 2 network are received
Porto(config)# int f1/1
Porto(config-if)# ip policy route-map SIP2-to-netL1-through-Porto
d) Packets from AS65400 should be routed to the Internet as generic, but should be routed via Lisbon2 to reach netM1
The packets from AS65400 should not have a specific path towards the Internet but they should be routed via Lisbon2 to reach netM1.
Lisboa2(config)# ip access-list extended 102
Lisboa2(config-ext-nacl)# permit ip 112.1.1.0 0.0.0.255 190.100.1.0 0.0.0.255
Lisboa2(config)# route-map AS65400-to-netM1-through-Lisboa2 permit 10
Lisboa2(config-route-map)# match ip address 102
Lisboa2(config-route-map)# set ip next-hop 5.4.4.9
Lisboa2(config)# route-map AS65400-to-netM1-through-Lisboa2 permit 20
Lisboa2(config)# int f2/0
Lisboa2(config-if)# ip policy route-map AS65400-to-netM1-through-Lisboa2
In order to apply both route-maps, from c) and d), to the same interface of the router Lisboa2, both need to be merged into a single route-map:
!! SIP proxy 2 network to netL1
Lisboa2(config)# route-map AS65400-routemap permit 10
Lisboa2(config-route-map)# match ip address 101
Lisboa2(config-route-map)# set ip next-hop 10.0.0.2
!! AS 65400 to netM1
Lisboa2(config)# route-map AS65400-routemap permit 20
Lisboa2(config-route-map)# match ip address 102
Lisboa2(config-route-map)# set ip next-hop 5.4.4.9
Lisboa2(config)# route-map AS65400-routemap permit 30
Lisboa2(config)# int f2/0
Lisboa2(config-if)# ip policy route-map AS65400-routemap
a) External AS transit traffic should be routed (between Lisboa2 and Porto) over a MPLS tunnel, with reserved bandwidth of 30Mbps
To enable MPLS traffic-engineering on a router, the following command needs to be entered in global configuration mode:
Lisboa2(config)# mpls traffic-eng tunnels
To enable the MPLS TE features in OSPF:
!! activate mpls-te on the process running in the core
Lisboa2(config)# router ospf 1
Lisboa2(config-router)# mpls traffic-eng area 0
Lisboa2(config-router)# mpls traffic-eng router-id Loopback 0
To support MPLS traffic engineering the label distribution protocol RSVP-TE was chosen. This protocol runs inside the network core and is configured on the interfaces connected to the core:
!! interface connected to the core
Lisboa2(config)# int f1/1
!! interface configured for MPLS TE
Lisboa2(config-if)# mpls traffic-eng tunnels
!! bandwidth on the interface that can be used by MPLS TE tunnels: 100 Mbps = 100000kbps (reverved to RSVP)
Lisboa2(config-if)# ip rsvp bandwidth 100000 100000
!! interface connected to Oeiras
Lisboa2(config)# int f2/1
!! interface configured for MPLS TE
Lisboa2(config-if)# mpls traffic-eng tunnels
Lisboa2(config-if)# ip rsvp bandwidth 100000 100000
Configuration of a static tunnel between Lisboa2 and Porto:
Lisboa2(config)# int tunnel 1
Lisboa2(config-if)# ip unnumbered Loopback0
!! loopback interface of Poroto router
Lisboa2(config-if)# tunnel destination 192.168.2.6
Lisboa2(config-if)# tunnel mode mpls traffic-eng
!! bandwidth reserved for the mpls tunnel
Lisboa2(config-if)# tunnel mpls traffic-eng bandwidth 30000 ! 30Mbps
Lisboa2(config-if)# tunnel mpls traffic-eng path-option 1 explicit name path1
Configuration of an explicit path to tunnel 1:
Lisboa2(config)# ip explicit-path name path1 enable
Lisboa2(cfg-ip-expl-path)# next-address 10.0.0.2
Creation of route-maps to send traffic destined to netM1 and netM2 towards the tunnel 1:
!! netL1 to netM1
Lisboa2(config)# ip access-list extended 103
Lisboa2(config-ext-nacl)# permit ip 65.0.1.0 0.0.0.255 190.100.1.0 0.0.0.255
!! netL1 to netM2
Lisboa2(config)# ip access-list extended 104
Lisboa2(config-ext-nacl)# permit ip 65.0.1.0 0.0.0.255 190.200.1.0 0.0.0.255
Lisboa2(config)# route-map external-AS-through-tunnel1 permit 10
Lisboa2(config-route-map)# match ip address 103
Lisboa2(config-route-map)# set default interface Tunnel1
Lisboa2(config)# route-map external-AS-through-tunnel1 permit 20
Lisboa2(config-route-map)# match ip address 104
Lisboa2(config-route-map)# set default interface Tunnel1
Lisboa2(config)# route-map external-AS-through-tunnel1 permit 30
!! apply route map to the interface that connects to the external AS
Lisboa2(config)# int f1/0
Lisboa2(config-if)# ip policy route-map external-AS-through-tunnel1
To ping aracdn.com, a DNS server has to be configured. However because we also need to provide redirection of traffic according to the geographic location, the DNS server will also serve as the CDN server (it is a geographically aware DNS server for CDN deployment). To implement these features, a Virtual Machine was added to the Datacenter Aveiro network (running Ubuntu 12.04 Server i386).
Configuration of a static IP address and default gateway in the file /etc/network/interfaces:
(...)
## the eth0 lines were commented
auto eth1
iface eth1 inet static
address 10.2.64.10
netmask 255.255.192.0
gateway 10.2.64.1
For DNS and CDN redirection, the bind9 service was used and several files in the path /etc/bind/ needed to be created and configured:
- the file aracdn.com-aveiro.db
$TTL 604800
$ORIGIN aracdn.com.
@ IN SOA nsl.aracdn.com. adm.aracdn.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS nsl.aracdn.com.
IN A 10.2.64.10
nsl IN A 10.2.64.10
- the file aracdn.com-lisboa.db
$TTL 604800
$ORIGIN aracdn.com.
@ IN SOA nsl.aracdn.com. adm.aracdn.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS nsl.aracdn.com.
IN A 10.2.128.2
nsl IN A 10.2.64.10
- the file aracdn.com-oeiras.db
$TTL 604800
$ORIGIN aracdn.com.
@ IN SOA nsl.aracdn.com. adm.aracdn.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS nsl.aracdn.com.
IN A 10.2.0.2
nsl IN A 10.2.64.10
- the following lines were added to the file named.conf.local
view "aveiro" {
match-clients{110.1.1.0/25; 111.1.1.0/25;};
allow-recursion{any;};
zone "aracdn.com"{
type master;
file "/etc/bind/aracdn.com-aveiro.db";
};
};
view "oeiras"{
match-clients{110.1.1.128/25; 111.1.1.128/25; 112.1.1.0/24;};
allow-recursion{any;};
zone "aracdn.com"{
type master;
file "/etc/bind/aracdn.com-oeiras.db";
};
};
view "lisboa"{
match-clients{any;};
allow-recursion{any;};
zone "aracdn.com"{
type master;
file "/etc/bind/aracdn.com-lisboa.db";
};
};
- and the following line was commented in the file named.conf
## include "/etc/bind/named.conf.default-zones";
To test the configurations of the 3 added files, the following commands are used (in the VM terminal):
CDNserver$ named-checkzone aracdn.com aracdn.com-aveiro.db
CDNserver$ named-checkzone aracdn.com aracdn.com-lisboa.db
CDNserver$ named-checkzone aracdn.com aracdn.com-oeiras.db
Finally the bind9 service is restarted:
CDNserver$ service bind9 restart