ccie blog

IPv6 – Convert Hex to Binary

In binary, there is 8 bits in an octet. We are now going to half the octet and turn it into 4 bits (also known as a nibble). So our total maximum value is 1111, which in decimal equates to 15 (8+4+2+1). Another example is 1110 in binary, converted to decimal equates to 14 (8+4+2+0 = 14).

 

Hex value FE80 converted to Binary = 1111111010000000. How did I convert that without a calculator?

Each value in hex is worth 4 bits (1 nibble). What we do is convert it to decimal, then convert them to binary, as shown in the table below:

HexDecimalBinary
F151111
E141110
881000
000

Put all the binary numbers together in the order of FE80, and you get 1111111010000000.

How does traceroute work?

I’m gonna fly into an example so you can see what actually happens when you bang out a traceroute command on a router. In the network below, I’m going to traceroute from Sw1 to Sw2.

Sw1#traceroute 24.24.24.2

Type escape sequence to abort.
Tracing the route to 24.24.24.2

  1 13.13.13.3 0 msec 0 msec 9 msec
  2 34.34.34.4 0 msec 0 msec 0 msec
  3 24.24.24.2 8 msec *  0 msec
Sw1#

A wireshark capture was taken on Sw1, and this can be viewed online here (I recommend you open this file before reading on).

 

Traceroute can be explained in three main steps below.

1- Traceroute starts by sending 3 UDP packets with a TTL set to 1, towards the destination. Each UDP packet gets an ICMP reply with a Time-to-live  exceeded message. The key thing is that the IPv4 Source field is now filled with an IP address (13.13.13.3 – line 2 in the packet capture). This means 13.13.13.3 is now our first hop.

2- Sw1 then sends another 3 UDP packets to the destination with a TTL of 2. So the packet goes past the first hop (Sw3), gets to the second hop (Sw4), and another 3 ICMP TTL exceeded messages are sent back with the source IP field filled in (34.34.34.4 – line 8 in the packet capture). This means 34.34.34.4 is our second hop.

3- Sw1 then sends another 3 UDP packets to the destination with a TTL of 3. This time it actually reaches the destination, and we get an ICMP – Destination unreachable (Port unreachable) message back. Because we can actually reach the destination (at layer 3) and the TTL has not been exceeded, it now tries to reach the destination port (layer 4). This verifies that this is the final hop, and a TTL of 3 meant the destination was 3 hops away. It doesn’t matter that the port was unreachable, it was simply a test to get that port unreachable message back so that we know we moved up the OSI stack to layer 4, which verifies layer 3 is reachable.

The last thing is that traceroute always starts at port 33434 and increments by 1 each time a UDP packet is sent. You can see this in the packet capture. The first line shows the destination port is traceroute (which is 33434). The next red line shows 33435, then 33436 and so on.

Multicast Address Ranges

Link-Local

– 224.0.0.0/24 is the range used

– 224.0.0.1 – All Hosts

– 224.0.0.2 – All Routers

 

GLOP Addressing

– GLOP addressing is used to give anyone with their own registered public AS number their own globally unique multicast IP address range.

– 233.0.0.0/8 is the reserved GLOP range.

– 233.x.x.0/24 is the actual address you use, where x.x is the 2 bytes of your AS number.  If your AS was 54321, convert it to hex = D431.  Here D4 is the first byte, and 31 is the second byte.  D4 into Decimal is 212, and 31 into decimal is 49. So your range is 233.212.49.0/24

– The drawback is that it only works with 2 byte AS numbers

– GLOP doesn’t stand for anything, it’s just called GLOP

 

Administratively Scoped Addressess

– 239.0.0.0/8 is the reserved range

– IP addresses in this range should be filtered on the edge of the administrative boundary

– This range of IP’s are only guaranteed to be unique within the administrative boundary (eg, within the BGP AS)

 

Source Specific Multicast

–  232.0.0.0/8 is the reserved range for SSM

– Used to identify exactly what source & group a device wants to receive multicast traffic for

 

SDP/SAP

– 224.2.0.0/16 is the range used

 

Multicast Part 3: SPT Creation From Member to Source Using PIM-SM

The poster below details the final stage of joining a receiver to a source over the shorted path. Once the (*,G) has been created from receiver to RP, and the RP has created the (S,G) towards the source, the final stage is to get the receiver using the shortest path towards the source. Please click the poster below for more details.

Multicast Part 2: Multicast Source Sending Process With PIM-SM

The poster shows how a source (PC1) registers with an RP, and details how the (S,G) entries are created. Please click the poster below.

