Friday, December 10, 2010

Password recovery on a Catalyst switch

Part of the preparation work for my home lab is to clear off the old config on the recycled systems. This includes performing a password reset.

The steps on my catalyst switches are as follows:

  1. Access ROMMON - power off the device, press the Mode button on the front, connect the power. When the 'x1' LED goes out release the Mode button and ROMMON will be presented in your terminal
  2. Enable Flash - ROMMON: flash_int
  3. Enter the Following cmd - :loader_helper
  4. Check the directory structure - : dir flash:
  5. Rename the Startup-config file - :rename flash:config.text flash:config.bak
  6. Restart the system - :boot
  7. At the prompt enter 'no', you do not wish to run through the automation steps
  8. At this point you can either stop here and run the system as a fresh system or you can continue
  9. Rename the config.old back to config.text - switch#rename flash:config.bak flash:config.text
  10. Next, load the config file in the memory - switch#copy flash:config.text system:running-config
  11. At this point you are now running your original config. All you need to do now is reset all your access passwords
  12. Change the Enable Secret - switch(config)#enable secret [Secret]
  13. Change the Enable Password - switch(config)#enable password [Password]
  14. Change the Telnet password - switch(config)#line vty 0 4; switch(config-line)#password [Password] 
  15. Set the VTY line to prompt for the password - switch(config-line)#login
  16. Finally, save your running-config - switch#wr mem

How to access ROMMON

In your working environment how often do you really need to access ROMMON? if everything is in order and you have up to date documentation then I suspect not very often.

So, I come to preparing my new home lab for my CCNP SWITCH course and I've had to remove the old configuration off the recycled kit.

For my access server I'm going to run an old 2610 router, not the most feature rich router but it has a single ethernet interface which I run inter-VLAN routing off. I have 2 catalyst 3550's for my distribution layer and I have 2 Catalyst 2950's for the access layer.

Accessing ROMMON.
Accessing ROMMON is actually very simple on the catalyst switches. Power off your device. Hold the mode button down on the front of the box, then connect the power lead.

Wait for the 'x1' interface indicator to go out and then release the mode button.

For the 2610 you power cycle the system and at the point the boot process is displayed on screen you hit ctrl+Break.

Thursday, December 9, 2010

To 'Delete' or to 'Erase'?

When do you use the commands Delete or Erase?

Well it depends on what you are wanting to do.

If you want to remove a file, you use the delete cmd, for example:
R1#delete flash:config.old
or
SW1#delete vlan.dat

If you want to remove system information you use the erase cmd, for example:
R1#erase startup-config

If in doubt use the ? to inspect your options:
R1#?

Saturday, November 13, 2010

Tuesday, October 26, 2010

Subnet Mask vs Wildcard Mask

Something I find I struggle with is when to use a subnet mask and when to use a wildcard mask. This article is to simply set out the instances when you will use one or the other (not the actual steps to apply them).

Subnet Mask:

  • When applying an IP to an interface
  • Routing protocol summary addresses
  • BGP
  • PIX security appliance ACL's
  • ASA security appliance ACL's
  • When creating DHCP pools on a Switch or Router

Wildcard Mask:
  • EIGRP network statements
  • OSPF network statements
  • VPN concentrator network lists (when setting the local and remote allowed networks)
  • Router ACL's
This list is not exhaustive and I will add to it as I come across new instances where you use either a Subnet mask or Wildcard mask. 

Friday, September 17, 2010

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

Wednesday, September 15, 2010

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.

Tuesday, September 14, 2010

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

Sunday, September 12, 2010

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

Friday, September 10, 2010

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














Wednesday, September 8, 2010

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.

Tuesday, September 7, 2010

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

Tuesday, August 31, 2010

BSCI - 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
!

BSCI - 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

  • 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
IS-IS: Link-State routing protocol
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

BSCI - 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

BSCI - BGP - Route Reflectors

A route reflector acts like a DR (for OSPF) or DIS (in IS-IS) where it acts as a central location where multiple BGP routers can peer with it. The Route Reflector is the Server and all other BGP peers are clients.

