Sunday, June 21, 2009

IPv6 Introduction

IPv6 is an extension of IP with several advanced features:
  • Larger address space
  • Simpler header
  • Autoconfiguration
  • Extension headers
  • Flow labels
  • Mobility
  • “Baked in” security
Of these, many capabilities have been backported to IPv4. The primary adoption of IPv6 will be driven by the need for more addresses. Given the growth in Internet use and the emergence of large groups of Internet users in developing countries, this is a significant requirement.

IPv6 Routing Prefix

IPv4 addresses are 32 bits long, whereas IPv6 addresses are 128 bits. IPv6 addresses are composed of the following elements (see Figure 8-1):
  • The first three bits (/3) of unicast always 001.
  • The next 13 bits (/16) are Top-Level Aggregator (TLA) the upstream ISP.
  • The next 24 bits (/40) are the next-level aggregator or regional ISP.
  • Enterprises are assigned /48 and have 16 bits of subnetting.

IPv6 Interface ID


The host portion of the address is last 64 bits. It can be assigned manually, using DHCP v6, or using stateless autoconfiguration. An end-system uses stateless autoconfiguration by waiting for a router to advertise the local prefix. If the end system has a 64-bit MAC, it concatenates the prefix and its MAC to form an IPv6 address. If the end system has a 48-bit MAC, it flips the global/local bit and inserts 0xFFEE into the middle of the MAC. The resulting 64-bit number is called the EUI64. The prefix and EUI64 are concatenated to form the address. Figure 8-2 shows how a host uses its MAC address to create its IPv6 address.


Simplified Presentation of IPv6 Address
There are two ways to shorten the representation of an IPv6 address. Take the example address
4001:0000:0001:0002:0000:0000:0000:ABCD.
  • Leading zeros may be omitted. This makes the example 4001:0:1:2:0:0:0:ABCD.
  • Sequential zeros may be shown as double colons once per address. This makes the example 4001:0:1:2::ABCD.

IPv6 Header


The IPv6 header is similar to the IPv4 header. The largest changes have to do with the larger addresses, aligning fields to 64-bit boundaries and moving fragmentation to an extension header.

The fields are:
  • Version—6.
  • Priority—Similar to DSCP in version 4, this eight-bit field is used to describe relative priority.
  • Flow—20-bit flow label allows tagging in a manner similar to MPLS.
  • Length—The length of the data in the packet.
  • Next Header—Indicates how the bits after the IP header should be interpreted. Could indicate TCP or UDP, or it could show an extension header.
  • Hop Limit—Similar to TTL.
  • Source and Destination—IPv6 addresses.
Zero or more extension headers could follow, including:
  • Hop-by-hop options—Options for intermediate devices.
  • Destination options—Options for the end node.
  • Source routing—Specifies “way stations” that the route must include.
  • Fragmentation—Used to divide packets.
  • Authentication—Used to attest to source. Replaces the AH header from IPSec.
  • Encryption—Replaces the IPSec ESP header.

Sunday, June 14, 2009

Multicast MAC Address

Multicast MAC addresses all start with the first 25 bits 01005E. The last 23 bits are the left-most bits from the IP address. Example 7-4 shows how a MAC address of 0100.5E40.0305 maps to a multicast IP address of 227.64.3.5.


The first four bits of multicast IP addresses are always 1110, and the last 23 bits map to the MAC. That leaves five bits that are dropped. Remember that this is an issue, because every multicast MAC maps to many multicast IPs! Example 7-5 shows how a MAC address of 0100.5E40.0305 could map to several different multicast IP addresses. Notice that the first two octets can vary in the IP addresses.


Multicast IP Addresses

Multicasts use the IP address range 224.0.0.0 to 239.255.255.255. The first four bits of the first octet are always binary 1110, and the remaining 28 bits identify the multicast group. Some addresses are reserved:
  • 224.0.0.1 is the all-hosts group.
  • 224.0.0.2 is the all-routers group.
  • The rest of the 224.0.0.0/24 range is reserved for link-local protocols.
  • 224.0.1.0 to 238.255.255.255 are for use over the Internet, and they are called globally-scoped addresses.
  • Source-specific multicast uses 232.0.0.0/8 addresses.
  • 233.0.0.0/8 is used to assign static multicast addresses for use by an organization. The second and third octets of the address are the organization’s Autonomous System number. This is called GLOP, which is a combination of global and scope.
  • 239.0.0.0/8 is for local use within an organization, and it is called a limited scope or an administratively scoped address.

Protocol Independent Multicast (PIM)