Multicast Part 1: Multicast Member Join Process

The poster below details how a host joins onto a multicast stream. It goes through each step, identifing how interfaces are added to the (*,G) tree. The information on the right shows some of the important IGMP timers. Please click the poster below.

OSPF – Point-To-Multipoint Network

This network type is useful in forcing traffic from multiple sites go via the HQ, or central location. In the example below, this means all traffic is going to flow through R3.

R1#
interface Serial0/0
 ip address 10.0.0.1 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.0.0.3 103 broadcast
 no frame-relay inverse-arp
!
router ospf 1
 router-id 1.1.1.1
 network 10.0.0.0 0.0.0.255 area 0
R2#
interface Loopback0
 ip address 99.99.99.99 255.255.255.255
 ip ospf network point-to-point
!
interface Serial0/0
 ip address 10.0.0.2 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.0.0.3 203 broadcast
 no frame-relay inverse-arp
!
router ospf 1
 router-id 2.2.2.2
 network 10.0.0.0 0.0.0.255 area 0
 network 99.99.99.99 0.0.0.0 area 0
R3#
interface Serial1/0
 ip address 10.0.0.3 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.0.0.1 301 broadcast
 frame-relay map ip 10.0.0.2 302 broadcast
 no frame-relay inverse-arp
!
router ospf 1
 router-id 3.3.3.3
 network 10.0.0.0 0.0.0.255 area 0

Read the rest of this entry »

OSPF – Non-broadcast (NBMA) Network

This network type is used on networks that have no broadcast/multicast capability, such as frame-relay, ATM, SMDS, & X.25. The key point is that these layer 2 protocols are unable to send broadcasts/multicasts. To show how critical this is, please see the diagram below.

– In the top (Ethernet) network, if R1 wanted to send some data to R2, then R1 would send a broadcast ARP with a layer 3 destination of 10.0.0.2 in order to discover the mac address of R2’s Fa0/0 interface. R1 would then forward the data to this MAC address.

– In the second diagram (Frame-Relay)  R3 is unable to send that broadcast ARP (like we could in the Ethernet scenario above). MAC addresses are only used on Ethernet networks, whereas Frame-relay uses the concept of DLCI’s at layer 2. So R3’s WAN interface must be statically configured with the layer 2 DLCI that it needs to use in order to reach R4 (commands such as #frame-relay map ip 10.0.0.4 304, or #frame-relay interface-dlci 304 (if using inverse-arp) could be used to achieve that). The point here is that it is not possible to send any layer 2 broadcasts across a frame-relay network.

Read the rest of this entry »

OSPF Broadcast Network

The beauty of this network type is the ability to multicast.  Take the network below. If each router were to use unicast in the hello protocol, each one would have to send 3 lots of hellos every 10 seconds in order to establish & maintain adjacencies. Instead multicast allows the router to send 1 hello to do the same job.  This best explained in the packet capture beneath.

I’ve taken a packet capture on R3’s fa0/0 interface. The result is shown below. You can see that each router is only sending one hello, and it’s destined to 224.0.0.5. The highlighted line, which is a packet sent from 10.0.0.3 (R3),  shows that R3 has active neighbors for routers 1.1.1.1, 2.2.2.2, and 4.4.4.4.  So when any of those routers receive the hello, they are aware that R3 knows about them. For example, R1 can see that R3 knows about him because R3 lists 1.1.1.1 as an active neighbor. This shows how just 1 multicast packet can be used instead of 3 unicast hellos.

Read the rest of this entry »

Hello Protocol On Each OSPF Network Type

Point-to-Point Network

– OSPF hellos are sent to the AllSPFRouters multicast address – 224.0.0.5

– Default timers are Hello 10 secs, Dead 40 secs

– No DR/BDR election (point-to-anything does NOT require a DR)

I have configured an ospf point-to-point network below to show the OSPF hello packets that are sent:

I’ve taken a packet capture that you can view online here: OSPF Point-to-Point Packet Capture.  The capture shows that packets are sent to the 224.0.0.5 AllSPFRouters address.  It also shows the DR/BDR ip address as 0.0.0.0, indicating that no DR/BDR election has occurred.  The command below shows the default timers on a point-to-point network.

R2#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
  Internet Address 24.0.0.1/24, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:05

 

Broadcast Networks

– OSPF hellos are sent to the AllSPFRouters multicast address – 224.0.0.5

– Default timers are Hello 10 secs, Dead 40 secs

– DR/BDR election occurs Read the rest of this entry »