The benefit of this is that you can by pass the Full Mesh requirement the iBGP requires. Instead a Route Reflector server propagates routes to the peers. A Route Reflector advertises a route learned from one iBGP peer to another iBGP peer. (remember by it's very nature iBGP peers to not forward updates received as it is assumed the network is a Full Mesh. The use of a Route Reflector helps cuts down the admin required for a Full Mesh configuration.

If you had 10 routers, in a full mesh you'd be looking at 100 specific statements across the network. Introducing a Route Reflector cuts this down to 20 statements (11 on the RR and 9 across the remaining 9 routers).

There are rules on how a Route Reflector will propagate routes within the iBGP AS.
1) If a route is received from a non-client peer ( a BGP peer not using a route reflector), reflect to clients only
2) If a route is received from a client peer, refelct to all non-client peers AND client peers, except the originator of the route
3) If a route is received from an eBGP peer, reflect to all client and non-client peers.

Configuration:
Clients require no configuration at all. Process is transparent. Just configure your neighbor statements as usual.

On the Route Reflector:
R1(config)#router bgp 100
R1(config-router)#neighbor 172.16.10.1 route-reflector-client
R1(config-router)#neighbor 172.16.20.1 route-reflector-client
!
Note that when configuring the neighbor as a route reflector client the adjacency will go down and back up.

That's it. R1 will 'reflect' routes to the clients set out in the neighbor statements.

Verify your route reflector clients using:
R1#sh ip bgp neighbor
!
The out put will be quite lengthy but there will be a statement in the output highlighting the 'Route Reflector Client'

Sunday, August 29, 2010

BSCI - OSPF - Network Types - Point-to-Multipoint Non-Broadcast

Point-to-Multipoint Non-Broadcast:

  • Cisco proprietary
  • Single subnet required
  • No DR/BDR elected
  • Neighbors specifically configured - this is the difference between standard and Cisco Point-to-Multipoint
Configuration:
R1(config)#interface Serial0
R1(config-if)#ip address 192.168.10.1 255.255.255.0
R1(config-if)#ip ospf network point-to-multipoint non-broadcast
R1(config-if)#encapsulation frame-relay
R1(config-if)#frame-relay local-dlci 100
R1(config-if)#frame-relay map ip 192.168.10.2 102
R1(config-if)#frame-relay map ip 192.168.10.3 103
R1(config-if)#frame-relay map ip 192.168.10.4 104
R1(config-if)#no shut
!
R1(config)#router ospf 1
R1(config-router)#network 192.168.10.0 0.0.0.255 area 0
R1(config-router)#neighbor 192.168.10.2
R1(config-router)#neighbor 192.168.10.3
R1(config-router)#neighbor 192.168.10.4
!

On R2:
R2(config)#interface S0/0
R2(config-if)#ip address 192.168.10.2 255.255.255.0
R2(config-if)#encapsulation frame-relay
R2(config-if)#ip ospf network point-to-multipoint non-broadcast
R2(config-if)#frame-relay local-dlci 201
R2(config-if)#frame-relay map ip 192.168.10.1 201
R2(config-if)#no shut
!
R2(config)#router ospf 1
R2(config-routrer)#network 10.0.1.0 0.0.0.255 area 0
!

BSCI - OSPF - Network Types - Broadcast

Broadcast:

  • Cisco proprietary
  • Full mesh required
  • Single subnet required
  • DR/BDR elected
  • Timers = 10 seconds
Configuration:
Lacking a diagram, assume we have 4 routers in a hub and spoke design. R1 is the Hub and R2,R3, and R4 are spoke routers. Frame-relay is in use.

On R1:
R1(config)#router ospf 1
R1(config-router)#network 192.168.1.0 0.0.0.255 area 0
!
R1(config)#int s0/0
R1(config-if)#ip address 192.168.1.1 255.255.255.0
R1(config-if)#encapsulation frame-relay
R1(config-if)#ip ospf network broadcast
R1(config-if)#ip ospf priority 10
R1(config-if)#frame-relay map ip 192.168.1.2 102 broadcast*
R1(config-if)#frame-relay map ip 192.168.1.3 103 broadcast
R1(config-if)#frame-relay map ip 192.168.1.4 104 broadcast
!
*broadcasts and multi-casts are now forwarded

