(c) 2002 roger venning permission to modify / use readily granted 1 routing & addressing routing...
TRANSCRIPT
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
1
Routing & Addressing
Routing and Addressing Working Group.© 2002 Roger Venning <[email protected]>
Permission to use or modify readily granted.Version 0.12
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
2
Contents
• Introduction to Routing
• Network Design Templates• WAN routing overview• WAN addressing• Multicast Another
time
• Network peering• IPv6• Distributed Web Caching• Internal peer-to-peer file sharing
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
3
Introduction to Routing
• 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
4
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
http://www.erg.abdn.ac.uk/users/gorry/eg3561/inet-pages/ip-packet.html
http://ntrg.cs.tcd.ie/undergrad/4ba2/ipng/gerd.ipv4.html
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
5
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)
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
6
How to check if a IP is in a 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/32 255.255.255.255 /24 255.255.255.0 /16 255.255.0.0 /8 255.0.0.0 /0 0.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
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
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
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
IP
& result
Mask
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
7
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
8
An example routing table
172.16.80.5 via 10.10.0.34 dev eth0203.220.79.17 dev ppp0 proto kernel scope link src 203.221.40.10310.10.0.48/29 dev eth1 proto kernel scope link src 10.10.0.4910.10.0.32/28 dev eth0 scope link172.16.80.0/20 via 10.10.0.34 dev eth010.10.0.0/16 via 10.10.0.34 dev eth0127.0.0.0/8 dev lo scope linkdefault via 203.220.79.17 dev ppp0
• 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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
9
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
10
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
11
A simple example
1.1.1.1 1.1.1.2 2.2.2.1 2.2.2.2
1.1.1.0/24 2.2.2.0/24
1.1.1.0/24 connected2.2.2.0/24 via 1.1.1.2 1.1.1.0/24 connected
2.2.2.0/24 connected
2.2.2.0/24 connected1.1.1.0/24 via 2.2.2.1
• Three hosts• Each routing table is simple
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
12
A complex example
• 20 hosts• What on earth should the routing table of each
be?
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
13
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
http://netweb.usc.edu/cs551sp2000/lectures/Routing1.pdf
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
14
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
15
http://www.eurecom.fr/Symposium2000/slides/slides_CB/sld013.htm(PLI = physical location information)
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
16
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
17
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
18
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
19
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
20
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)
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
21
Demo Configuration
WAN172.16.80.0/23
SSID: coreMode: adhoc
Freq: 2.437GHz
Clients10.10.0.32/27
SSID: node2Mode: adhoc
Freq: 2.412GHz
Clients10.10.0.0/27
SSID: node1Mode: adhoc
Freq: 2.457GHz
80.1
80.2
80.3
80.4
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
10.10.0.0/27 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 172.16.80.3
10.10.0.32/27 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.32/27 connected
10.10.0.32/27 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.32/27 connected
10.10.0.32/27 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 172.16.80.3
10.10.0.32/27 via 172.16.80.2
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
10.10.0.0/27 via 172.16.80.2
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
22
Network design templates
• 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
23
Scope
• Outline• Network architecture
– Core Nodes• OSPF configuration• Diffserv PHB configuration• Multicast configuration
– Edge nodes• Node configuration• Node templates• IPv6 support
– Network services• DNS
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
24
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
25
Architecture
Client network
a core node
Must support• OSPF• IP forwardingNeeds only one WAN interface, can support moreattached
client networks
Inter-node links
• ad-hoc • or infrastructure
Mesh network• arbitrary topology• may be subdivided into OSPF areas• hierarchy applied with growth
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
26
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.
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
27
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
28
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
29
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’
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
30
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)
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
31
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)
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
32
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?
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
33
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
34
Node Templates
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
35
WAN172.16.80.0/23
172.16.80.x
10.10.x.x/29
/29 (6 hosts)
Non-OSPF node
Non-core routing node
Design 1
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.
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
36
/29 (6 hosts)
WAN172.16.80.0/23
172.16.80.x
10.10.x.x/29
/29 (6 hosts)
Non-OSPF node
Non-core routing node
Design 1a
Non-routing node with clients. Link to core node like previous case.
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
37
Simple core-node
Internet
WAN172.16.80.0/23
172.16.80.x
Design 2
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.
OSPFv2 run as WAN routing protocol, interface treated as point-to-multipoint, multicast capable.
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
38
Internet
WAN
/28 (14 hosts)
Allocation:10.10.x.x/28
172.16.80.0/23
172.16.80.x
Core-node with wired clients
Design 3a
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.
Reachability to the 10.10.x.x/28 subnet announced into the WAN via OSPFv2.
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
39
Internet
WAN
/28 (14 hosts)
Allocation:10.10.x.x/28
172.16.80.0/23
172.16.80.x
Core-node with wireless clients
Design 3b
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.
Summarised reachability to the /28 subnet announced into the WAN
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
40
Internet
WAN
/29 (6 hosts)
/29 (6 hosts)
Allocation:10.10.x.x/28
172.16.80.0/23
172.16.80.x
Core-node with wired & wireless clients
Design 3c
Text to describe
Summarised reachability to the /28 subnet announced into the WAN
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
41
Internet
WAN
DMZ/30 (2 hosts)
/29 (6 hosts)
Free:/29 (6 hosts)/30 (2 hosts)
/29 (6 hosts)
Allocation:10.10.x.x/27
172.16.80.0/23
172.16.80.x
Design 4
Text to describe
Summarised reachability to the /27 subnet announced into the WAN. OSPF can be used within the site as area 172.16.80.x
Core-node with DMZ
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
42
Design Summary
(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.
Wireless Configuration – channel, ESSID
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
43
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?
• ?
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
44
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
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
45
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
•
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
46
Implementation
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
47
Linux
• 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
48
Wireless configuration
• iwconfig <eth0> essid wireless.org.au freq 2.412G mode ad-hoc
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
49
Backbone(AREA 0)
Area 1
Area 2
Area 3
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.
WAN Routing
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
50
Area Border Router
Announces 10.10.11.16/28
Summarises and announces10.10.11.0/24
(2) Learns of reachability to 10.10.11.0/24 through (1) and does not know about (4)
1
2
43
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.
WAN Routing Areas
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
51
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 sub-optimality
• 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.
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
52
New (cross area) Link
Traffic path without node 2 added to the backbone via virtual link
Traffic path when 2 is part of backbone.
Virtual Link
1
2
• 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’
WAN Routing – Impact of Areas Illustrated
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
53
• 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
Melbourne Wireless OSPFv2 Configuration
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
54
• 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?
Zebra Configuration Tests
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
55
• 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.
Growing the network
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
56
11
5
21
18
2
6
3
15
12
13
20
19
7
8
9
17
1610
14
1
Non-backbone area
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.
Random example – Area 0 or other links
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
57
Multicast
• Cover configuration of multicast– PIM-DM or PIM-SM?
• Utilise for multimedia applications e.g. broadcasting meetings, ‘talkback webradio’.
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
58
Network Peering
• Covers the interconnection of the WAN to other similar networks through BGP
• Cooperation in RFC1918 addressing
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
59
• 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
IPv6 Addressing Fundamentals
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
60
One IPv6 overlay architecture
128.64.0.2
Area 2Area 2
Area 2
Area 2
ISATAP GW
6to4 to6Bone
2002:8040::/48 for WAN
From static IPv4 128.64.0.2 allocation
6to4 GW
ISATAP GW
Static tunnel
NativeIPv6 / IPv4
link
IPv4only link ISATAP
Client
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
61
• 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
IPv6 Addressing Fundamentals
200.100.0.2
Area 2Area 2
Area 2
Area 2
ISATAP GW
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
62
IPv6 Applications
• VIC / RAT – IPv6 & multicast video / audio conferencing
• Mozilla & Apache• ncftp & wu-ftpd• Samba
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
63
Distributed Web Caching
• Configuration of Central Squid Server?
(C) 2002 Roger Venning <[email protected]> permission to modify / use readily granted
64
Peer to peer file sharing
• Can we run an internal file sharing app?