BSCI Exam - Passed!

Well, I've just got back from the test centre and I'm pleased to say that I passed!!

It was a bit touch and go though as I think there was about 1 minute 30 seconds left on the clock.

No rest though as I've already started CCNP SWITCH at my local Cisco Networking Academy.

As you'll guess, most posts from now on will be SWITCH related.

Thanks
Jonathan

BSCI - OSPF - Adjacency requirements

For an OSPF adjacency to form the 2 neighbors must agree on several parameters within the Hello Packet before the adjacency can form. These are:

i) Each must have a unique Route-ID
ii) Each must be in the same Area
iii) Authentication setting must match
iv) Timers must match.

One other parameter that must be agreed upon is the router priority for DR/DBR elections.

BSCI - Manipulating Routing Updates - Route-map permissions

When compiling a Route-map(RM), you set an access control list (ACL) then use the Route-map to match addresses set out in that ACL to apply your chosen criteria in the Set field of the Route-map.

Now the question is given the combination of permit or deny statements in the ACL and the permit or deny statement of the Route-map what is the out come for a packet.

The following is what happens to a given packet when the permit or deny statements are considered:

ACL = Permit
RM= Permit
Result = Packet Permitted to proceed via the route-map. That's to say the packet is permitted to be permitted.

ACL = Deny
RM = Permit
Result = Packet Denied. The packet is denied from being permitted.

ACL = Permit
RM = Deny
Result = Packet Denied. The packet is permitted to be denied.

ACL = Deny
RM = Deny
Result = Packet PERMITTED. The packet is denied from being denied. If it isn't allowed to be denied, it must, therefore, be permitted.

Bit of a weird one to get your head round but it's an obvious trick to chuck in there when you're under pressure so keep an eye out.

BSCI - IPv6 - IP address types

The following is a list of IPv6 address types. The high order bits are displayed and their function:

i) 001 = Global - 200
ii) 1111 1111 = Multicast - FF
iii) 1111 1110 11 = Site Local - FEC0
iv) 1111 1110 10 = Link Local - FE80
v) ::X:X:X:X = IPv4 compatible address, where the first 96 bits are set to 0 (hence the ::) and the remaining 32 bits are converted to hex from the IPv4 address

Other addresses include:
::1 or 0:0:0:0:0:0:0:1 = Loopback
::/128 = unspecified address which is essentially the DFG for IPv6, all the bits are set to 0.
IPv6 private addresses start - 1111 1110 1 - therefore both site local and link local are private

BSCI - EIGRP - Adjacency Requirements

The following criteria need to be meet before an EIGRP adjacency will form:
i) Authentication (if in place)
ii) AS Number
iii) Source IP MUST be the primary address for the interface - secondary IP's will not result in the adjacency forming
iv) K values must match

N.B. - Timers do not have to match but they must be equal.
- Adjacency will flap if timers are mismatched.
- Therefore ensure you have a reliable time source.

BSCI - ISIS - Adjacency requirements

For an ISIS adjacency to come up the following criteria must match:
i) MTU  - default is 1497
ii) Router Levels - L1, L1/L2, L2 only
iii) If L1 router, the IS must be in the same area
iv) System ID's must be unique
v) Authentication (if used)

Adjacency is formed after a 3-way handshake. The stages are DOWN - INIT- UP

The adjacency is up if the neighbor has put you identity in their hello packet.

BSCI - ISIS - Show commands

The following show commands can be used for ISIS:

#sh ip protocols
-Displays: active interfaces, routing information sources (neighbors), whether summarisation is in effect, last update

#sh clns protocols
-Displays: System ID, ISIS router type (L1| L1/L2| L2), Area IS, active interfaces

#sh clns neighbor
-Displays:  Single Line summary of neighbors, system id NAMES, SNPA, State (Up or Down), hold time, router type, protocol

#sh clns neighbor detail
- Displays: multi-line details of neighbors, neighbor info, Area ID, up time, ip of neighbor

#sh isis database
-Displays:  L1/L2 routers you see 2 Db's, * indicates the DIS (which is elected either via the interface cmd #isis priority [number] or is a priority is not set the DIS is the device with the highest SNPA which in this case it the Ethernet MAC address on the router)

#sh isis topology
- Displays: system, metric, next-hop, egress interface to get to next-hop, SNPA of next-hop router

BSCI - Creating/Converting addresses

One easy way to pick up marks in the BSCI exam is to practise creating or converting addresses in one format to another, quickly.