On R2:
R2(config)#router ospf 1
R2(config-router)#network 192.168.1.0 0.0.0.255 area 0
!
R2(config)#int s0/0
R2(config-if)#ip address 192.168.1.2 255.255.255.0
R2(config-if)#encapsulation frame-relay
R2(config-if)#ip ospf network broadcast
R2(config-if)#ip ospf priority 0
R2(config-if)#frame-relay map ip 192.168.1.1 25 broadcast
R2(config-if)#frame-relay map ip 192.168.1.3 25 broadcast
R2(config-if)#frame-relay map ip 192.168.1.4 25 broadcast
!

On R3:
R3(config)#router ospf 1
R3(config-router)#network 192.168.1.0 0.0.0.255 area 0
!
R3(config)#int s0/0
R3(config-if)#ip address 192.168.1.3 255.255.255.0
R3(config-if)#encapsulation frame-relay
R3(config-if)#ip ospf network broadcast
R3(config-if)#ip ospf priority 0
R3(config-if)#frame-relay map ip 192.168.1.1 35 broadcast
R3(config-if)#frame-relay map ip 192.168.1.2 35 broadcast
R3(config-if)#frame-relay map ip 192.168.1.4 35 broadcast
!

On R4:
R4(config)#router ospf 1
R4(config-router)#network 192.168.1.0 0.0.0.255 area 0
!
R4(config)#int s0/0
R4(config-if)#ip address 192.168.1.4 255.255.255.0
R4(config-if)#encapsulation frame-relay
R4(config-if)#ip ospf network broadcast
R4(config-if)#ip ospf priority 0
R4(config-if)#frame-relay map ip 192.168.1.1 45 broadcast
R4(config-if)#frame-relay map ip 192.168.1.2 45 broadcast
R4(config-if)#frame-relay map ip 192.168.1.3 45 broadcast
!

In the example above you should note that R1 has a priority of 10 manually configured whilst R2, R3, and R4 each have their ospf priority set to 0. This will ensure that regardless of any future configuration R1 will always be the OSPF DR.

BSCI - OSPF - Network Types - Point-to-Point

Point-to-Point:

Uses Sub-Interfaces
Sub-interfaces used to address Split-Horizon issues that can result in using a single physical interface
Separate sub-interfaces require separate subnets
No DR/BDR elections
Neighbors automatically form.

Configuration:
Lacking a diagram, assume we have 4 routers in a hub and spoke design. R1 is the Hub and R2,R3, and R4 are spoke routers. Frame-relay is in use.

On R1:
R1(Config)#router ospf 1
R1(config-router)#network 192.168.0.0 0.0.255.255 area 0
!
R1(config)#int s0/0
R1(config-if)#encapsulation frame-relay
R1(config-if)#no shutdown
!
R1(config)#int s0/0.102 point-to-point
R1(config-if)#description Link_To_R2
R1(config-if)#ip addr 192.168.12.1 255.255.255.252
R1(config-if)#frame-relay interface-dlci 102
!
R1(config)#int s0/0.103 point-to-point
R1(config-if)#description Link_To_R3
R1(config-if)#ip addr 192.168.13.1 255.255.255.252
R1(config-if)#frame-relay interface-dlci 103
!
R1(config)#int s0/0.104 point-to-point
R1(config-if)#description Link_To_R4
R1(config-if)#ip addr 192.168.14.1 255.255.255.252
R1(config-if)#frame-relay interface-dlci 104
!

On R2:
R2(Config)#router ospf 1
R2(config-router)#network 192.168.0.0 0.0.255.255 area 0
!
R2(config)#int s0/0
R2(config-if)#encapsulation frame-relay
R2(config-if)#no shutdown
!
R2(config)#int s0/0.25
R2(config-if)#description Link_To_R1
R2(config-if)#ip addr 192.168.12.2 255.255.255.252
R2(config-if)#frame-relay interface-dlci 25
!

On R3:
R3(Config)#router ospf 1
R3(config-router)#network 192.168.0.0 0.0.255.255 area 0
!
R3(config)#int s0/0
R3(config-if)#encapsulation frame-relay
R3(config-if)#no shutdown
!
R3(config)#int s0/0.35
R3(config-if)#description Link_To_R1
R3(config-if)#ip addr 192.168.13.2 255.255.255.252
R3(config-if)#frame-relay interface-dlci 35
!

