Transcript MelbWireless: Network Design Thoughts v0.1

Routing & Addressing
Routing and Addressing Working Group.
© 2002 Roger Venning <[email protected]>
Permission to use or modify readily granted.
Version 0.12
1
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Contents
• Introduction to Routing
•
•
•
•
•
•
•
•
2
Network Design Templates
WAN routing overview
WAN addressing
Multicast
Network peering
IPv6
Distributed Web Caching
Internal peer-to-peer file sharing
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Another time
Introduction to Routing
3
•
•
•
•
Internet Protocol
Forwarding process
Types of routes
Routing protocols
•
Good notes at
http://www.erg.abdn.ac.uk/users/gorry/eg3561/syllabus.html
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Internet Protocol
• IPv4 has been
around since 1981,
standardised in
Arpanet RFCs
• Specifies a packet
switched network
protocol
• TCP, UDP, etc.
layer over the top
of the fundamental
IP datagram
4
http://www.erg.abdn.ac.uk/users/gorry/eg3561/inet-pages/ip-packet.html
(C) 2002 Roger Venning <[email protected]>
http://ntrg.cs.tcd.ie/undergrad/4ba2/ipng/gerd.ipv4.html
permission to modify / use readily granted
Networks and Netmasks
• A ‘network’ here is a group of hosts that have
layer two (switched) access, and are given the
addresses beginning with the same sequence of
bits
• The ‘netmask’ specifies how many bits are the
same
• At first IP was ‘classful’, separated into A, B, C, D
class space, each space had given netmask.
– Inefficient allocation led to fears of exhaustion…
• Two measures to address inefficiency
– Next came Variable Length Subnetting (VLSM)
– Then Classless Internet Domain Routing (CIDR)
5
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
How to check if a IP is in a network
0 0 0 1 0 1 1 0 1 1 0 1 1 1 0 1 1 1 1 0 1 1 0 0 1 1 0 0 1 1 0 1
IP
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
Mask
0 0 0 1 0 1 1 0 1 1 0 1 1 1 0 1 1 1 1 0 1 1 0 0 0 0 0 0 0 0 0 0
& result
0 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
<> Network
Or more simply:
22.221.236.205 does not fall in network 22.255.255.0/24
Netmask can also be specified in dotted quad, like 255.255.255.0
6
/32 255.255.255.255
/24 255.255.255.0
/16 255.255.0.0
/8 255.0.0.0
/31 255.255.255.254
/23 255.255.254.0
/15 255.254.0.0
/7 254.0.0.0
/30 255.255.255.252
/22 255.255.252.0
/14 255.252.0.0
/6 252.0.0.0
/29 255.255.255.248
/21 255.255.248.0
/13 255.248.0.0
/5 248..0.0
/28 255.255.255.240
/20 255.255.240.0
/12 255.240.0.0
/4 240.0.0.0
/27 255.255.255.224
/19 255.255.224.0
/11 255.224.0.0
/3 224.0.0.0
/26 255.255.255.196
/18 255.255.196.0
/10 255.196.0.0
/2 196.0.,0.0
/25 255.255.255.128
/17 255.255.128.0
/9 255.128.0.0
/1 128.0.0.0
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
/0 0.0.0.0
Packet Switching IP
• Packets need to get the to the destination
– Check the destination address
– Make a selection of the next hop to the final endpoint
based on this address
– The last hop is ‘connected’, so is sent directly to the host
• Solution: routing tables
– Groups of addresses and associated next hops
– “Groups” defined in terms of a ‘network’, now specified
through a network part and a netmask, e.g. 10.0.0.0/24
• Netmask also represented as dotted quad, e.g.
255.255.255.0 is /24
• Specifies number of bits that are must be the same in the
first part of two addresses for them to be from the same
network
7
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
An example routing table
172.16.80.5 via 10.10.0.34 dev eth0
203.220.79.17 dev ppp0 proto kernel scope link
10.10.0.48/29 dev eth1 proto kernel scope link
10.10.0.32/28 dev eth0 scope link
172.16.80.0/20 via 10.10.0.34 dev eth0
10.10.0.0/16 via 10.10.0.34 dev eth0
127.0.0.0/8 dev lo scope link
default via 203.220.79.17 dev ppp0
src 203.221.40.103
src 10.10.0.49
• A packet to 172.16.80.21 has (at least) the first
20 bits the same as 172.16.80.0/20, so
172.16.80.0/20 matches
• This route is the most specific match (although if
the destination was 172.16.80.5 it wouldn’t be…)
• So a packet to 172.16.80.21 would be sent via
10.10.0.34
– Must know how to get to 10.10.0.34… via connected route
8
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Example 2 (Win2K)
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...44 45 53 54 42 00 ...... NOC Extranet Access Adapter
0x1000004 ...00 00 e8 e2 2b 24 ...... Realtek RTL8029(AS) Ethernet Adapt
===========================================================================
===========================================================================
Active Routes:
Network Destination
Netmask
Gateway
Interface Metric
0.0.0.0
0.0.0.0
10.10.0.33
10.10.0.35
1
10.10.0.32 255.255.255.240
10.10.0.35
10.10.0.35
1
10.10.0.35 255.255.255.255
127.0.0.1
127.0.0.1
1
10.255.255.255 255.255.255.255
10.10.0.35
10.10.0.35
1
127.0.0.0
255.0.0.0
127.0.0.1
127.0.0.1
1
224.0.0.0
224.0.0.0
10.10.0.35
10.10.0.35
1
255.255.255.255 255.255.255.255
10.10.0.35
2
1
Default Gateway:
10.10.0.33
===========================================================================
Persistent Routes:
None
9
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Types of routes
• We saw some different types of route on the
previous page:
– Connected
– Via next hop
• Also there were
– Routes to different networks; and
– The default route
• Finally (although not shown)
– Routes might be statically defined
– Dynamically created by a routing process
– Or configured as connected routes
10
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
A simple example
• Three hosts
• Each routing table is simple
1.1.1.0/24
1.1.1.1
1.1.1.0/24 connected
2.2.2.0/24 via 1.1.1.2
11
2.2.2.0/24
1.1.1.2
2.2.2.1
1.1.1.0/24 connected
2.2.2.0/24 connected
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
2.2.2.2
2.2.2.0/24 connected
1.1.1.0/24 via 2.2.2.1
A complex example
• 20 hosts
• What on earth should the routing table of each
be?
12
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Dynamic routing protocols
• The solution is Djikstra’s Algorithm or
Distributed Bellman Ford to build the tables
• Primary mechanism:
– Link state routing protocols (Djikstra)
•
•
•
•
OSPF
IS-IS
EIGRP
OLSR
– Distance Vector routing protocols (Bellman Ford)
• RIP1 & RIP2
• BGP
http://www.cs.virginia.edu/~cs551ie/slides/cs551-lecture8-ospfbgp.pdf
13
(C) 2002 Roger Venning <[email protected]> http://netweb.usc.edu/cs551sp2000/lectures/Routing1.pdf
permission to modify / use readily granted
Other approaches
• On-demand routing
– As used by a number of the Mobile Ad-hoc Networking groups
– Most of the time a node doesn’t need to know how to get to all
the other nodes
– So only find out when you need to!
• Source routing
– Include a list of nodes along the way to the destination
• Strict, loose
– Means the intermediate nodes don’t have to know how to get
there…
• Hierarchical
– Different ‘domains’ have different levels of knowledge of
topology
14
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
http://www.eurecom.fr/Symposium2000/slides/slides_CB/sld013.htm
(PLI = physical location information)
15
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Addressing
• Dictated by the previous routing fundamentals
• Performed in a structured manner to:
– Allow for growth
– Allocate efficiently
– Summarise (aggregate) effectively
• Aggregation is used to allow hierarchical routing
– If 1.1.0.0/24 and 1.1.1.0/24 both are reached through the
same path from the perspective of every remote to the
networks, then it can be ‘summarised’ to 1.1.1.0/23…
halving the number of routes. If 1.1.0.0/16 can be
summarised then the number of routing entries is
reduced by 256…
http://netweb.usc.edu/cs551sp2000/lectures/Routing2.ppt
16
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Melbourne Wireless
Current thinking is best summarised as: (no pun intended!)
• OSPF between all nodes that can support it
– Point-to-multipoint mode
– A 172.16.80.0/23 address per core WAN interface
– All nodes area 0 to begin with
• Nodes moved to other areas as density increases
• Non-OSPF nodes numbered with 10.10.0.0/16
address space
• Can support routing nodes not running OSPF – but
not in the core
• BGP to peer – possibly even with other regions
within Melbourne Wireless later on
17
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Discussion
• Should run nodes in ad-hoc, can use omni or less
directional antenna if possible
– Core nodes WAN interfaces should be SSID
“wireless.org.au” and on the same frequency across the
network to assist in meshing
• Can even support ‘client’ nodes on the same
interface (use secondary IP address)
• Focus on connectivity
– Then performance
18
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Summary
• Normal IP routing done on basis of IP destination
– Asks the question which network does it fall into?
• And what therefore is the next hop
• Maintaining the table of networks & next hops can
be hard work when topology changes
• Dynamic routing protocols are the key
– Link state
– Distance vector
• Hierarchy reduces load – localisation of knowledge
– Requires hierarchical addressing
19
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Demonstration
• OSPF on Linux with Zebra (modified to really
support point to point mode)
• No per neighbour configuration (ie. Automated
neighbour discovery, connection & utilisation as
true peer to peer routing)
• Routes around failures
• Supports attached client networks (ie. Wired and
wireless Win95 laptops etc.)
• Supports IPv6 connectivity through 6to4 (should
use ISATAP though)
20
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Demo Configuration
172.16.80.3/32 via 172.16.80.2
172.16.80.2/32 connected
172.16.80.4/32 connected
10.10.0.32/27 connected
connected
10.10.0.0/27 via
via 172.16.80.2
172.16.80.2
80.4
Clients
10.10.0.32/27
SSID: node2
Mode: adhoc
Freq: 2.412GHz
80.1
WAN
172.16.80.0/23
SSID: core
Mode: adhoc
Freq: 2.437GHz
Clients
10.10.0.0/27
80.3
SSID: node1
Mode: adhoc
Freq: 2.457GHz
80.2
172.16.80.1/32 via 172.16.80.2
172.16.80.1/32 via 172.16.80.2
172.16.80.2/32 connected
172.16.80.4/32 connected
10.10.0.0/27 via
via 172.16.80.3
172.16.80.3
172.16.80.2/32 connected
172.16.80.4/32 connected
10.10.0.32/27 connected
connected
10.10.0.32/27 via
via 172.16.80.2
172.16.80.2
10.10.0.32/27 via
via 172.16.80.2
172.16.80.2
21
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Network design templates
•
•
•
•
22
Non-routing node
Simple node
Node with connected internal networks
Node with DMZ
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Scope
• Outline
• Network architecture
– Core Nodes
• OSPF configuration
• Diffserv PHB configuration
• Multicast configuration
– Edge nodes
• Node configuration
• Node templates
• IPv6 support
– Network services
• DNS
23
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Outline
• Peer to peer routing between wireless core nodes
– Through ad-hoc or other connectivity
• Both wired and wireless clients networks attached
to core nodes
– Client networks can be routed network as well
• All nodes and networks ‘uniquely’ numbered from
RFC1918 space
• Attempt to support advanced IP functionality –
DiffServ, IPv6, Multicast
24
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Architecture
Mesh network
• arbitrary topology
• may be subdivided into OSPF
areas
• hierarchy applied with growth
a core
node
Must support
• OSPF
• IP
forwarding
Needs only
one WAN
interface, can
support more
Client network
attached
client
networks
Inter-node links
• ad-hoc
• or infrastructure
25
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Core Nodes
• Supports OSPFv2 routing protocol
– Point to multipoint links
• IP forwarding
– ICMP redirects disabled
– DiffServ PHB
• Connections to ‘client networks’
– Non-OSPF enabled, routed networks
– Includes connected wired & wireless networks supporting
DHCP, including overloaded subnets on WAN interface
– May still be over a long distance wireless link, but these
are still ‘client’ routing nodes.
26
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Core Nodes – OSPF configuration
• WAN interfaces in point-to-multipoint mode
– Each numbered with /32s from 172.16.80.0/23
• Area 0
• Increasing density of mesh will see creation of further
areas, and renumbering of nodes that are re-allocated
• No OSPF MD5 authentication
– Shared key could not be managed anyway
• Filter acceptable routes instead
– Only 172.16.80.0/20 & 10.10.0.0/16?
• Open monitoring interfaces to identify sources of ‘pollution’
• Redistributes connected & summarised routes to
client nodes (many nodes may be ASBR)
• Automatic neighbour discovery through multicast
27
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Core Nodes – Forwarding
• ICMP redirect generation disabled
– Nodes must support forwarding out the incoming
interface
• DiffServ PHB
– Priority queues
• OSPF HELLO etc. prioritised to highest
– Re-classification
• PIM-SM
– Enabled on all boxes for multicast forwarding
• Forwarding statistics exposed via SNMP public
community
28
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Core Nodes – Client networks
• Routes to connections to directly connected
wireless and wireline clients
– e.g. home networks
– may enforce fire-walling between WAN and clients
– no NAT necessary
• Routes to other router nodes that due to an
inability to support OSPF are classed as ‘non-core
router nodes’
29
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Lowest cost ‘core’ node
• Router node with just one wireless interface
– Interface runs in ad-hoc mode with wireless.org.au SSID
– Configured with /32 from 172.16.80.0/23 address for
WAN connectivity (further blocks allocated as needed)
– Additional /28 subnet added from 10.10.0.0/16 to the
same interface (secondary address)
• DHCP runs on this subnet for wireless client nodes
– Could also support wired clients on another subnet if the
platform has an ethernet card
• Runs Zebra or other OSPF implementation on a OS
that supports IP forwarding (e.g. Linux, FreeBSD)
30
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Backbone ‘core node’
• Many router interfaces
– Sectorised antenna for higher throughput
• Still using ad-hoc mode point-to-multipoint
– High gain directional antenna on dedicated cards for long
haul links
• Could use access points in bridging mode, ad-hoc cards,
configure with a /30 and run in OSPF broadcast mode
• This would be numbered from 172.16.80.22/23 (further
allocation made as needed)
31
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Edge nodes
• May be able to route IP, but do not support OSPF
(otherwise would add within OSPF areas)
• These may support RIP for instance, or use static
routing, with default route via the connected ‘core’
node
• If multi-homed (ie. to two core nodes) can support
receiving traffic from either, but only sending via
one.
• Win2K etc. could function in this role. Purportedly
Win98 as well with registry patch and static
routes?
32
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
IPv6 support to edge nodes
• Since using RFC1918 space, then nodes should use
ISATAP to gain addresses through prefixes from
nodes that may be connected to the 6Bone.
• Tunnels IPv6 over IPv4, no support necessary
from
33
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Node Templates
34
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Design 1
Non-core routing node
WAN
172.16.80.0/23
/29 (6 hosts)
172.16.80.x
Non-OSPF
node
10.10.x.x/29
Simplest case. Even though connected over wide area wireless link, node does
not route packets to other nodes.
Greyed out ‘server’ node might have for instance an omni, non-routing node
might be a Windows 98 PC.
35
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Design 1a
Non-core routing node
WAN
172.16.80.0/23
/29 (6 hosts)
172.16.80.x
Non-OSPF
node
10.10.x.x/29
Non-routing node with clients. Link to core node like previous case.
/29 (6 hosts)
36
Server node assigns an address plus a static route to the client node. It must
redistribute this static route into the WAN.
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Design 2
Simple core-node
OSPFv2 run as WAN routing
protocol, interface treated as
point-to-multipoint, multicast
capable.
WAN
172.16.80.0/23
172.16.80.x
Internet
Simplest routing node case.
The WAN interface uses address space from 172.16.80.0/20. Initially use
172.16.80.0/23 for backbone address range.
The interface is assigned an address from this range, and uses the netmask
255.255.254.0
Acting as a server node on the same interface is possible by overloading
subnets. Works with both IBSS and BSS mode, but makes the most sense in
IBSS mode.
37
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Design 3a
Core-node with wired clients
Reachability to the
10.10.x.x/28 subnet
announced into the WAN via
OSPFv2.
WAN
172.16.80.0/23
172.16.80.x
Allocation:
10.10.x.x/28
Internet
/28 (14 hosts)
As before, but the router node also has a connected route to a client subnet.
Presumably trusted nodes on the fixed network, so appropriate firewalling might
be used.
38
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Design 3b
Core-node with wireless clients
Summarised reachability to
the /28 subnet announced
into the WAN
WAN
172.16.80.0/23
172.16.80.x
/28 (14 hosts)
Internet
Allocation:
10.10.x.x/28
As before, but this time the client subnet is wireless. This might be a public
access wireless interface, and also support wide area nodes.
Authentication solutions are out of scope.
39
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Design 3c
Core-node with wired & wireless clients
Summarised reachability to
the /28 subnet announced
into the WAN
WAN
172.16.80.0/23
172.16.80.x
/29 (6 hosts)
Allocation:
10.10.x.x/28
Internet
/29 (6 hosts)
Text to describe
40
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Design 4
Core-node with DMZ
Summarised reachability to the /27
subnet announced into the WAN. OSPF
can be used within the site as area
172.16.80.x
WAN
172.16.80.0/23
172.16.80.x
/29 (6 hosts)
DMZ
/30 (2 hosts)
Internet
Allocation:
10.10.x.x/27
Free:
/29 (6 hosts)
/30 (2 hosts)
/29 (6 hosts)
Text to describe
41
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Design Summary
Wireless Configuration – channel, ESSID
(1) non-routing node
Configuration dictated by the ‘server’ node that this node connects to. Use of BSS mode
entirely reasonable, as this node will not forward further to other nodes out of reach of
the ‘server’ node.
(1)(a) non-routing node
Ditto
(2) simple node
Follows WAN standard. If ad-hoc, then can use single interface to forward on behalf of
peers.
(3)(a) node with wired clients
Ditto
(3)(b) node with wireless clients
As before, but if wireless clients also in ad-hoc mode, then one interface can be used
for both local and WAN clients. Desirable to split though for performance reasons.
Changing ESSID is not enough, must be on discrete channel.
(3)(c) node with wireless & wired
clients
Ditto
(4) node with DMZ
Ditto
Notes: in order to support a mesh, rather than several sets of access point areas, joined by machines
with more than one interface, WAN must use ad-hoc links when using antenna technologies that allow
many to many connectivity. Similarly, one ESSID, a single WEP key, and a single channel must be used
across the entire network to avoid partitioning that requires machines with > 1 interface to connect the
two sets.
42
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Design Summary
Network configuration
• OSPF details
• ICMP send redirects must be turned off
• /proc/sys/net/ipv4/config/eth1/icmp_send_redirect < echo 0
• FreeBSD?
• Hello interval?
•?
43
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Design Summary
Network configuration
• OSPF, point-to-multipoint, 172.16.80.0/23 space, ICMP redirects off
• Adhoc, ESSID wireless.org.au
• Client networks 10.10.0.0/16
• DHCP for clients, static routing, etc.
• IPv4 backbone
• ISATAP IPv6 with 6to4 connectivity
• Multicast routing: PIM-SM
44
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Design Summary
Network configuration
• DNS
• names follow name.nodecode.wireless.org.au
• reverse DNS? Class C reverse DNS versus delegating /28?
• Management
• SNMP public access encouraged
• module for monitoring link quality (any MIBS standardised?)
• DiffServ
• PHB implementation in Linux.
• Routing protocols
• unicast & multicast
•
45
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Implementation
46
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Linux
•
•
•
•
•
•
•
47
Wireless configuration through iwconfig
Addressing configuration
Zebra configuration
Setting of icmp_send_redirect
DiffServ
PIM-SM
IPv6
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Wireless configuration
• iwconfig <eth0> essid wireless.org.au freq 2.412G
mode ad-hoc
48
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
WAN Routing
OSPF allows nodes to discover neighbours, and exchange information about link
states (connections to other neighbours and networks). Each node then forms a
shortest-path tree (utilising link cost information as ‘distance’) to each known
network. This algorithm is run for all link state information within an area; link
state information does not leak across area boundaries.
Area 1
Backbone
(AREA 0)
Area 2
49
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Area 3
WAN Routing Areas
OSPF allows nodes to discover neighbours, and exchange information about link
states (connections to other neighbours and networks). Each node then forms a
shortest-path tree (utilising link cost information as ‘distance’) to each known
network. This algorithm is run for all link state information within an area; link
state information does not leak across area boundaries.
(2) Learns of reachability to
10.10.11.0/24 through (1) and
does not know about (4)
2
1
4
3
Announces 10.10.11.16/28
Area Border
Router
Summarises and announces
10.10.11.0/24
50
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
WAN Routing – Impact of Areas
• Size of link state databases kept smaller
• fewer re-computations of shortest path first tree as less links to change
state
• faster re-computations when it does occur, as tree is smaller
• Traffic only optimally routed within an area
• Summarisation and hiding of information at borders may lead to suboptimality
• All areas must be connected to the backbone, i.e. all area border routers
must be on the backbone
• if not physically connected to the backbone, it can be extended with
‘virtual links’
• Addresses must assigned in aggregatable fashion so that the subnets that
constitute and area can be concisely configured and summarisation is
accurate.
51
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
WAN Routing – Impact of Areas Illustrated
Traffic path without
node 2 added to
the backbone via
virtual link
1
New (cross area) Link
2
Traffic path when 2
is part of backbone.
Virtual Link
• Communication between different node (1 & 2) in different areas must be via the
backbone.
• Additional nodes can be added to the backbone with ‘virtual links’
52
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Melbourne Wireless OSPFv2 Configuration
• All nodes initially in the backbone.
• A subnet for all interfaces in the backbone must be allocated
• choose 172.16.80.0/23 out of the Melbourne Wireless earmarked
10.10.0.0/16 and 172.16.80.0/20
• this gives up to 510 nodes in the backbone, which exceeds the
number of routers in an area that has previously been observed to
give operational instability
• Any other networks connected to a backbone node are placed within an stub
area, number equivalent to the lowest 172.16.80.0/23 address allocated to that
node
• this keeps the backbone link state database smaller
53
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Zebra Configuration Tests
• take three hosts (A), (B), (C), configured each with one interface in the
backbone, and connectivity (A) (B) and (B) (C)
• does zebra create host routes to each other node in addition to the less
specific 172.16.80.0/23 connected subnet route already on the interface?
• add an additional interface to (C) and arrange such that (C)  (A) (and
only this connectivity) on this (and only this) interface?
• does zebra operate correctly over two interfaces both connected to the
same network on node (C)
• add a connected network to (A)
• do nodes (B) & (C) learn reachability?
54
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Growing the network
• As the network grows, it will become obvious that some nodes do not usefully
fall within the backbone
• e.g. a node has connectivity to just one other node
• These nodes can then be partitioned off into a separate area
• Why can’t we just allocate areas on the basis of large geographical cells?
• because the borders between cells would be the backbone
• all traffic between cells must be via the backbone, e.g. non-adjacent
cells would all focus the traffic on the cell borders (backbone). The lack of
higher speed technologies for the backbone mean that this would lead to
undesirable congestion.
• Outcome: would rather prefer a backbone with a high degree of
multipath, obtained through fine structure by using quite small cells.
55
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Random example – Area 0 or other links
To improve backbone scalability, some
links can be taken out of Area 0 (the
backbone) and placed in another area.
No inter-area traffic will traverse the red
links though – a blue link (backbone) path
must be used instead.
2
1
5
3
7
13
6
Non-backbone area
14
12
8
11
16
10
15
9
17
18
20
19
21
56
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Multicast
• Cover configuration of multicast
– PIM-DM or PIM-SM?
• Utilise for multimedia applications e.g.
broadcasting meetings, ‘talkback webradio’.
57
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Network Peering
• Covers the interconnection of the WAN to other
similar networks through BGP
• Cooperation in RFC1918 addressing
58
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
IPv6 Addressing Fundamentals
• Prefix Acquisition Options
– WAN “boundaries”
• 6to4 (from nodes with public IPv4 allocation)
• Prefixes allocations from tunnel brokers
• Assignments from registries
– Native IPv6/IPv4 links
• From other networks that are closer to the WAN “boundary”
• Through the same allocation process as Melbourne Wireless
RFC1918 space – need to acquire a /48 and sub-allocate
–
–
–
–
APNIC?
pTLA?
Tunnel broker?
Start with fec0::/48
– Separated islands of IPv6
• Addresses through ISATAP
59
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
One IPv6 overlay architecture
2002:8040::/48
for WAN
From static IPv4
128.64.0.2 allocation
Area 2
Area 2
Area 2
Area 2
Native
IPv6 / IPv4
link
ISATAP GW
128.64.0.2
ISATAP GW
IPv4
only link
ISATAP
Client
6to4 to
6Bone
6to4 GW
Static tunnel
60
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
IPv6 Addressing Fundamentals
• Prefixes Distribution
– 6to4: from nodes with public IPv4 addresses
– Native IPv6/IPv4 links
– ISATAP for automatic tunnelling within the mesh
• Static configuration of ISATAP gateways
– ISATAP gateways can also support sending
Area 2
Area 2
Area 2
Area 2
200.100.0.2
ISATAP GW
61
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
IPv6 Applications
• VIC / RAT – IPv6 & multicast video / audio
conferencing
• Mozilla & Apache
• ncftp & wu-ftpd
• Samba
62
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Distributed Web Caching
• Configuration of Central Squid Server?
63
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted
Peer to peer file sharing
• Can we run an internal file sharing app?
64
(C) 2002 Roger Venning <[email protected]>
permission to modify / use readily granted