So far I've spotted 4 situations where you would be asked to identify suitable converted addresses for a given address.


These are:
1) Identify the correct Multicast MAC address for a given Multicast IP addresses
- Multicast MAC addresses always start 01-00-5e. You need to find the last 23 bits to add to these first 25 bits to create a 48bit MAC.
- Take you Multicast IP and convert to binary
- section off the last 23 bits starting from the RIGHT in to 4 bit sections. the last section will contain only 3 bits so to get a Hex figure for this just tack a 0 on to the start of it. 
- Next convert your binary to Hex
- Finally add these to the 01-00-5e to get your Multicast MAC
e.g - 224.90.17.43
Binary = 11100000.0 101 1010. 0001 0001 0010 1011
Hex -                      | 5 |  A |  1   |  1  |   2   |   B
MAC = 01-00-5e-5a-11-2b


2) When regarding IPv6 6to4 tunnels, identify a suitable IPv6 address for a given IPv4 address that is assigned to a physical interface.
-  Using a Global address you know 2 things A) the high order bits always start 001 = 2000::/3 and generally end with 0001 in the first 16bits and B) a Global prefix is 48 bits long ( or /48). With this in mind  you know your first 16 bits, 0010 0000 0000 0001: X:X:X:X:X:X:X, so you are looking for the remaining 32 bits to form the address
- Copy out into binary the IPv4 address of the physical interface the tunnel will be associated with then convert it to hex, e.g.) 192.168.99.1
    1100 0000. 1010 1000. 0110 0011. 0000 0001
      c     0        a      8       6     3      0     1

- Combine this with your first 16 bits and you have your Global IPv6 to apply to your tunnel interface
     2001:c0a8:6301::/48

3) Given the ASN 5662 what would a suitable GLOP address be.

- For this type of question you know that the 1st octet is always 233 and you can choose what the last octet can be (1-255) so you need to calculate the 2nd and 3rd octet values.

- Take the ASN 5662

-Convert it to binary and pad the left of the binary figure with zero's until you have 16 bits (octets 2 and 3 combined) -0001011000011110

- Divide the 16 bits in 2 and you are left with 2 octets (8bits each)

- convert these to decimal - 00010110 = 22, 00011110 = 30 and add to you GLOP address starting 233.X.X.X

- GLOP addresses always have /24 subnet mask because the implementer can select 255 addresses to be assigned locally. As a result in this example the GLOP address will be 233.22.30.XXX/24

4) Finally there is the question that asked you about subnetting. Be it a host is not communicating (it has the wrong subnet mask), Which path would the router select (you need to work out the correct Network in a routing table for a given IP), will a packet be permitted or denied in the ACL (again you need to work out if your IP is with the range permitted or denied with in the subnet mask stated) 

- For all these types of questions you are looking at basic subnetting. Aim to get these calculations down to less the 20 SECONDS. 

- Imagine a slide ruler in your head. Slide it to the where the subnet mask stops and bang, you have your subnet increments. From here you know the Network address, 1st host in the subnet, last host in the subnet, broadcast address for the subnet, and the next network address.

- Practise this over and over until you can see in your head the octet with the bit values and where you stop for each subnet.

If you can get each of the situations above nailed, and nailed quickly you can buy time on the harder questions. Practice, practice, and practice again.

BSCI - Multicast - Address scopes

Multicast uses a reserved Class D with the first 4 high order bits in the 1st octet assigned 1110.

Therefore you can work out that the address range assigned for Multicast is 224.0.0.0 to 239.255.255.255

IANA then broke the address scope down further:
1) Locally Scoped, Reserved Link Local, addresses:
224.0.0.0 to 224.0.0.255
This range is the IANA 'well known' multicast range which includes your addresses for EIGRP (224.0.0.10), OSPF (224.0.0.5 and 224.0.0.6) RIPv2 (224.0.0.9) PIMv2 (224.0.0.13)

2) Globally Scoped addresses: - 224.0.1.0 to 238.255.255.255
-These can be allocated dynamically across the internet
-GLOP addresses fall into this scope (233.0.0.0/8)
-224.2.X.X was allocated to the 'MBone' or Multicast Backbone which is now a defunct technology due to little uptake by large institutions and the resources required by the equipment to manage the multicast traffic.

3) Limited (administratively) scoped addresses: - 239.0.0.0 to 239.255.255.255
- Reserved for inside corporate networks, similar to private IP's
- Organisations can use limited scoped addresses for local multicast apps

