Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Wireless security wikipedia , lookup
Computer network wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Airborne Networking wikipedia , lookup
IEEE 802.11 wikipedia , lookup
Zero-configuration networking wikipedia , lookup
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