Routing Addressing Routing and Addressing Working Group 2002

Routing & Addressing Routing and Addressing Working Group. © 2002 Roger Venning <roger. venning@ieee. org> Permission to use or modify readily granted. Version 0. 12 1 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Contents • Introduction to Routing • • 2 Network Design Templates WAN routing overview WAN addressing Multicast Network peering IPv 6 Distributed Web Caching Internal peer-to-peer file sharing (C) 2002 Roger Venning <roger. venning@ieee. org> 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/eg 3561/syllabus. html (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Internet Protocol • IPv 4 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/eg 3561/inet-pages/ip-p (C) 2002 Roger Venning <roger. venning@ieee. org> http: //ntrg. cs. tcd. ie/undergrad/4 ba 2/ipng/gerd. ip 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 <roger. venning@ieee. org> permission to modify / use readily granted

How to check if a IP is in a network 0 0 0 1 1 1 0 1 1 0 1 IP 1 1 1 1 1 1 0 0 0 0 Mask 0 0 0 1 1 1 0 1 1 0 0 0 0 0 & result 0 0 0 1 1 1 1 1 0 0 0 0 <> Network Or more simply: 22. 221. 236. 205 does not fall in network 22. 255. 0/24 Netmask can also be specified in dotted quad, like 255. 0 6 /32 255 /24 255. 0 /16 255. 0. 0 /8 255. 0. 0. 0 /31 255. 254 /23 255. 254. 0 /15 255. 254. 0. 0 /7 254. 0. 0. 0 /30 255. 252 /22 255. 252. 0 /14 255. 252. 0. 0 /6 252. 0. 0. 0 /29 255. 248 /21 255. 248. 0 /13 255. 248. 0. 0 /5 248. . 0. 0 /28 255. 240 /20 255. 240. 0 /12 255. 240. 0. 0 /4 240. 0 /27 255. 224 /19 255. 224. 0 /11 255. 224. 0. 0 /3 224. 0. 0. 0 /26 255. 196 /18 255. 196. 0 /10 255. 196. 0. 0 /2 196. 0. , 0. 0 /25 255. 128 /17 255. 128. 0 /9 255. 128. 0. 0 /1 128. 0. 0. 0 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted /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/24 • Netmask also represented as dotted quad, e. g. 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 <roger. venning@ieee. org> permission to modify / use readily granted

An example routing table 172. 16. 80. 5 via 10. 0. 34 dev eth 0 203. 220. 79. 17 dev ppp 0 proto kernel scope link 10. 0. 48/29 dev eth 1 proto kernel scope link 10. 0. 32/28 dev eth 0 scope link 172. 16. 80. 0/20 via 10. 0. 34 dev eth 0 10. 0. 0/16 via 10. 0. 34 dev eth 0 127. 0. 0. 0/8 dev lo scope link default via 203. 220. 79. 17 dev ppp 0 src 203. 221. 40. 103 src 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. 0. 34 – Must know how to get to 10. 0. 34… via connected route 8 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Example 2 (Win 2 K) ====================================== Interface List 0 x 1. . . . MS TCP Loopback interface 0 x 2. . . 44 45 53 54 42 00. . . NOC Extranet Access Adapter 0 x 1000004. . . 00 00 e 8 e 2 2 b 24. . . Realtek RTL 8029(AS) Ethernet Adapt =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0. 0 10. 0. 33 10. 0. 35 1 10. 0. 32 255. 240 10. 10. 0. 35 1 10. 0. 35 255 127. 0. 0. 1 1 10. 255 10. 10. 0. 35 1 127. 0. 0. 0 255. 0. 0. 0 127. 0. 0. 1 1 224. 0. 0. 0 10. 10. 0. 35 1 255 10. 0. 35 2 1 Default Gateway: 10. 0. 33 ====================================== Persistent Routes: None 9 (C) 2002 Roger Venning <roger. venning@ieee. org> 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 <roger. venning@ieee. org> permission to modify / use readily granted

A simple example • Three hosts • Each routing table is simple 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 <roger. venning@ieee. org> permission to modify / use readily granted 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 <roger. venning@ieee. org> 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) • RIP 1 & RIP 2 • BGP http: //www. cs. virginia. edu/~cs 551 ie/slides/cs 551 -lecture 8 -osp 13 (C) 2002 Roger Venning <roger. venning@ieee. org> http: //netweb. usc. edu/cs 551 sp 2000/lectures/Routing 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 <roger. venning@ieee. org> permission to modify / use readily granted