On R4:
R4(Config)#router ospf 1
R4(config-router)#network 192.168.0.0 0.0.255.255 area 0
!
R4(config)#int s0/0
R4(config-if)#encapsulation frame-relay
R4(config-if)#no shutdown
!
R4(config)#int s0/0.45
R4(config-if)#description Link_To_R1
R4(config-if)#ip addr 192.168.14.2 255.255.255.252
R4(config-if)#frame-relay interface-dlci 45
!

BSCI - OSPF - Network Types - Point-to-Multipoint

Point-to-Multipoint

  • Full mesh not required
  • Allows for NBMA networking
  • No DR/BDR elections
  • Timers = 30 seconds /120 seconds
  • Do not need to manually configure neighbor statements
  • Specific networks advertised through out.
    Configuration:
    Lacking a diagram, assume we have 4 routers in a hub and spoke design. R1 is the Hub and R2,R3, and R4 are spoke routers. Frame-relay is in use.

    On R1:
    R1(config)#router ospf 1
    R1(config-router)#network 192.168.1.0 0.0.0.255 area 0
    !
    R1(config)#int s0/0
    R1(config-if)#ip address 192.168.1.1 255.255.255.0
    R1(config-if)#encapsulation frame-relay
    R1(config-if)#ip ospf network point-to-multipoint
    R1(config-if)#frame-relay map ip 192.168.1.2 102^
    R1(config-if)#frame-relay map ip 192.168.1.3 103
    R1(config-if)#frame-relay map ip 192.168.1.4 104
    !
    ^ maps 192.168.1.2 to DLCI 102 - this is locally significant.

    On R2:
    R2(config)#router ospf 1
    R2(config-router)#network 192.168.1.0 0.0.0.255 area 0
    !
    R2(config)#int s0/0
    R2(config-if)#ip address 192.168.1.2 255.255.255.0
    R2(config-if)#encapsulation frame-relay
    R2(config-if)#ip ospf network point-to-multipoint
    R2(config-if)#frame-relay map ip 192.168.1.1 25
    R2(config-if)#frame-relay map ip 192.168.1.3 25
    R2(config-if)#frame-relay map ip 192.168.1.4 25
    !

    On R3:
    R3(config)#router ospf 1
    R3(config-router)#network 192.168.1.0 0.0.0.255 area 0
    !
    R3(config)#int s0/0
    R3(config-if)#ip address 192.168.1.3 255.255.255.0
    R3(config-if)#encapsulation frame-relay
    R3(config-if)#ip ospf network point-to-multipoint
    R3(config-if)#frame-relay map ip 192.168.1.1 35
    R3(config-if)#frame-relay map ip 192.168.1.2 35
    R3(config-if)#frame-relay map ip 192.168.1.4 35
    !

    On R4:
    R4(config)#router ospf 1
    R4(config-router)#network 192.168.1.0 0.0.0.255 area 0
    !
    R4(config)#int s0/0
    R4(config-if)#ip address 192.168.1.4 255.255.255.0
    R4(config-if)#encapsulation frame-relay
    R4(config-if)#ip ospf network point-to-multipoint
    R4(config-if)#frame-relay map ip 192.168.1.1 45
    R4(config-if)#frame-relay map ip 192.168.1.2 45
    R4(config-if)#frame-relay map ip 192.168.1.3 45
    !

    Note - the lack of manually assigned neighbor statements and the fact you still need to configure your frame-relay maps.
    -Also do not forget the ip ospf network point-to-multipoint cmd.

    BSCI - OSPF - Network Types - NBMA

    Non-Broadcast Multi-Access :
    • Typically a full mesh topology (each router has a link to every one router). 
    • Is the default network configuration for Frame Relay/ATM
    • Neighbors are statically configured (see config below)
    • Must use a single subnet to link all the interfaces in the mesh
    • a DR/BDR is elected
    • Hello Timers = 30 seconds Hello/120 seconds hold down
    Note: With Frame Relay, when adding a new network behind one of the branch routers (not a DR router) it will be advertised out via OSPF but not actually pingable.
    - to resolve this issue you need to manually add a Frame-Relay map to the outgoing interface on the router the new network is sat behind and on the DR.

    Configuration:
    Lacking a diagram, assume we have 4 routers in a hub and spoke design. R1 is the Hub and R2,R3, and R4 are spoke routers. Frame-relay is in use.

    On R1:
    R1(config)#router ospf 1
    R1(config-router)#network 192.168.1.0 0.0.0.255 area 0
    R1(config-router)#neighbor 192.168.1.2*
    R1(config-router)#neighbor 192.168.1.3
    R1(config-router)#neighbor 192.168.1.4
    !
    R1(config)#int s0/0
    R1(config-if)#ip address 192.168.1.1 255.255.255.0
    R1(config-if)#encapsulation frame-relay
    R1(config-if)#frame-relay map ip 192.168.1.2 102^
    R1(config-if)#frame-relay map ip 192.168.1.3 103
    R1(config-if)#frame-relay map ip 192.168.1.4 104
    !

    *when you use this cmd with out setting a neighbor priority the default is 1
    ^ maps 192.168.1.2 to DLCI 102 - this is locally significant.

    On R2:
    R2(config)#router ospf 1
    R2(config-router)#network 192.168.1.0 0.0.0.255 area 0
    R2(config-router)#neighbor 192.168.1.1 priority 10* 
    !
    R2(config)#int s0/0
    R2(config-if)#ip address 192.168.1.2 255.255.255.0
    R2(config-if)#encapsulation frame-relay
    R2(config-if)#frame-relay map ip 192.168.1.1 25
    R2(config-if)#frame-relay map ip 192.168.1.3 25
    R2(config-if)#frame-relay map ip 192.168.1.4 25
    !

    *when you use this cmd with the priority cmd the highest will be elected DR.

    On R3:
    R3(config)#router ospf 1
    R3(config-router)#network 192.168.1.0 0.0.0.255 area 0
    R3(config-router)#neighbor 192.168.1.1 priority 10
    !
    R3(config)#int s0/0
    R3(config-if)#ip address 192.168.1.3 255.255.255.0
    R3(config-if)#encapsulation frame-relay
    R3(config-if)#frame-relay map ip 192.168.1.1 35
    R3(config-if)#frame-relay map ip 192.168.1.2 35
    R3(config-if)#frame-relay map ip 192.168.1.4 35
    !

    On R4:
    R4(config)#router ospf 1
    R4(config-router)#network 192.168.1.0 0.0.0.255 area 0
    R4(config-router)#neighbor 192.168.1.1 priority 10
    !
    R4(config)#int s0/0
    R4(config-if)#ip address 192.168.1.4 255.255.255.0
    R4(config-if)#encapsulation frame-relay
    R4(config-if)#frame-relay map ip 192.168.1.1 45
    R4(config-if)#frame-relay map ip 192.168.1.2 45
    R4(config-if)#frame-relay map ip 192.168.1.3 45
    !

    You'll note that on the hub router, R1, each DLCI is different. This is because it is sending packets to 3 different routers. On the spoke routers, R2, R3, R4, the DLCI is the same. This is because they are directing all traffic to R1 for all destinations and therefore use the same outbound link. Resulting in the same DLCI being allocated. (if you follow me?).

    BSCI - OSPF - Area types and LSA's

    Note to self:

    Routers in a stub area will have a default route to use to reach external destinations; routers in total stub areas will have a default route to use in order to reach both external and inter-area networks.

    Saturday, August 28, 2010

    BSCI - OSPF - Network types

    From my experience with the Cisco ISCW exam if you try to hide from a subject, hoping your outstanding knowledge in other topics with carry you through, the you're more or less guaranteed that this will come back and bite you in the ass. You can tell what happened to me.

    Soooo, OSPF Network types. This is not Area types where we are looking at making the OSPF process more efficient. This is the nature of the network that OSPF is running on.

    There are generally 3 broad types of network that OSPF can be used within:
    1) Broadcast Access - this is a multi-access network. Ethernet.
    2) Point-To-Point - Such as lease lines, T1/T3 connections, ISDN.
    3) Non-Broadcast Multi-Access (NBMA) - Any WAN config represented by a Cloud, Frame-Relay, ATM etc

    In your lab work you'll generally configure either option 1, fastethernet links in to a switch and all your routers connected to the switch resulting in DR/BDR elections. Alternatively you'll have configured option 2, directly connecting your routers using serial cables resulting in there being only one device at either end, thereby eliminating the need for DR/BDR operations.

    It is here that we arrive at our third option and the one I struggle with. Just keep telling yourself 'if it was easy it wouldn't be worth achieving'

    There are 5 modes of NMBA network:
    1) NBMA - RFC 2328 standard
    2) Point-To-Multipoint - RFC 2328 standard
    3) Point-To-Point - Cisco propriortary
    4) Broadcast - CIsco propriortary
    5) Point-To-Multipoint Non-Broadcast - Cisco propriortary

    The next articles cover these network modes.

    BSCI - OSPF - Path Selection

    When OSPF considers which path to take to a destination if there are multiple paths available it will first consider the destination advertised from the lowest LSA (where type1 LSA = Low and type5 LSA =high)

    OSPF will the select the path with the lowest cost.

    BSCI - OSPF - NSSA Totally Stubby Area

    As I was reviewing my posts on OSPF LSA packet types and the Area types they are used in, it struck me that I missed off the last of the 4 area types.

    We have a Stub area, totally stubby area, a Not-So-Stubby-Area, and the last one is NSSA Totally Stubby Area.

    A NSSA Totally Stubby Area works in a similar manner to a Totally Stubby Area (blocking External type5 LSAs, Interarea route type4 LSA's and Summary type 3 LSA's). A single default route replaces all of these.

    To configure a NSSA Totally Stubby Area you do the following:
    On the NSSA ABR (this is the router that now has links to external networks/ Autonomous Systems):
    R5(config)#router ospf 1
    R5(config-router)#area 6 nssa
    !

    On the ABR that links to Area 0 do:
    R4(config)#router ospf 1
    R4(config-router)#area 6 nssa no-summary
    !

    In this situation R4 will automatically generate an O*N2 default route therefore you are not required to enter 'default-information originate'

    Note that this is a Cisco propriortary config.

    Thursday, August 26, 2010

    BSCI - Route Redistribution - #ip helper-address cmd

    I'm due to sit my BSCI exam (courtesy of being a Network Academy Student) and I thought I'd just clarify the use of this very helpful cmd.

    If you have DHCP host sat on one side of a router but the DHCP server is sat on the other side of the router then without further configuration the Host will not be able to communicate with the server as routers, by default, do not forward broadcast traffic.

    To get round this you use the #ip helper-address [ip address of DHCP or Broadcast address of network where multiple DHCP reside] cmd.

    Applied to the default gateway interface for the Host do the following:
    R1(config)#int e0
    R1(config-if)#ip helper-address 192.168.5.255
    !
    R1(config)#int e1
    R1(config-if)#ip directed-broadcast

    In the example above the admin knows there are multiple DHCP servers on the 192.168.5.0/24 network connected to int e1. So instead of specifying a single DHCP server the router is configured to pass the DHCP request to the broadcast address of that network.

    On interface e1, the #ip directed-broadcast cmd is used to convert the unicast traffic to a link-layer broadcast. a further explanation is here (taken from www.lansweeper.com):

    An IP directed broadcast is a datagram which is sent to the broadcast address of a subnet to which the sending machine is not directly attached. The directed broadcast is routed through the network as a unicast packet until it arrives at the target subnet, where it is converted into a link-layer broadcast. Because of the nature of the IP addressing architecture, only the last router in the chain, the one that is connected directly to the target subnet, can conclusively identify a directed broadcast



    Monday, July 26, 2010

    BSCI - Authentication in EIGRP, OSPF, IS-IS, BGP

    Like my previous post, the way authentication is applied for each protocol varies in a EIGRP, OSPF, IS-IS, and BGP.

    EIGRP:
    Supports MD5/Plain text
    Applied to the interface that connects to the neighbour, must be the same at each side.

    Configure by doing:
    R1(config)#int s0/0
    R1(config0if)#ip authentication eigrp 1 md5
    R1(config-if)#ip authentication key-chain eigrp 1 EIGRP_AUTH
    !
    R1(config)#key-chain EIGRP_AUTH
    R1(config-keychain)#key 1
    R1(config-keychain-key)#key-string P@ssw0rd
    !

    OSPF:
    Applied on the interface
    Can be MD5/Plain text
    Configure the same authentication on all neighbors

    Configure plain text:
    R1(config)#int s0/0
    R1(config-if)#ip ospf authentication*
    R1(config-if)#ip ospf authentication-key 1 P@ssw0rd
      *This cmd, without any switches, configures authentication in plain text

    Configure MD5 authentication:
    R1(config)#int s0/0
    R1(config-if)#ip ospf authentication message-digest
    R1(config-if)#ip ospf message-digest-key 1 md5 P@ssw0rd
    !

    IS-IS:
    Offers 2 layers of authentication
    i) Area-Passwords - between Level1 routers
    ii)Domain-Password - between Level2 routers

    Can be plain text or MD5 (out of scope of BSCI though)
    Apply the cmd on all routers within the area or domain (for Level2)

    Configure Level1 plain text authentication by:
    R1(config)#router isis
    R1(config-router)#area-password P@ssW0rd
    !

    Configure Level2 plain text authentication by:
    R2(config)#router isis
    R2(config-router)#domain-password P@ssw0rd
    !

    Protect specific links by applying the authentication on the interface:
    R2(config)#int s0/0
    R2(config-if)#isis password P@ssw0rd level-2*
     *you should state the router level to apply the authentication to, default is level1

    BGP:
    Uses MD5 authentication
    Must be configured on each side of the neighbor relationship otherwise the connection is not made

    Configure authentication by:
    R4(config)#router bgp 100
    R4(config-router)#neighbor 10.1.1.1 password P@ssw0rd



    BSCI - Route Summarisation with RIPv2, EIGRP, OSPF, IS-IS, BGP

    Something I seem to be struggling with is committing to memory how to implement route summarisation within each routing protocol. So in this post I'm going set down the necessary steps to implement summarisation in each protocol.


    RIPv2:
    On the router running RIPv2 you apply the summary to the outgoing interface:
    R1(config)#int s0/0
    R1(config-if)#ip summary-address rip 10.0.0.0 255.252.0.0


    EIGRP:
    Firstly disable auto summarisation-
    R1(config)#router eigrp 1
    R1(config-router)#no auto-summary



    Next apply your summary route to the OUT Bound interface -
    R1(config)#int s0/0/0
    R1(config-if)#ip summary-address eigrp 1 172.16.0.0 255.255.224.



    Points - Configured on a per interface basis, Router creates a NULL0 entry as loop prevention (longest match rule works here so if there isn't a more specific route within the summary route the router will drop the packet), When the last specific route within the summary is removed the NULL0 entry is removed.


    OSPF:
    Summarisation is performed on the ABR and ASBR only.
    ABR - Applied to routes from within one area and summarised in to another area
    ASBR - External routes are redistributed INTO ospf from protocols such as RIPv2 or EIGRP


    For Intra-area route summarisation, on the ABR do:
    R1(config)#router ospf 1
    R1(config-router)# area 1 range 192.168.64.0 255.255.224.0
      *Area number is the area you are summarising FROM
     *#sh ip route - will show a NULL0 route to help prevent routing loops
     * #sh ip ospf database - will show the summary route


    For Inter-area route summarisation, on the ASBR do:
    R4(config)#router ospf 1
    R4(config-router)#summary address 192.168.64.0 255.255.224.0
     *Advertises a summary route for all routes within 192.168.64.0/19 subnet


    Note - By default ABR's and ASBR's do not summarise routes.


    IS-IS:
    Summarisation to be done on a Level1/2 router, which injects level 1 routes in to level 2.
    If summarisation is being implemented, ALL level1/2 routers in the area need to be configured for summarisation.
    Otherwise if one router advertises a more specific route then the Level 2 router will direct all traffic to that one router (due to the Longest Match rule).


    On the Level1/2 router do:
    R5(config)#router isis
    R5(config-router)#summary-address 192.168.0.0 255.255.0.0 level-2
     *You state which level router you are summarising in to (default is level-2).


    BGP:
    BGP will not advertise a summary route unless the route can be first located in the Routing Table. As a result you can't simply apply a summary in the BGP process as it won't exist in the RT and therefore will not be advertised.


    To get round this you first add a static route for the summary point to NULL0 and then you apply your summary route in BGP.


    To do this do:
    R2(config)#ip route 192.168.0.0 255.255.0.0 NULL0
    !
    R2(config)#router bgp 100
    R2(config-router)#network 192.168.0.0 mask 255.255.0.0