This range was further subdivided in to:
239.192.0.0 to 239.251.255.255
- Organisation wide scoped addresses

239.255.0.0/16 - site local address.

BSCI - Multicast - GLOP addresses

The GLOP address range, (pronounced GLOP not G-L-O-P), was originally specified in RFC2770 and was an experimental, public, statically assigned multicast address for publishers and ISP's to source content on the internet.

The method of assigning one of these experimental address was called GLOP. Implementers were assigned 255 addresses from the 233.0.0.0/8 subnet. The actual address assigned was determined from the ASN the implementer already used.

The address assigned set out the values of the 2nd and 3rd octet of the GLOP address. That is to say, all GLOP addresses start 233 (octet #1), the you had octet #2 and #3 to allocate, and finally you knew you had 255 addresses to choose from so the 4th octet was always a value of your choice 1-255.

Octet 2 and Octet 3 were determined by a calculation involving the ASN already assigned to the implementer and therefore, in theory, the GLOP address that resulted was unique (i.e. - not allocated to another organisation).

To determine the value of octet #2 and octet #3 do the following: (example taken from RFC2770)
i)Take the ASN 5662
ii)Convert it to binary and pad the left of the binary figure with zero's until you have 16 bits (octets 2 and 3 combined) - 0001011000011110
iii)Divide the 16 bits in 2 and you are left with 2 octets (8bits each)
iv) convert these to decimal - 00010110 = 22, 00011110 = 30 and add to you GLOP address starting 233.X.X.X
v) GLOP addresses always have /24 subnet mask because the implementer can select 255 addresses to be assigned locally. As a result in this example the GLOP address will be 233.22.30.XXX/24

Further reading:
http://www.faqs.org/rfcs/rfc2770.html

BSCI - Manipulating Routing Updates - Private IP address scopes

RC 1918 states that IANA has assigned the following ranges to be 'Private'

10.0.0.0        -   10.255.255.255  (10/8 prefix)

172.16.0.0      -   172.31.255.255  (172.16/12 prefix)

192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

BSCI - OSPF - Default Path Cost values

The OSPF metric is cost, which is calculated using the equation 100Mbps/Bandwidth of interface.

The 100Mbps is a reference bandwidth which is applied in order to calculate the Cost of an interface. The Cost is an indication of the overhead to send packets across that link. Lower Costs are better.

OSPF uses the following default metric costs for different types of interface:
56K dial-up - 1785
T1 (1.544Mbps serial link) - 64
E1 (2.048Mbps serial link) - 48
Ethernet - 10
100Mb Fast Ethernet - 1
1000Mb Gigabit Ethernet - 1

The default OSPF Cost is used to calculate the best path. The best path is then entered in to the routing table (assuming there isn't another protocol with a better AD with the same path).

In order to refine your traffic shaping you can change the reference bandwidth so that you can determine the best path when considering FE and GE links, as you'll note that the default cost is the same and there fore determining the best path between the two could result in sub-optimal routing.

To change the reference bandwidth do:
R1(config)#router ospf 1
R1(config-router)#auto-cost reference-bandwidth [ref-bw]
!where ref-bw can be a value of 1-4294967

To override the default cost value that would result from the values stated above, you can manually set a cost value on an interface:
R1(config)#int s0/0
R1(config)#ip ospf cost [int-cost]
!where int-cost is a value of 1 -65535

BSCI - EIGRP - Metric Weights

When redistributing another routing protocol in to EIGRP you need to specify the metric weights in order to redistribute the routes correctly and efficiently.

The command you need to perform redistribution is:
R1(config)#router eigrp 1
R1(config-router)#redistribute ospf 1 metric 1500 10 255 10 1500
!

Alternatively you can define a 'Seed' metric which is applied to all redistributed routes and so you don't need to specify the individual metrics each time.

R1(config)#router eigrp 1
R1(config-router)#default-metric 1000 100 250 100 1500
R1(config-router)#redistribute ospf 1
!

The values stated above represent each of the values for the EIGRP metric:

R1(config-router)#default-metric bandwidth delay reliability loading mtu 

In both of the examples above you are manually setting out the metric for the routes once they are redistributed in to EIGRP.

If you fail to set either a default metric or a specific metric in your redistribute command then EIGRP will assign a metric of 'infinity' and the routes will fail. So if you end up scratching you head wondering why your desired routes don't appear in the routing table take a look at your metrics.

The metric set out above represent the K-values for each of the criteria that make up the EIGRP Metric. The K values are:
i) Bandwidth (K1) - Minimum bandwidth along the path in Kbps. This is a value of 1 - 4294967295
ii) Load (K2) - Used as a way of managing traffic off heavily used links. Value is 0 to 255 where 255 equals is 100% utilisation of the available bandwidth
iii) Delay (K3) - Latency of the path in 10's of Microseconds. This is a value of 1 - 4294967295
iv) Reliability (K4) - A value representing how likely the path is to be available or fail. Value is between 0 and 255, with 255 equalling 100% reliable.
v) MTU (K5)- Used to set a path MTU for a given route. Value is 1 - 65535