http: //www. eurecom. fr/Symposium 2000/slides_CB/sld 013. htm (PLI = physical location information) 15 (C) 2002 Roger Venning <roger. venning@ieee. org> 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/cs 551 sp 2000/lectures/Routin 16 (C) 2002 Roger Venning <roger. venning@ieee. org> 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. 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 <roger. venning@ieee. org> 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 <roger. venning@ieee. org> 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 <roger. venning@ieee. org> 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 Win 95 laptops etc. ) • Supports IPv 6 connectivity through 6 to 4 (should use ISATAP though) 20 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Demo Configuration 172. 16. 80. 3/32 via 172. 16. 80. 2/32 connected 172. 16. 80. 4/32 connected 10. 0. 32/27 connected 10. 0. 0/27 via 172. 16. 80. 2 80. 4 Clients 10. 0. 32/27 SSID: node 2 Mode: adhoc Freq: 2. 412 GHz 80. 1 WAN 172. 16. 80. 0/23 SSID: core Mode: adhoc Freq: 2. 437 GHz Clients 10. 0. 0/27 80. 3 SSID: node 1 Mode: adhoc Freq: 2. 457 GHz 80. 2 172. 16. 80. 1/32 via 172. 16. 80. 2/32 connected 172. 16. 80. 4/32 connected 10. 0. 0/27 via 172. 16. 80. 3 172. 16. 80. 2/32 connected 172. 16. 80. 4/32 connected 10. 0. 32/27 connected 10. 10. 0. 32/27 via via 172. 16. 80. 2 21 (C) 2002 Roger Venning <roger. venning@ieee. org> 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 <roger. venning@ieee. org> 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 • IPv 6 support – Network services • DNS 23 (C) 2002 Roger Venning <roger. venning@ieee. org> 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 RFC 1918 space • Attempt to support advanced IP functionality – Diff. Serv, IPv 6, Multicast 24 (C) 2002 Roger Venning <roger. venning@ieee. org> 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 <roger. venning@ieee. org> permission to modify / use readily granted

Core Nodes • Supports OSPFv 2 routing protocol – Point to multipoint links • IP forwarding – ICMP redirects disabled – Diff. Serv 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 <roger. venning@ieee. org> permission to modify / use readily granted

Core Nodes – OSPF configuration • WAN interfaces in point-to-multipoint mode – Each numbered with /32 s 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 MD 5 authentication – Shared key could not be managed anyway • Filter acceptable routes instead – Only 172. 16. 80. 0/20 & 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 <roger. venning@ieee. org> permission to modify / use readily granted

Core Nodes – Forwarding • ICMP redirect generation disabled – Nodes must support forwarding out the incoming interface • Diff. Serv 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 <roger. venning@ieee. org> 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 <roger. venning@ieee. org> 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. 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, Free. BSD) 30 (C) 2002 Roger Venning <roger. venning@ieee. org> 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 <roger. venning@ieee. org> 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. • Win 2 K etc. could function in this role. Purportedly Win 98 as well with registry patch and static routes? 32 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

IPv 6 support to edge nodes • Since using RFC 1918 space, then nodes should use ISATAP to gain addresses through prefixes from nodes that may be connected to the 6 Bone. • Tunnels IPv 6 over IPv 4, no support necessary from 33 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Node Templates 34 (C) 2002 Roger Venning <roger. venning@ieee. org> 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. 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, nonrouting node might be a Windows 98 PC. 35 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Design 1 a Non-core routing node WAN 172. 16. 80. 0/23 /29 (6 hosts) 172. 16. 80. x Non-OSPF node 10. x. x/29 (6 hosts) 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. 36 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Design 2 Simple core-node OSPFv 2 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. 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 <roger. venning@ieee. org> permission to modify / use readily granted

Design 3 a Core-node with wired clients Reachability to the 10. x. x/28 subnet announced into the WAN via OSPFv 2. WAN 172. 16. 80. 0/23 172. 16. 80. x Allocation: 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 <roger. venning@ieee. org> permission to modify / use readily granted

Design 3 b Core-node with wireless clients Summarised reachability to the /28 subnet announced into the WAN 172. 16. 80. 0/23 172. 16. 80. x /28 (14 hosts) Internet Allocation: 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 <roger. venning@ieee. org> permission to modify / use readily granted

