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
Friday, September 10, 2010
CCNP - ENTERPRISE - 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
!
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
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
CCNP - ENTERPRISE - 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
Wednesday, September 8, 2010
CCNP - ENTERPRISE - 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.
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.
CCNP - ENTERPRISE - BGP - Neighbor States
When establishing neighbor sessions, BGP transitions through a number of states. These are:
- IDLE - router is searching routing table to see whether a route exists to the neighbor*
- CONNECT - Router found a route to the neighbor and 3 way TCP handshake is complete
- Open Sent - Open msg with parameters for BGP session is sent
- 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
- 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...
CCNP - ENTERPRISE - BGP - Message Types
As with all routing protocols there are a number of different messages types with differing duties/purposes.
For BGP we have:
For BGP we have:
- OPEN - Includes BGP version number, AS number (ASN), Hold Time, BGP router-id, other optional parameters such as Authentication criteria
- Keepalives - Exchanged to prevent the hold time expiring, where hold time is 0 keepalives are not sent. Keepalives are sent every 60seconds
- 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)
- Notification Messages - sent due to error condition being met. BGP connection is closed immediately after one of these is sent.
Tuesday, September 7, 2010
CCNP - ENTERPRISE - 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:
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
Tuesday, August 31, 2010
CCNP - ENTERPRISE - Manipulating Routing updates
So, this evening I've been battling Distribution lists and the appropriate application of them and for some reason I just couldn't get that external EIGRP route to be filtered out when redistributing in to OSPF.
After a bit of reading around I've figured out I was approaching it from the wrong end. Assume you have R1, R2, and R3. R1 is running EIGRP, R2 is performing redistribution in to EIGRP and OSPF, and OSPF is running on R3.
My error was that I was working on R2 and wondering why it was that I had configured my access-list to deny my chosen route, applied the cmd - #distribution-list 1 out ospf 1 within the #router ospf 1 process, and nothing had happened.
The problem I was encountering was that in order for OSPF to properly calculate the shortest path, all the Link-State Databases through out your area must be synchronised. As such you can't simply deny your chosen network on the redistributing router as the network would not then be in synch.
The solution was to log on to R3, the router I wanted to have the route filtered from. Create the access list to deny the chosen route (then permit any - remember the implicite deny that would otherwise take affect). I then entered #distribution-list 1 in, from within the ospf routing process and job done! My desired route if filtered out and the rest remain.
Configuration:
R3(config)#access-list 4 deny 172.16.4.0 0.0.0.255
R3(config)#access-list 4 permit any
!
R3(config)#router ospf 1
R3(config-router)#network 10.10.0.0 0.0.255.255 area 0
R3(config-router)#network 192.168.12.0 0.0.0.255 area 0
R3(config-router)# distribute-list 4 in
!
After a bit of reading around I've figured out I was approaching it from the wrong end. Assume you have R1, R2, and R3. R1 is running EIGRP, R2 is performing redistribution in to EIGRP and OSPF, and OSPF is running on R3.
My error was that I was working on R2 and wondering why it was that I had configured my access-list to deny my chosen route, applied the cmd - #distribution-list 1 out ospf 1 within the #router ospf 1 process, and nothing had happened.
The problem I was encountering was that in order for OSPF to properly calculate the shortest path, all the Link-State Databases through out your area must be synchronised. As such you can't simply deny your chosen network on the redistributing router as the network would not then be in synch.
The solution was to log on to R3, the router I wanted to have the route filtered from. Create the access list to deny the chosen route (then permit any - remember the implicite deny that would otherwise take affect). I then entered #distribution-list 1 in, from within the ospf routing process and job done! My desired route if filtered out and the rest remain.
Configuration:
R3(config)#access-list 4 deny 172.16.4.0 0.0.0.255
R3(config)#access-list 4 permit any
!
R3(config)#router ospf 1
R3(config-router)#network 10.10.0.0 0.0.255.255 area 0
R3(config-router)#network 192.168.12.0 0.0.0.255 area 0
R3(config-router)# distribute-list 4 in
!
CCNP - ENTERPRISE - Routing Protocol Metrics
Continuing the theme of grouping together common attributes/characteristics (see my posts on Summarisation and Authentication), in this article I'm going to set out the Metric for each routing protocol tested on the BSCI.
RIPv2 : Distance Vector protocol
Metric = Hop count, 1-15, with 16 being 'infinity' or unreachable
EIGRP: Advanced Distance Vector protocol
Metric = Calculation based on Bandwidth (K1), Load(K2), Delay(K3), Reliability(K4), MTU (K5) although MTU is tracked through the path to find the smallest MTU - it is NOT used in the metric calculation.
Calculation is: Metric = 256*([K1*Bw + K2*Bw/(256-Load) + K3*Delay]*[K5/(Reliability + K4)])
Where:
[K5/(Reliability + K4)] is disregarded if K5 = 0
Default K-values in use are K1 and K3 therefore is you use the default settings the default metric is based on Bandwidth and Delay.
OSPF: Link-State routing protocol
Metric = Cost where cost is calculated by - cost= 10000 0000/bandwith in bps
Metric = Arbitrary value between 0 -63, you decide what it means. Default value is 10
RIPv2 : Distance Vector protocol
Metric = Hop count, 1-15, with 16 being 'infinity' or unreachable
EIGRP: Advanced Distance Vector protocol
Metric = Calculation based on Bandwidth (K1), Load(K2), Delay(K3), Reliability(K4), MTU (K5) although MTU is tracked through the path to find the smallest MTU - it is NOT used in the metric calculation.
Calculation is: Metric = 256*([K1*Bw + K2*Bw/(256-Load) + K3*Delay]*[K5/(Reliability + K4)])
Where:
[K5/(Reliability + K4)] is disregarded if K5 = 0
Default K-values in use are K1 and K3 therefore is you use the default settings the default metric is based on Bandwidth and Delay.
OSPF: Link-State routing protocol
Metric = Cost where cost is calculated by - cost= 10000 0000/bandwith in bps
- The Cost is an indication of the overhead required to send a packet over a specified interface.
- Cost is inversely affected by the bandwidth, the greater the bandwidth the lower the cost
- The Cost of the outbound interface is used
- To change the Cost of a given interface and therefore influence path selection you apply the command #ip ospf cost [cost value] to the outbound interface concerned
Metric = Arbitrary value between 0 -63, you decide what it means. Default value is 10
- To fine tune IS-IS you manually assign a metric value to each interface configured for IS-IS
- Similar to the OSPF bandwidth
- use the cmd #isis metric [metric] [level1| level2] to change the metric and assign it the appropriate routing level.
BGP: Distance Vector exterior routing protocol
Metric - is the Multi-Exit Discriminator value.
- the Lower the MED the better
- Used to decided how to enter an AS
- Default is 0
- Optional, Non-transitive
- Usually only shared between 2 AS's that have multiple eBGP connections with each other
Monday, August 30, 2010
CCNP - ENTERPRISE - Manipulating Routing Updates - Routing Table Codes
I got caught out during some practice questions on routing table codes. So I thought it might be an idea to list the out put from #sh ip route and just set down what they are.
Simple question to nail - given the codes [X, Y, Z] which is the least trust worthy. I should have had this down from my CCNA but there you are. You need to first understand what the code is, then cross reference it with a suitable Administrative Distance. (Check my Charts and Table page above if you're unsure of the AD for a given protocol)
Protocol code:
C - connected,
S - static,
R - RIP,
M - mobile
B - BGP
D - EIGRP,
EX - EIGRP external,
O - OSPF,
IA - OSPF inter area
N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type 2
E1 - OSPF external type 1,
E2 - OSPF external type 2
i - IS-IS,
su - IS-IS summary,
L1 - IS-IS level-1,
L2 - IS-IS level-2
ia - IS-IS inter area,
* - candidate default,
U - per-user static route
o - ODR,
P - periodic downloaded static route
Simple question to nail - given the codes [X, Y, Z] which is the least trust worthy. I should have had this down from my CCNA but there you are. You need to first understand what the code is, then cross reference it with a suitable Administrative Distance. (Check my Charts and Table page above if you're unsure of the AD for a given protocol)
Protocol code:
C - connected,
S - static,
R - RIP,
M - mobile
B - BGP
D - EIGRP,
EX - EIGRP external,
O - OSPF,
IA - OSPF inter area
N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type 2
E1 - OSPF external type 1,
E2 - OSPF external type 2
i - IS-IS,
su - IS-IS summary,
L1 - IS-IS level-1,
L2 - IS-IS level-2
ia - IS-IS inter area,
* - candidate default,
U - per-user static route
o - ODR,
P - periodic downloaded static route
Subscribe to:
Posts (Atom)