The second trouble ticket that I was able to demonstrate my TSHOOT knowledge was the following:
Trouble Ticket #2 - the customer reported that hosts at SiteC were not getting a DHCP allocation from the server at SiteD.
The customer reported that when they performed a traceroute from the LAN at SiteC to 192.168.10.10 on the LAN at SiteD the trace stopped. The network looked like this:
SiteC --> R1 at SiteC --> 'the core network' at R2 --> R3 at SiteD --> DHCP Server on SiteD LAN
For this one I took a look at our Nagios Monitoring and could see that there were no issues reported on R1, R2, or R3. As such I jumped on to R1 at SiteC and performed a traceroute to 192.168.10.10. The trace was successful! Yet from the LAN at SiteC the trace failed?
Based on this information I formed my hypothesis. I asked the customer whether there could be an access-list/firewall between R3 and the DHCP server that could be blocking traffic from the LAN at SiteC? The customer investigated their equipment and found that an earlier change to an access-list on their equipment at SiteD was now stopping DHCP requests from SiteC. They corrected their configuration and the issue was resolved.
Trouble Ticket #2 - Closed
With this ticket because our network monitoring was reporting no issues with R1, R2, R3, I took the 'Shoot from hip' approach and looked to eliminate all L3 issues in one go. The trace route worked indicating that the server was responding to ping and that all L3 connectivity between SiteC and SiteD was fine. I could have tested the L1/L2 physical connectivity on each router in turn but our monitoring would have pick this up and therefore I was confident the physical connectivity was fine. Once L3 connectivity had been proven on the equipment I have admin access on I could formulate my hypothesis and put it to the customer to test.
Monday, September 27, 2010
CCNP - TSHOOT - TSHOOT in the real world...
When studying for any certification exam it's very easy to end up concentrating on the goal of passing the exam instead of the actual goal which should be gaining knowledge and achieving a certain standard of expertise that can be practically utilised in the real world. The exam simply confirms that you have a certain level of knowledge. The point is to enable you to use it in the real world.
So here I am, studying for my TSHOOT exam, which will complete my CCNP, and in the week before the exam comes 2 real world examples of how studying for the TSHOOT exam has helped me investigate and resolve the issue in hand. The next 2 posts will outline the problem, methodology used and how the TSHOOT exam materials directly related to resolving the problems.
Trouble Ticket #1 - The customer contacted us to state that SiteA no longer had access to the internet via it's default route.
Following the TSHOOT troubleshooting methodology I gathered as much relevant information as I could from the client. I then reviewed the information, eliminated the possible causes until I was down to a small number of possible issues, I then formed my hypothesis, tested it and reviewed the outcome.
For this particular problem the customer stated that following the closure of one office and the migration to a new site access to the internet via it's default route was no longer possible. The customer supplied me their default route - 10.1.1.1 and that it originally routed via the now closed office. I also had the new network diagram outlining the new office and the appropriate routes. The diagram was essentially as follows:
SiteA Firewall ---> R1at SiteA ---> 'The core network' at R2 ---> R3 at SiteB - (trunk link)--> SiteB L3 switch ---> SiteB's ASA firewall --> INTERNET
First job was to see where the routing began to fail. So on to R1 and check the interfaces were up (yes) and then I moved on to the routing table to check for a route for 10.1.1.1. This was a static route pointing to our core network (for this article we'll call all of it R2). I performed a traceoute on R1 to 10.1.1.1 and it failed at R2.
On R2 I did the same, checked that interfaces were up and then checked the routing, This is where the first issue occurred. The static route on R2 was still pointing to the closed office. So the change was made. Static route was now pointing to R3 at SiteB.
I performed a traceroute to the default route from R1 again and it still didn't work. This time the trace stopped at R3.
On to R3 the routing table revealed that there was no route for 10.1.1.1 at all. After referring to the customer they advised me that the traffic had to go via a specific VLAN on the L3 switch so on R3 we needed to create VLAN10 and allowed VLAN10 on the trunk link to the L3 switch at SiteB. Finally the route for 10.1.1.1 was set to go via the SVI for VLAN10.
With this created I tested the route to 10.1.1.1 from R3. It still didn't work? With the information at hand I was able to formulate my hypothesis.
Was VLAN10 a) created on the L3 switch? and b) allowed on the trunk link?
Next I checked the state of the VLANs. VLAN10 was in place on R3, and was allowed on the trunk link to the L3 switch. The trunk link was up and protocol was up. Everything that I had admin access to was now properly configured and had been tested however the traceroute was still not returning. I put this to the customer who inspected their L3 Switch. They reported that VLAN10 had not been created after all on their equipment.
Once the customer applied their configuration on their equipment the route from SiteA to the ASA firewall on the LAN of SiteB worked. It was only after the issue was investigated that it became apparent the customer had neglected to account for the routing required for SiteA when they planned the closure of their old office. As a result none of the required configuration had been prepared before hand and SiteA had been cut off once the old office closed.
Trouble Ticket #1 - Closed.
As you can see on this occasion I was able to use a 'Divide and Conquer' trouble shooting approach. Starting L3 and then checking L1 and L2 when the traceroute failed. On R3 I was able to narrow the issue to L2 and formulate my hypothesis which was then tested.
So here I am, studying for my TSHOOT exam, which will complete my CCNP, and in the week before the exam comes 2 real world examples of how studying for the TSHOOT exam has helped me investigate and resolve the issue in hand. The next 2 posts will outline the problem, methodology used and how the TSHOOT exam materials directly related to resolving the problems.
Trouble Ticket #1 - The customer contacted us to state that SiteA no longer had access to the internet via it's default route.
Following the TSHOOT troubleshooting methodology I gathered as much relevant information as I could from the client. I then reviewed the information, eliminated the possible causes until I was down to a small number of possible issues, I then formed my hypothesis, tested it and reviewed the outcome.
For this particular problem the customer stated that following the closure of one office and the migration to a new site access to the internet via it's default route was no longer possible. The customer supplied me their default route - 10.1.1.1 and that it originally routed via the now closed office. I also had the new network diagram outlining the new office and the appropriate routes. The diagram was essentially as follows:
SiteA Firewall ---> R1at SiteA ---> 'The core network' at R2 ---> R3 at SiteB - (trunk link)--> SiteB L3 switch ---> SiteB's ASA firewall --> INTERNET
First job was to see where the routing began to fail. So on to R1 and check the interfaces were up (yes) and then I moved on to the routing table to check for a route for 10.1.1.1. This was a static route pointing to our core network (for this article we'll call all of it R2). I performed a traceoute on R1 to 10.1.1.1 and it failed at R2.
On R2 I did the same, checked that interfaces were up and then checked the routing, This is where the first issue occurred. The static route on R2 was still pointing to the closed office. So the change was made. Static route was now pointing to R3 at SiteB.
I performed a traceroute to the default route from R1 again and it still didn't work. This time the trace stopped at R3.
On to R3 the routing table revealed that there was no route for 10.1.1.1 at all. After referring to the customer they advised me that the traffic had to go via a specific VLAN on the L3 switch so on R3 we needed to create VLAN10 and allowed VLAN10 on the trunk link to the L3 switch at SiteB. Finally the route for 10.1.1.1 was set to go via the SVI for VLAN10.
With this created I tested the route to 10.1.1.1 from R3. It still didn't work? With the information at hand I was able to formulate my hypothesis.
Was VLAN10 a) created on the L3 switch? and b) allowed on the trunk link?
Next I checked the state of the VLANs. VLAN10 was in place on R3, and was allowed on the trunk link to the L3 switch. The trunk link was up and protocol was up. Everything that I had admin access to was now properly configured and had been tested however the traceroute was still not returning. I put this to the customer who inspected their L3 Switch. They reported that VLAN10 had not been created after all on their equipment.
Once the customer applied their configuration on their equipment the route from SiteA to the ASA firewall on the LAN of SiteB worked. It was only after the issue was investigated that it became apparent the customer had neglected to account for the routing required for SiteA when they planned the closure of their old office. As a result none of the required configuration had been prepared before hand and SiteA had been cut off once the old office closed.
Trouble Ticket #1 - Closed.
As you can see on this occasion I was able to use a 'Divide and Conquer' trouble shooting approach. Starting L3 and then checking L1 and L2 when the traceroute failed. On R3 I was able to narrow the issue to L2 and formulate my hypothesis which was then tested.
Friday, September 24, 2010
CCNP - TSHOOT - Troubleshooting the Routers...
Continuing my TSHOOT methodology, in this post I'm going to look at troubleshooting the network between R4, R3, R2,R1 and out to the web server at 209.65.200.241.
Having not sat the TSHOOT exam the impression I'm getting is the Trouble Ticket (TT) will state something like Client1 cannot access [insert resource]. As such you need to identify the system the issue is on and the resolution.
Again I'll be referring to the actual TSHOOT topology - here
Let's say Client 1 cannot access the web server at 209.65.200.241. Based on my previous article, also assume Client 1 can ping 10.1.4.5 at R4. In this post I will outline how I see myself troubleshooting the connectivity issue to the web server.
I'll want to prove connectivity to R1. So in turn I'll ping each interface on the way to R1 at 10.1.1.1 If at any point the ping is not returned then log in to the router that you were trying to ping and begin troubleshooting.
1) Are the interface on the link UP/UP? check that one of them is not admin'd down:
#sh ip interfaces brief
2) With interfaces up, is the L2 Frame-Relay topology correct? the diagram shows that the routers are connected via point-to-point links therefore I'm expecting to see a config similar to:
R4(config)#int s0/0/0
R4(config-if)#encapsulation frame-relay point-to-point
R4(config-if)#no shutdown
!
R4(config)#int s0/0/0.34 point-to-point
R4(config-if)#ip address 10.1.1.10 255.255.255.252
R4(config-if)#frame-relay interface dlci 403
3) Assuming L2 is fine move on the routing protocols. Things to check here are:
i - is route redistribution functioning correctly on R4? check the routing table, check config
ii - Are the adjacencies up? Check the neighbor tables/topology tables.
iii -Are the correct networks being advertised to the neighbor? check the ospf network statements
iv - is there any authentication in place? if so it must match at each end
v - is the routing table including the correct route as per the network diagram? If the route is not in the routing table it won't be advertised out to the neighbor.
vi - Is the routing config command 'passive-interface default' set? if it is then updates will be suppressed by default. You need to either remove the command using #no passive-interface default
Or you specifically list the interfaces you want to participate in dynamic routing using:
#passive-interface default
#no passive-interface f0/0
#no passive-interface f0/1
and so on...
4) Up to R1 I think that would cover off all the major connectivity issues you'd be likely to get. If you still have problems look closer at R1.
On R1 check you can get to the next-hop outside of the network. If you can the config on R1 should be sound. If you can't it could indicate any of the following.
i - Check over the interfaces as per previous points. Ensure they are UP/UP. if they aren't then troubleshoot accordingly.
ii - Check routing/BGP - is the BGP peering up? if not check the config, if the update source being used is a Loopback address then you need the update-source command set in the BGP config. Check the IP's of the Peers, check the remote-as command is correct
iii - Is there a default route? I'd expect there to be one. Simple question. Is it pointing to the correct outbound next-hop? not in towards the LAN?
iv - Are there any access-lists? if so, what are they permitting and what are they blocking? Could the implicit deny be causing an issue here?
v- Is the default route being correctly redistributed? I'm expecting to see something like:
R1(config)#router ospf 1
R1(config)#default-information originate
vi - Is NAT in operation? check which interface is inside, outside, check the ip nat source statements. Check any NAT pools that my be configured? if a pool is not configured then I'm looking for the 'overload' option in the command :
#ip nat source list 10 interface s0/0/1 overload
With out Overload then port address translation is not working and you'd only be able to have 1 host using NAT at any one time.
Based on the exam topology I'd hope that by running through my structured check list from L1, L2 to L3 to L4 and above that the issue in hand would be revealed.
When I'm in the exam I'll be taking my cue from the information in the TT. As such I might not need to bother with L1/L2 checks if the remote peer is responding as expected.
My next article is going to look at the IPv6 topology and look at how I might be troubleshooting problems there.
Having not sat the TSHOOT exam the impression I'm getting is the Trouble Ticket (TT) will state something like Client1 cannot access [insert resource]. As such you need to identify the system the issue is on and the resolution.
Again I'll be referring to the actual TSHOOT topology - here
Let's say Client 1 cannot access the web server at 209.65.200.241. Based on my previous article, also assume Client 1 can ping 10.1.4.5 at R4. In this post I will outline how I see myself troubleshooting the connectivity issue to the web server.
I'll want to prove connectivity to R1. So in turn I'll ping each interface on the way to R1 at 10.1.1.1 If at any point the ping is not returned then log in to the router that you were trying to ping and begin troubleshooting.
1) Are the interface on the link UP/UP? check that one of them is not admin'd down:
#sh ip interfaces brief
2) With interfaces up, is the L2 Frame-Relay topology correct? the diagram shows that the routers are connected via point-to-point links therefore I'm expecting to see a config similar to:
R4(config)#int s0/0/0
R4(config-if)#encapsulation frame-relay point-to-point
R4(config-if)#no shutdown
!
R4(config)#int s0/0/0.34 point-to-point
R4(config-if)#ip address 10.1.1.10 255.255.255.252
R4(config-if)#frame-relay interface dlci 403
3) Assuming L2 is fine move on the routing protocols. Things to check here are:
i - is route redistribution functioning correctly on R4? check the routing table, check config
ii - Are the adjacencies up? Check the neighbor tables/topology tables.
iii -Are the correct networks being advertised to the neighbor? check the ospf network statements
iv - is there any authentication in place? if so it must match at each end
v - is the routing table including the correct route as per the network diagram? If the route is not in the routing table it won't be advertised out to the neighbor.
vi - Is the routing config command 'passive-interface default' set? if it is then updates will be suppressed by default. You need to either remove the command using #no passive-interface default
Or you specifically list the interfaces you want to participate in dynamic routing using:
#passive-interface default
#no passive-interface f0/0
#no passive-interface f0/1
and so on...
4) Up to R1 I think that would cover off all the major connectivity issues you'd be likely to get. If you still have problems look closer at R1.
On R1 check you can get to the next-hop outside of the network. If you can the config on R1 should be sound. If you can't it could indicate any of the following.
i - Check over the interfaces as per previous points. Ensure they are UP/UP. if they aren't then troubleshoot accordingly.
ii - Check routing/BGP - is the BGP peering up? if not check the config, if the update source being used is a Loopback address then you need the update-source command set in the BGP config. Check the IP's of the Peers, check the remote-as command is correct
iii - Is there a default route? I'd expect there to be one. Simple question. Is it pointing to the correct outbound next-hop? not in towards the LAN?
iv - Are there any access-lists? if so, what are they permitting and what are they blocking? Could the implicit deny be causing an issue here?
v- Is the default route being correctly redistributed? I'm expecting to see something like:
R1(config)#router ospf 1
R1(config)#default-information originate
vi - Is NAT in operation? check which interface is inside, outside, check the ip nat source statements. Check any NAT pools that my be configured? if a pool is not configured then I'm looking for the 'overload' option in the command :
#ip nat source list 10 interface s0/0/1 overload
With out Overload then port address translation is not working and you'd only be able to have 1 host using NAT at any one time.
Based on the exam topology I'd hope that by running through my structured check list from L1, L2 to L3 to L4 and above that the issue in hand would be revealed.
When I'm in the exam I'll be taking my cue from the information in the TT. As such I might not need to bother with L1/L2 checks if the remote peer is responding as expected.
My next article is going to look at the IPv6 topology and look at how I might be troubleshooting problems there.
Monday, September 20, 2010
CCNP - ENTERPRISE - Considering the Client...
In the TSHOOT exam the bulk of the trouble tickets will pretty much be Client1 cannot access [insert resource here], identify the problem device and present a solution.
The TSHOOT topology is freely available from the Cisco website - here - and so we can take a look and start to suggest possible problems that can be presented. On it we have BGP, OSPF, EIGRP and redistribution, NAT, DHCP, IPv6 Tunnels, OSPFv3 and RIPng redistribution, we've got first hop redundancy and etherchannel, plus OSPF over Frame-Relay. Some pretty tasty stuff.
So, where to start? Well, lets say that Client1 can't access the web server at 209.65.200.241. As I'm looking at client issues assume that the config between the web server all the way in to the network to R4 is fine.
When I'm in the exam I'm going to be looking to ensure connectivity to Client1's default gateway and the DHCP server at R4 is sound. When I find that Client1 is unable to ping the default gateway or obtain a DHCP allocation here is what I'll be looking for:
1) Client1 IP Assignment - The L2/L3 topology diagram states that the address is obtained via DHCP (R4 at 10.1.4.5). On Client1 do >ipconfig - if the address is 10.2.1.4 move to ASW1, if the address is 169.X.X.X then DHCP is not working properly for some reason. In both cases move to ASW1
2) Interface VLAN membership - Client1 should be connected to int f1/0/1 - is it? if not then correct as appropriate. Interface f1/0/1 should be a member of VLAN 10 - does the VLAN exist? :
#sh vlan
Is int f1/0/1 a member of VLAN 10?:
#sh run int f1/0/1 OR #sh vlan
Does ASW1 have any port security?
#sh run int f1/0/1
if so what is configured here? Does any static MAC address match that of Client1? does the port limit number of MAC addresses per interface? Problem is here is if port security is incorrect. Otherwise move on
3) Is VLAN 10 allowed on the trunks?
Firstly prove int Po13 is an active Etherchannel and that interfaces f1/0/19-20 are members
#sh etherchannel summary - Trouble shoot accordingly if this is not the case.
Next is int Po13 a trunk link?
#sh interfaces trunk - if not then problem is here.
Next which VLAN's are allowed on the trunk links?
#sh interfaces po13 trunk - if VLAN10 is not here then you won't get to DSW1
Next, can you see any VLAN filtering in place? if so check that any permited ACL has the correct ip range otherwise traffic from 10.2.1.4 will not be allowed to use VLAN10. Also check the vlan access-map config ensure that the traffic allowed in the ACL is forwarded not dropped.
Do step 3 on both ASW1 and DSW1. If one side is not configured correctly then connectivity will fail.
If everything looks good you should be able to at least ping VLAN10's dfg at 10.2.1.1 on DSW1, move on.
4) Check routing on DSW1:
- DSW1 is an L3 switch that needs to send your DHCPDISCOVER to the DHCP server on a different network. As such ensure ip routing is enabled:
DSW1#sh run | begin ip routing
- Check L3 connectivity between DSW1 and R4 - Ping 10.1.4.5, check interfaces are UP/UP
DSW1#sh ip interface brief
- Check DSW1 int f1/0/1 is not admin'd down:
- If all looks good here check that the ip-helper command is applied to interface VLAN 10:
DSW1(config)#int vlan10
DSW1(config-if)#ip helper-address 10.1.4.5
(this will tell DSW1 to forward UDP broadcasts received on this interface)
5) You should now be at R4. If all of the above looks good then you should look above L2/L3 to DHCP or other factors.
6) DHCP configuration:
- Is DHCP running on R4? look for service dhcp in #sh run
- Are there any leases active? check - #sh ip dhcp bindings
Check the Hardware Address with that of Client1 to ensure the correct Client has an assignment. If you've discounted steps 1-4 I'd be surprised if this was the case.
- Check the DHCP address pool is correctly configured:
DSW1#sh run | begin ip dhcp
look for any kind of misconfig here be it incorrect subnet defined for the pool or an exclude address incorrect
7) At this point I'd expect to have uncovered an issue. If that's not case there's still some tactics I can try.
i) Kevin Wallace suggested Abort! - if you think you've narrowed the issue to a point but are unsure of the final solution, hit Abort, dive in to a different ticket and cross check the config. If the config is different the here is your fault. If it's the same then you can discount that area as the source of the problem and move on
ii) Let the question guide you - you've narrowed the issue to, lets say, DSW1 but are still unsure. Review the options available to you in part 2 and part 3 of the trouble ticket and use the information there to gleen if you are looking in the right place.
I think I've covered off the major issues that could be presented. I guess HSRP on DSW1 could be an issue but if DSW2 is the active router (#sh standby) then you should still be able to reach the DHCP server at 10.1.4.5?
Please let me know if I've missed a point or am miss guided in any way. Thanks
The TSHOOT topology is freely available from the Cisco website - here - and so we can take a look and start to suggest possible problems that can be presented. On it we have BGP, OSPF, EIGRP and redistribution, NAT, DHCP, IPv6 Tunnels, OSPFv3 and RIPng redistribution, we've got first hop redundancy and etherchannel, plus OSPF over Frame-Relay. Some pretty tasty stuff.
So, where to start? Well, lets say that Client1 can't access the web server at 209.65.200.241. As I'm looking at client issues assume that the config between the web server all the way in to the network to R4 is fine.
When I'm in the exam I'm going to be looking to ensure connectivity to Client1's default gateway and the DHCP server at R4 is sound. When I find that Client1 is unable to ping the default gateway or obtain a DHCP allocation here is what I'll be looking for:
1) Client1 IP Assignment - The L2/L3 topology diagram states that the address is obtained via DHCP (R4 at 10.1.4.5). On Client1 do >ipconfig - if the address is 10.2.1.4 move to ASW1, if the address is 169.X.X.X then DHCP is not working properly for some reason. In both cases move to ASW1
2) Interface VLAN membership - Client1 should be connected to int f1/0/1 - is it? if not then correct as appropriate. Interface f1/0/1 should be a member of VLAN 10 - does the VLAN exist? :
#sh vlan
Is int f1/0/1 a member of VLAN 10?:
#sh run int f1/0/1 OR #sh vlan
Does ASW1 have any port security?
#sh run int f1/0/1
if so what is configured here? Does any static MAC address match that of Client1? does the port limit number of MAC addresses per interface? Problem is here is if port security is incorrect. Otherwise move on
3) Is VLAN 10 allowed on the trunks?
Firstly prove int Po13 is an active Etherchannel and that interfaces f1/0/19-20 are members
#sh etherchannel summary - Trouble shoot accordingly if this is not the case.
Next is int Po13 a trunk link?
#sh interfaces trunk - if not then problem is here.
Next which VLAN's are allowed on the trunk links?
#sh interfaces po13 trunk - if VLAN10 is not here then you won't get to DSW1
Next, can you see any VLAN filtering in place? if so check that any permited ACL has the correct ip range otherwise traffic from 10.2.1.4 will not be allowed to use VLAN10. Also check the vlan access-map config ensure that the traffic allowed in the ACL is forwarded not dropped.
Do step 3 on both ASW1 and DSW1. If one side is not configured correctly then connectivity will fail.
If everything looks good you should be able to at least ping VLAN10's dfg at 10.2.1.1 on DSW1, move on.
4) Check routing on DSW1:
- DSW1 is an L3 switch that needs to send your DHCPDISCOVER to the DHCP server on a different network. As such ensure ip routing is enabled:
DSW1#sh run | begin ip routing
- Check L3 connectivity between DSW1 and R4 - Ping 10.1.4.5, check interfaces are UP/UP
DSW1#sh ip interface brief
- Check DSW1 int f1/0/1 is not admin'd down:
- If all looks good here check that the ip-helper command is applied to interface VLAN 10:
DSW1(config)#int vlan10
DSW1(config-if)#ip helper-address 10.1.4.5
(this will tell DSW1 to forward UDP broadcasts received on this interface)
5) You should now be at R4. If all of the above looks good then you should look above L2/L3 to DHCP or other factors.
6) DHCP configuration:
- Is DHCP running on R4? look for service dhcp in #sh run
- Are there any leases active? check - #sh ip dhcp bindings
Check the Hardware Address with that of Client1 to ensure the correct Client has an assignment. If you've discounted steps 1-4 I'd be surprised if this was the case.
- Check the DHCP address pool is correctly configured:
DSW1#sh run | begin ip dhcp
look for any kind of misconfig here be it incorrect subnet defined for the pool or an exclude address incorrect
7) At this point I'd expect to have uncovered an issue. If that's not case there's still some tactics I can try.
i) Kevin Wallace suggested Abort! - if you think you've narrowed the issue to a point but are unsure of the final solution, hit Abort, dive in to a different ticket and cross check the config. If the config is different the here is your fault. If it's the same then you can discount that area as the source of the problem and move on
ii) Let the question guide you - you've narrowed the issue to, lets say, DSW1 but are still unsure. Review the options available to you in part 2 and part 3 of the trouble ticket and use the information there to gleen if you are looking in the right place.
I think I've covered off the major issues that could be presented. I guess HSRP on DSW1 could be an issue but if DSW2 is the active router (#sh standby) then you should still be able to reach the DHCP server at 10.1.4.5?
Please let me know if I've missed a point or am miss guided in any way. Thanks
Wednesday, September 15, 2010
CCNP - ENTERPRISE - 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.
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.
CCNP - ENTERPRISE - 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.
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
CCNP - ENTERPRISE - 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
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
CCNP - ENTERPRISE - 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.
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.
Sunday, September 12, 2010
CCNP - TSHOOT - Maintenance Models
The main models used in assisting with the maintenance of a network are as follows:
- FCAPS - which is - Fault mgmt, Configuration mgmt, Accounting mgmt, Performance mgmt and Security mgmt. Defined by ISO (International Organisation for Standardisation).
- ITIL - the IT Infrastructure Library, which is a collection of best practices. When implementing this PLEASE PLEASE PLEASE remember it is Best Practice not THE Practice. I've worked at companies who have
idiotsService Delivery Mangers who think that to be 'compliant' they need to implement all of the guidelines regardless of how big the firm is or how suitable the process is to their enterprise </rant> - TMN - Telecommunications Management Network, the ITU-T's variant to FCAPS tailored to the telecommunications field.
- Cisco Lifecycle Services - You should be familiar with this from your ROUTE and SWITCH studies Chpt1. Covering the PPDIOO - Prepare, Plan, Design, Implement, Operate, and Optimize life cycle.
CCNP - ENTERPRISE - 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
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
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.
- Practice 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.
CCNP - ENTERPRISE - 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.
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.
CCNP - ENTERPRISE - 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
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
CCNP - ENTERPRISE - 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
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
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
Subscribe to:
Posts (Atom)