PIM is a protocol used between routers to keep track of where to forward traffic for each multicast group. It can use information gathered from any routing protocol. PIM can run in dense mode or sparse mode.

PIM Dense Mode
PIM dense mode uses source-based trees. When running in dense mode, PIM assumes that every router needs to receive multicasts. Any router that doesn’t want to receive it must send a prune message upstream to the server. PIM dense mode is most appropriate when:
  • Multicast servers and receivers are near each other.
  • There are just a few servers and many receivers.
  • You have a high volume of multicast traffic.
  • The multicast stream is fairly constant.
PIM Sparse Mode
PIM sparse mode uses shared distribution trees. It does not assume that any routers want to receive the multicast, but instead waits to hear an explicit message from them, joining the group. Then it adds branches to the tree to reach the hosts behind those routers. PIM sparse mode uses RPs to connect hosts and servers. After the connection is made, PIM switches over to a source tree. Sparse mode is used when:
  • Pockets of users are widely dispersed around the network.
  • Multicast traffic is intermittent.
PIM Sparse-Dense Mode
An interface can be configured in sparse-dense mode. Then, if the router knows of an RP for its group, it uses sparse mode. Otherwise, it uses dense mode. In addition, it makes the interface capable of receiving multicasts from both sparse and dense-mode groups.


Configuring Multicast Routing and PIM

Use the following command to enable multicast routing:

(config)# ip multicast-routing

PIM mode must be configured at each interface with the following command. Configuring PIM on an interface also enables Internet Group Management Protocol (IGMP) on that interface:

(config-if)# ip pim {sparse-mode | dense-mode | sparse-dense-mode}

When using sparse mode, an RP must be specified. A router knows that it is an RP when it sees its own address in the command:

(config)# ip pim rp-address ip-address


Auto-RP
Auto-RP automates the discovery of RPs in a sparse or sparse-dense PIM network. RPs advertise themselves to a router designated as an RP mapping agent. The mapping agent then decides on one RP per group and sends that information to the other routers.

To configure a router as an RP, type the following:

(config)# ip pim send-rp-announce type number scope ttl group-list access-list-number

To configure a router as a mapping agent, type the following:

(config)# ip pim send-rp-discovery scope ttl


PIM Version 2
Cisco routers with recent versions of the IOS use PIM Version 2 by default. Some differences between PIM Version 1 and PIM Version 2 include:
  • PIM Version 1 is Cisco proprietary, whereas PIM Version 2 is standards-based.
  • Both versions can dynamically map RPs to multicast groups. PIM Version 1 uses an auto-RP mapping agent, and PIM Version 2 uses a bootstrap router (BSR).
  • PIM Version 1 uses a Time-to-Live value to bound its announcements, and PIM Version 2 uses a configured domain border.
  • In PIM Version 2, sparse and dense mode are group properties, not interface properties.

To configure PIM Version 2, configure at least one router as a BSR, and selected routers as RPs. To configure a BSR, use the following:

(config)# ip pim bsr-candidate interface hash-mask-length [priority]

To configure a router as a candidate RP, use the following:

(config)# ip pim rp-candidate type number ttl group-list access-list-number

Sunday, June 7, 2009

IP Multicast

A multicast is a single data stream sent from one source to a group of recipients. Examples might be a stock ticker or live video feed. Figure 7-3 shows an example multicast topology, as contrasted to unicast and broadcast.

Multicast Topolgy
Unicast Topolgy
In contrast, a unicast is traffic from one source to one destination (see Figure 7-2).


Broadcasting

A broadcast is traffic from one source to all destinations (see Figure 7-3). Broadcasts are not routed!Some features of multicast traffic are:
  • Multicast uses UDP, so reliability must be handled by the end host.
  • The sending host does not know the identity of the receiving hosts; it knows just a group IP addresses.
  • Group membership is dynamic. Hosts join a group, notify their upstream router, and the router begins forwarding data to them.
  • Hosts can belong to more than one group.
  • Hosts in a group can be located in many different places.

Monday, June 1, 2009

Configuring BGP

Table 6-1 lists the basic BGP configuration commands and their functions.


The BGP Network Command
In most IGPs, the network command starts the routing process on an interface. In BGP, the command tells the router to originate an advertisement for that network. The network does not have to be connected to the router; it just has to be in the routing table. In theory, it could even be a network in a different autonomous system (not usually recommended).