Design 3 c Core-node with wired & wireless clients Summarised reachability to the /28 subnet announced into the WAN 172. 16. 80. 0/23 172. 16. 80. x /29 (6 hosts) Allocation: 10. x. x/28 Internet /29 (6 hosts) Text to describe 40 (C) 2002 Roger Venning <roger. venning@ieee. org> 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) Internet DMZ /30 (2 hosts) Allocation: 10. x. x/27 Free: /29 (6 hosts) /30 (2 hosts) /29 (6 hosts) Text to describe 41 (C) 2002 Roger Venning <roger. venning@ieee. org> 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 <roger. venning@ieee. org> permission to modify / use readily granted

Design Summary Network configuration • OSPF details • ICMP send redirects must be turned off • /proc/sys/net/ipv 4/config/eth 1/icmp_send_redirect < echo 0 • Free. BSD? • Hello interval? • ? 43 (C) 2002 Roger Venning <roger. venning@ieee. org> 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. 0. 0/16 • DHCP for clients, static routing, etc. • IPv 4 backbone • ISATAP IPv 6 with 6 to 4 connectivity • Multicast routing: PIM-SM 44 (C) 2002 Roger Venning <roger. venning@ieee. org> 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? ) • Diff. Serv • PHB implementation in Linux. • Routing protocols • unicast & multicast 45 • (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Implementation 46 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Linux • • 47 Wireless configuration through iwconfig Addressing configuration Zebra configuration Setting of icmp_send_redirect Diff. Serv PIM-SM IPv 6 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Wireless configuration • iwconfig <eth 0> essid wireless. org. au freq 2. 412 G mode ad-hoc 48 (C) 2002 Roger Venning <roger. venning@ieee. org> 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 <roger. venning@ieee. org> 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. 11. 0/24 through (1) and does not know about (4) 2 1 4 3 Announces 10. 11. 16/28 Area Border Router Summarises and announces 10. 11. 0/24 50 (C) 2002 Roger Venning <roger. venning@ieee. org> 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 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’ 51 • Addresses must assigned in aggregatable fashion so that the subnets that constitute and area can be concisely configured (C) 2002 Roger Venning <roger. venning@ieee. org> and summarisationpermission is accurate. 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 <roger. venning@ieee. org> permission to modify / use readily granted

Melbourne Wireless OSPFv 2 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. 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 <roger. venning@ieee. org> 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 <roger. venning@ieee. org> 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. nonadjacent 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. 55 • Outcome: would rather prefer a backbone with a high (C) 2002 Roger Venning <roger. venning@ieee. org> degree of multipath, obtained through fine structure by using 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. 5 2 1 3 13 7 6 Non-backbone area 14 12 8 11 16 10 15 9 17 18 20 19 21 56 (C) 2002 Roger Venning <roger. venning@ieee. org> 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 <roger. venning@ieee. org> permission to modify / use readily granted

Network Peering • Covers the interconnection of the WAN to other similar networks through BGP • Cooperation in RFC 1918 addressing 58 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

IPv 6 Addressing Fundamentals • Prefix Acquisition Options – WAN “boundaries” • 6 to 4 (from nodes with public IPv 4 allocation) • Prefixes allocations from tunnel brokers • Assignments from registries – Native IPv 6/IPv 4 links • From other networks that are closer to the WAN “boundary” • Through the same allocation process as Melbourne Wireless RFC 1918 space – need to acquire a /48 and sub-allocate – – APNIC? p. TLA? Tunnel broker? Start with fec 0: : /48 – Separated islands of IPv 6 • Addresses through ISATAP 59 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

One IPv 6 overlay architecture 2002: 8040: : /48 for WAN From static IPv 4 128. 64. 0. 2 allocation Area 2 Native IPv 6 / IPv 4 link ISATAP GW 128. 64. 0. 2 ISATAP GW IPv 4 only link ISATAP Client 6 to 4 to 6 Bone 6 to 4 GW Static tunnel 60 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

IPv 6 Addressing Fundamentals • Prefixes Distribution – 6 to 4: from nodes with public IPv 4 addresses – Native IPv 6/IPv 4 links – ISATAP for automatic tunnelling within the mesh • Static configuration of ISATAP gateways – ISATAP gateways can also support sending Area 2 200. 100. 0. 2 ISATAP GW 61 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

IPv 6 Applications • VIC / RAT – IPv 6 & multicast video / audio conferencing • Mozilla & Apache • ncftp & wu-ftpd • Samba 62 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Distributed Web Caching • Configuration of Central Squid Server? 63 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted

Peer to peer file sharing • Can we run an internal file sharing app? 64 (C) 2002 Roger Venning <roger. venning@ieee. org> permission to modify / use readily granted