BSCI - OSPF - NBMA network types review

One of the things I have trouble with is remembering the different characteristic's of each of the OSPF network types.

Below is a chart simply highlighting each point.

For configuring each network type please refer to my earlier posts.

Cheers

BSCI - BGP - Neighbor States Notes

If a router stays in an IDLE condition check:
i) If the neighbor announces the route in it's local IGP
ii) Verify you have not entered an incorrect IP in your neighbor statements

If a router enters or remains in ACTIVE state it could be because:
i) Neighbor doesn't have a route to the source IP of the BGP Open packet generated by the router - check the routing table on the neighbor and add a suitable route via a static entry or an IGP if one is missing.
ii) The neighbor is peering with the wrong address - check neighbor statements via #sh run
iii) The neighbor doesn't have a neighbor statement for this router - add one!
iv)The AS number in the neighbor statement is misconfigured on one or both peers. - check the neighbor statements for a mis-typed Remote-AS entry.

BSCI - BGP - Neighbor States

When establishing neighbor sessions, BGP transitions through a number of states. These are:

1. IDLE - router is searching routing table to see whether a route exists to the neighbor*
2. CONNECT - Router found a route to the neighbor and 3 way TCP handshake is complete
3. Open Sent - Open msg with parameters for BGP session is sent
4. Open Confirm  - Router received an agreement on the parameters to establish a session. Alternatively, the router enters ACTIVE state is not responds is received to the Open Sent msg
5. ESTABLISHED - peering established, routing begins.

To view this activity you can use the debug options to see the process in action.

Configuration:

R1#debug ip bgp all

!

R1#debug ip bgp events

!

Remember, a debug is processor intensive so remove the debug once you are finished:

R1#undebug all 

OR

R1#u all 

!

*I can't remember if I've already stated this but in the UK the word is spelt NEIGHBOUR. For consistency with Cisco IOS commands I'm spelling it NEIGHBOR when I need to use the word. Thought I'd just clarify that as I'm not some dumb ass that can't spel. ...erm...

BSCI - BGP - Message Types

As with all routing protocols there are a number of different messages types with differing duties/purposes.

For BGP we have:

1. OPEN - Includes BGP version number, AS number (ASN), Hold Time, BGP router-id, other optional parameters such as Authentication criteria
2. Keepalives - Exchanged to prevent the hold time expiring, where hold time is 0 keepalives are not sent. Keepalives are sent every 60seconds
3. UPDATE - information on 1 path only. Multiple paths require multiple update messages. All attributes in an update refer to the path. This includes - Withdrawn routes, Path attributes, Network Layer Reachability (list of ip prefixes reachable via the path)
4. Notification Messages - sent due to error condition being met. BGP connection is closed immediately after one of these is sent.

BSCI - BGP - Synchronisation

Synchronisation rule states that a BGP router can not advertise an external neighbor destination from iBGP peers unless that route is also known via an IGP (such as EIGRP, OSPF, RIPv2 etc.)

The thinking behind this is that in the event that a router along the path to the destination is not running BGP then you don't end up with a black hole with packets getting dropped. The IGP has a route the the destination so a path will still exist.

By default, Synchronisation is switched off in Cisco IOS an and there fore BGP can advertise a route without it first being advertised by an IGP.

There are 2 situations when you can safely switch off synchronisation:

• When you have a fully meshed iBGP topology - resulting in the destination being reached with the need of an IGP
• When the AS is NOT an transit AS - where all destination networks are within the AS and accessible due to you having a full mesh iBGP topology.

Configuration:

R1(config)#router bgp 123

R1(config-router)#synchronization

!

!This turns on synchronisation (which is disabled by default)

R1(config)#router bgp 123

R1(config-router)#no synchronization

!

!This turns off synchronisation