When advertising a network, BGP assumes you are using the default classful subnet mask. If you want to advertise a subnet, you must use the optional keyword mask and specify the subnet mask to use. Note that this is a subnet mask, not the inverse mask used by OSPF and EIGRP network statements. The routing table must contain an exact match (prefix and subnet mask) to the network listed in the network statement before BGP will advertise the route.


BGP Peering
BGP assumes that external neighbors are directly connected and that they are peering with the IP address of the directly connected interface of their neighbor. If not, you must tell BGP to look more than one hop away for its neighbor, with the neighbor ip-address ebgp-multihop number-of-hops command. You might use this command if you are peering with loopback interface IP addresses, for instance. BGP assumes that internal neighbors might not be directly connected, so this command is not needed with IBGP.

BGP Peering States
The command show ip bgp neighbors shows a list of peers, and the status of their peering session. This status can include the following states:
  • Idle—No peering; router is looking for neighbor. Idle (admin) means that the neighbor relationship has been administratively shut down.
  • Connect—TCP handshake completed.
  • OpenSent, or Active—An open message was sent to try to establish the peering.
  • OpenConfirm—Router has received a reply to the open message.
  • Established—Routers have a BGP peering session. This is the desired state.
You can troubleshoot session establishment with debug commands. Use debug ip bgp events or debug ip bgp ipv4 unicast (in IOS versions 12.4 and up) to see where the process fails. Some common failure causes include AS number misconfiguration, neighbor IP address misconfiguration, neighbor with no neighbor statement for your router, and neighbor with no route to the source address of your router’s BGP messages.


BGP Path Selection
IGP, such as EIGRP or OSPF, choose routes based on lowest metric. They attempt to find the shortest, fastest way to get traffic to its destination. BGP, however, has a very different way of route selection. It assigns various attributes to each path; these attributes can be administratively manipulated in order to control the path that is selected. It then examines the value of these attributes in an ordered fashion until it is able to narrow all the possible routes down to one path.


BGP Attributes
BGP chooses a route to network based on the attributes of its path. Four categories of attributes exist:
  • Well-known mandatory—Must be recognized by all BGP routers, present in all BGP updates, and passed on to other BGP routers. For example, AS path, origin, and next hop.
  • Well-known discretionary—Must be recognized by all BGP routers and passed on to other BGP routers, but need not be present in an update. For example, local preference.
  • Optional transitive—Might or might not be recognized by a BGP router, but is passed on to other BGP routers. If not recognized, it is marked as partial. For example, aggregator, community.
  • Optional nontransitive—Might or might not be recognized by a BGP router and is not passed on to other routers. For example, Multi-Exit Discriminator (MED), originator ID.
Table 6-2 lists common BGP attributes, their meanings, and their category.


Influencing BGP Path Selection
BGP was not created to be a fast protocol; it was created to allow as much administrative control over route path selection as possible. Path selection is controlled by manipulating BGP attributes, usually using route maps. You can set a default local preference by using the command bgp default local-preference and a default MED for redistributed routes with the default-metric command under the BGP routing process. But by using route maps, you can change attributes for certain neighbors only or for certain routes only. This is higher than the default local preference of 120, so routers within the AS are more likely to prefer that path than others.

Route maps can also be applied to routes sent to or received from a neighbor. The following example shows a simple route map that sets MED on all routes advertised out to an EBGP neighbor:

route-map MED permit 10
set metric 50
!
router bgp 65001
neighbor 10.1.1.1 route-map MED out

When attributes are changed, you must tell BGP to apply the changes. Either clear the BGP session (clear ip bgp * ) or do a soft reset (clear ip bgp * soft in | out). Routers using recent IOS versions will do a route refresh when the session in cleared inbound.


BGP Path Selection Criteria
BGP tries to narrow its path selection down to one best path; it does not load balance by default. To do so, it examines the path attributes of any loop-free, synchronized (if synchronization is enabled) routes with a reachable next-hop in the following order:
  1. Choose the route with the highest weight.
  2. If weight is not set, choose the route with the highest local preference.
  3. Choose routes that you advertise.
  4. Choose the path with the shortest autonomous system path.
  5. Choose the path with the lowest origin code (i is lowest, e is next, ? is last).
  6. Choose the route with the lowest MED, if the same autonomous system advertises the possible routes.
  7. Choose an eBGP route over an iBGP route.
  8. Choose the route through the nearest IGP neighbor.
  9. Choose the oldest route.
  10. Choose a path through the neighbor with the lowest router ID.
  11. Choose a path through the neighbor with the lowest IP address.
To enable BGP to load balance over more than one path, you must enter the command maximum-paths number-of-paths. BGP can load balance over a maximum of six paths.