CCIE#26439
Exness交易商开户流程
1 year ago
Monday, July 12, 2010
Friday, July 9, 2010
INE Workbook Vol 2 Lab 14 and final notes....
When you configure a neighbor under the EIGRP process, EIGRP will stop processing/sending multicast packets. This is useful if you only need to exchange eigrp with certain neighbors on a shared segment. This differs greatly from RIP. With RIP, a neighbor command will process updates with that neighbor via unicast but will still process multicast packets on the interface. In RIP, you also need to add passive interface.
The 'ip bandwidth-percent eigrp 10 x' command should be placed on the physical interface, and not on the logic interface. The same goes for the bandwidth command. So far, I can't find the documentation from Cisco on this.
Enable DVMRP on in interface with 'ip dvmrp unicast-routing'. This will ensure the router can use DVMRP derived information for RPF checks.
It may be very important to add 'show run' to a parser view if that configured users should be allowed to see their pertinent configurations. The show run will only show relevant commands trusted to their view.
IP Traffic-export 'bidirectional' must be enabled if you want input/output export. Otherwise you will only get input statistics.
NAT on a stick is something I've seen a few times, and still just don't get. Chances are, you won't see it on the lab, but you could. In short, it is setup like a standard NAT , but uses a loopback interface as the inside interface. Then you need a policy-map on the 'outside' interface to match the translated traffic and 'set' the loopback interface.
interface Loopback0
ip address 150.1.2.2 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface FastEthernet0/0
ip address 172.16.0.2 255.255.255.0 secondary
ip address 167.1.27.2 255.255.255.0
ip nat outside
ip virtual-reassembly
ip policy route-map Policy
!
ip nat pool INSIDE 167.1.27.100 167.1.27.199 netmask 255.255.255.0
ip nat inside source list Inside pool Inside
!
ip access-list standard Inside
permit 172.16.0.0 0.0.0.255
!
route-map Policy permit 10
match ip address Inside
set interface Loopback0
Maybe that will help someone out there.
Overall, this lab was not hard. I completed it in about 5.5 hours, with lots of breaks in between, and had time to verify my solutions. This lab was graded a level 9. Again, not difficult, just very in-depth. Many small tasks for 2 - 3 points. The only reason this should be perceived as hard is because it covers a very wide range of topics, and it really get's out there on the outer fringes of the blueprint (dvmrp? NAT on a stick?).
And that is it. This was my last full lab before my exam on Monday. I plan to continue reading Ruhan's short notes through the weekend, and re-visiting some Vol 1 topics that I haven't seen in a while. I also plan to re-read my own blog as I took some pretty nice notes. Other than that, I will take it easy for the weekend. No mad dash, no marathon until the finish. If I don't know it by now, I'm not going to know it much better by Monday morning.
With that being said, I am feeling really good. I have learned so much more this time around than my previous attempts. Doing these full labs is very beneficial. They teach you and show you how technologies and protocols inter-operate and they reinforce everything you learned in Volume 1. As much as I like Narbik's workbooks and his teaching style, he still has a huge whole in his materials and that is full scale mock labs. I don't think he believes in them but I disagree. If you are only working on one topic at a time, how will you know how zone based firewall will affect you routing protocols or your multicast 12 steps later in the exam? But I digress...
I have rough days where I feel like I am not ready, but then I think back to how very close I came my first attempt, and compare that with how much better of an engineer I am now. I totally and 100% believe I am ready. I try not to get too excited at the prospect of finally conquering this thing. I want to stay grounded and humble so that I can attack this with a clear head.
So in short - here is what I have done the last 8 months.
The 'ip bandwidth-percent eigrp 10 x' command should be placed on the physical interface, and not on the logic interface. The same goes for the bandwidth command. So far, I can't find the documentation from Cisco on this.
Enable DVMRP on in interface with 'ip dvmrp unicast-routing'. This will ensure the router can use DVMRP derived information for RPF checks.
It may be very important to add 'show run' to a parser view if that configured users should be allowed to see their pertinent configurations. The show run will only show relevant commands trusted to their view.
IP Traffic-export 'bidirectional' must be enabled if you want input/output export. Otherwise you will only get input statistics.
NAT on a stick is something I've seen a few times, and still just don't get. Chances are, you won't see it on the lab, but you could. In short, it is setup like a standard NAT , but uses a loopback interface as the inside interface. Then you need a policy-map on the 'outside' interface to match the translated traffic and 'set' the loopback interface.
interface Loopback0
ip address 150.1.2.2 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface FastEthernet0/0
ip address 172.16.0.2 255.255.255.0 secondary
ip address 167.1.27.2 255.255.255.0
ip nat outside
ip virtual-reassembly
ip policy route-map Policy
!
ip nat pool INSIDE 167.1.27.100 167.1.27.199 netmask 255.255.255.0
ip nat inside source list Inside pool Inside
!
ip access-list standard Inside
permit 172.16.0.0 0.0.0.255
!
route-map Policy permit 10
match ip address Inside
set interface Loopback0
Maybe that will help someone out there.
Overall, this lab was not hard. I completed it in about 5.5 hours, with lots of breaks in between, and had time to verify my solutions. This lab was graded a level 9. Again, not difficult, just very in-depth. Many small tasks for 2 - 3 points. The only reason this should be perceived as hard is because it covers a very wide range of topics, and it really get's out there on the outer fringes of the blueprint (dvmrp? NAT on a stick?).
And that is it. This was my last full lab before my exam on Monday. I plan to continue reading Ruhan's short notes through the weekend, and re-visiting some Vol 1 topics that I haven't seen in a while. I also plan to re-read my own blog as I took some pretty nice notes. Other than that, I will take it easy for the weekend. No mad dash, no marathon until the finish. If I don't know it by now, I'm not going to know it much better by Monday morning.
With that being said, I am feeling really good. I have learned so much more this time around than my previous attempts. Doing these full labs is very beneficial. They teach you and show you how technologies and protocols inter-operate and they reinforce everything you learned in Volume 1. As much as I like Narbik's workbooks and his teaching style, he still has a huge whole in his materials and that is full scale mock labs. I don't think he believes in them but I disagree. If you are only working on one topic at a time, how will you know how zone based firewall will affect you routing protocols or your multicast 12 steps later in the exam? But I digress...
I have rough days where I feel like I am not ready, but then I think back to how very close I came my first attempt, and compare that with how much better of an engineer I am now. I totally and 100% believe I am ready. I try not to get too excited at the prospect of finally conquering this thing. I want to stay grounded and humble so that I can attack this with a clear head.
So in short - here is what I have done the last 8 months.
- INE's entire workbook Volume 1 on Dynamips. I completed the switching and some QoS tasks on 3560 switches located at my company's lab.
- INE Workbook Volume 2 for Dynamips. I completed labs rated 7 and higher which included labs 1,3,7,8,9,10,11,12,13 and 14 for a total of 10 labs.
- INE Workbook Volume 4 on INE Rack Rentals. I completed labs 1-7.
- Narbik Advanced Technologies Workbook. Specifically - MPLS. I had already been through his stuff twice. Chose INE for a different perspective and fresh material.
- Re-attended Narbik's bootcamp in November of 2010. I picked up some good bits of information, but really - how many times can you re-attend? That was my 3rd.
- INE/IPExpert blog posts - always useful and insightful. Even if you know the technology being discussed, it never hurts to reinforce your knowledge.
- IPExpert vSeminars. Sometimes useful. I hate that they take the time to setup the lab during the live session. If you can't assign IP addresses, setup trunk ports and assign VLANs - you have no business wasting internet bandwidth watching the vSeminar. I recently attended one on multicast and after watching for 1.5 hours, they didn't make it past setting up PIM neighbor relationships. I still appreciate that they offer this for free.
- Ruhan's CCIE Short Notes. Such a great book and something I will keep with me throughout my professional career. Give him some love - http://blog.ru.co.za/ccie-rs-short-notes-v4/
- And last but not least - the Cisco DocCD. This should a very important aspect of your studies. Not only have I read the core topics from cover-to-cover, but I still like to bounce around during my labs. This way I can read what it is I am doing, and I can remember where certain items are located in the event I need to reference them in the doc cd. Both the configuration guides and the command reference are your friends.
Wish me luck everyone. I hope to have good news Monday evening.
Wednesday, July 7, 2010
INE Workbook VOl 2 Lab 12 & Lab 13
Sometimes, you may need to filter in two locations. In the first scenario, you needed to filter on the switch and on the router. The scenario asked to configure SW1 or R1 so this could be a tricky scenario. On the switch side, I just added the mac address to an unused port to prevent communication. On the router side, I matched the source mac address in a class-map and dropped the traffic.
With an OSPF network type of broadcast, you will see both net link states and summary net link states for the OSPF area. A network type of point-to-point treats the local network slightly different, it will not have a net link entry for the area. Seeing the scenario, and reading that it now makes sense.
If you are using a line password, the login 'block' feature will not work. You must use AAA or the local database.
You only need two additional options to use a remote DHCP server to assign IP addresses via PPP.
ip address-pool dhcp-proxy-client
ip dhcp-server 139.1.11.100
This if in addition to the client 'ip address negotiated' and the host 'peer default ip address dhcp' commands.
If you are sending prefixes out to backbones at multiple locations, you may want to filter routes inbound so you do not learn the same route from another location.
With BGP synchronization, iBGP routes received from an iBGP neighbor must be present in the IGP routing table to be considered best paths. I always think of this a different way - which is wrong. I was under the impression that a route must be present in the IGP routing table before it can be advertised to another iBGP peer. The synchronization issue come from received routes, not advertised routes. The only rule that applies with advertisements is that the bgp advertisement must have a match in the routing table - be it static routes to null 0 or IGP. This is an important distinction in that iBGP routes must be redistributed into IGP between iBGP peers. This is to prevent a black-hole where an intermediary routers between the peers does not run BGP. Also be careful of OSPF/BGP router-id's when working with synchronization.
I made ISATAP tunneling more difficult than it needed to be. Part of the problem was I got it mixed up with 6to4 tunnels. With ISATAP, create the tunnel interfaces and set the source interface and the mode. Assign the requested IPV6 prefix using eui-64 for the host portion. Now all you need are your static routes - but where do you point them to? This is where some similarity between 6to4 and ISATAP come in. Your static route destination will be like so for a route from R3 to R4 loopback interface.
ipv6 route 2001:cc1e:1:4::/64 2001:cc1e:1:345:0:5efe:9601:404
The 2001:cc1e:1:345 is just the standard IPv6 prefix for the tunnel. 0:5efe is part of the ISATAP specification and should be placed between the prefix and the host address. 9601:404 is simply the hex representation of R4's loopback 0 interface (which is the source interface for it's tunnel back to R3. Here are the DocCD details - http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-tunnel_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1055566
So here is the full configuration for completeness:
R3
int tun345
ipv add 2001:cc1e:1:345::/64 eui-64
tunn so lo0
tunn mode ipv6ip isatap
!
ipv6 route 2001:cc1e:1:4::/64 2001:cc1e:1:345:0:5efe:9601:404
ipv6 route 2001:cc1e:1:5::/64 2001:cc1e:1:345:0:5efe:9601:505
R4
int tun345
ipv add 2001:cc1e:1:345::/64 eui-64
tunn so lo0
tunn mode ipv6ip isatap
!
int lo0
ipv add 2001:cc1e:1:4::4/64
!
ipv6 route ::/0 2001:cc1e:1:345:0:5efe:9601:303
R5
int tun345
ipv add 2001:cc1e:1:345::/64 eui-64
tunn so lo0
tunn mode ipv6ip isatap
!
int lo0
ipv add 2001:cc1e:1:5::5/64
!
ipv6 route ::/0 2001:cc1e:345:0:5efe:9601:303
The reason we are sending traffic from R4/R5 to R3 is because R3 is participating in OSPFv3 and providing IPv6 routing for the rest of the network. Thus, we also redistribute static in OSPF so that ospf neighbor routers can reach R4/R5. You could do this with any number of routers - just have one as the 'hub'. With two routers, you would just point them to each other. If this sounds like frame-relay, that is because that's really what it is. ISATAP treats the underlying IPv4 network as NBMA.
'ip dhcp relay information policy keep' will retain Option 82 information. This is a global exec command.
'ip dhcp relay information trust' will trust the Option 82 information with a 0.0.0.0 giaddr. This is an interface command.
'ip dhcp relay information trust-all' is the global equivalent of the above interface command.
If you get a scenario asking you about collecting traffic being sent/received on an interface, storing it locally and providing you with 5 minute averages - the solution is not ip accounting and it is not netflow. The correct answer is 'ip nbar protocol-discovery'. Pretty simple eh?
You can also create a flow monitor to capture information.
flow monitor TEST <= defines a flow monitor
statistics packet protocol <= capture packet protocol
statistics packet size <= capture packet size
record netflow ipv4 protocol-port-tos <= record netflow protocol, port and TOS counts
interface fa0/1
ip flow monitor TEST output <= capture output packets
ip accounting output-packets <= enable ip accounting output
Be very careful with policy routing. Although the configuration is pretty straight-forward, pay attention to where you place it. If there are multiple paths through the network, you will need to select the right location to apply the policy.
'frame-relay ip rtp priority 16384 16383 512' will prioritize RTP packets up to the configured rate, which is 512k here.
And with that, lab 12 and lab 13 are complete. Had a few things through me for a loop, and some other things that were messed up by INE. Overall, not too bad. I believe both labs were a level 9. Off now to prep for the next lab. Troubleshooting tomorrow and start on the next lab. Only a few days left....the clock is ticking....
With an OSPF network type of broadcast, you will see both net link states and summary net link states for the OSPF area. A network type of point-to-point treats the local network slightly different, it will not have a net link entry for the area. Seeing the scenario, and reading that it now makes sense.
If you are using a line password, the login 'block' feature will not work. You must use AAA or the local database.
You only need two additional options to use a remote DHCP server to assign IP addresses via PPP.
ip address-pool dhcp-proxy-client
ip dhcp-server 139.1.11.100
This if in addition to the client 'ip address negotiated' and the host 'peer default ip address dhcp' commands.
If you are sending prefixes out to backbones at multiple locations, you may want to filter routes inbound so you do not learn the same route from another location.
With BGP synchronization, iBGP routes received from an iBGP neighbor must be present in the IGP routing table to be considered best paths. I always think of this a different way - which is wrong. I was under the impression that a route must be present in the IGP routing table before it can be advertised to another iBGP peer. The synchronization issue come from received routes, not advertised routes. The only rule that applies with advertisements is that the bgp advertisement must have a match in the routing table - be it static routes to null 0 or IGP. This is an important distinction in that iBGP routes must be redistributed into IGP between iBGP peers. This is to prevent a black-hole where an intermediary routers between the peers does not run BGP. Also be careful of OSPF/BGP router-id's when working with synchronization.
I made ISATAP tunneling more difficult than it needed to be. Part of the problem was I got it mixed up with 6to4 tunnels. With ISATAP, create the tunnel interfaces and set the source interface and the mode. Assign the requested IPV6 prefix using eui-64 for the host portion. Now all you need are your static routes - but where do you point them to? This is where some similarity between 6to4 and ISATAP come in. Your static route destination will be like so for a route from R3 to R4 loopback interface.
ipv6 route 2001:cc1e:1:4::/64 2001:cc1e:1:345:0:5efe:9601:404
The 2001:cc1e:1:345 is just the standard IPv6 prefix for the tunnel. 0:5efe is part of the ISATAP specification and should be placed between the prefix and the host address. 9601:404 is simply the hex representation of R4's loopback 0 interface (which is the source interface for it's tunnel back to R3. Here are the DocCD details - http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-tunnel_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1055566
So here is the full configuration for completeness:
R3
int tun345
ipv add 2001:cc1e:1:345::/64 eui-64
tunn so lo0
tunn mode ipv6ip isatap
!
ipv6 route 2001:cc1e:1:4::/64 2001:cc1e:1:345:0:5efe:9601:404
ipv6 route 2001:cc1e:1:5::/64 2001:cc1e:1:345:0:5efe:9601:505
R4
int tun345
ipv add 2001:cc1e:1:345::/64 eui-64
tunn so lo0
tunn mode ipv6ip isatap
!
int lo0
ipv add 2001:cc1e:1:4::4/64
!
ipv6 route ::/0 2001:cc1e:1:345:0:5efe:9601:303
R5
int tun345
ipv add 2001:cc1e:1:345::/64 eui-64
tunn so lo0
tunn mode ipv6ip isatap
!
int lo0
ipv add 2001:cc1e:1:5::5/64
!
ipv6 route ::/0 2001:cc1e:345:0:5efe:9601:303
The reason we are sending traffic from R4/R5 to R3 is because R3 is participating in OSPFv3 and providing IPv6 routing for the rest of the network. Thus, we also redistribute static in OSPF so that ospf neighbor routers can reach R4/R5. You could do this with any number of routers - just have one as the 'hub'. With two routers, you would just point them to each other. If this sounds like frame-relay, that is because that's really what it is. ISATAP treats the underlying IPv4 network as NBMA.
'ip dhcp relay information policy keep' will retain Option 82 information. This is a global exec command.
'ip dhcp relay information trust' will trust the Option 82 information with a 0.0.0.0 giaddr. This is an interface command.
'ip dhcp relay information trust-all' is the global equivalent of the above interface command.
If you get a scenario asking you about collecting traffic being sent/received on an interface, storing it locally and providing you with 5 minute averages - the solution is not ip accounting and it is not netflow. The correct answer is 'ip nbar protocol-discovery'. Pretty simple eh?
You can also create a flow monitor to capture information.
flow monitor TEST <= defines a flow monitor
statistics packet protocol <= capture packet protocol
statistics packet size <= capture packet size
record netflow ipv4 protocol-port-tos <= record netflow protocol, port and TOS counts
interface fa0/1
ip flow monitor TEST output <= capture output packets
ip accounting output-packets <= enable ip accounting output
Be very careful with policy routing. Although the configuration is pretty straight-forward, pay attention to where you place it. If there are multiple paths through the network, you will need to select the right location to apply the policy.
'frame-relay ip rtp priority 16384 16383 512' will prioritize RTP packets up to the configured rate, which is 512k here.
And with that, lab 12 and lab 13 are complete. Had a few things through me for a loop, and some other things that were messed up by INE. Overall, not too bad. I believe both labs were a level 9. Off now to prep for the next lab. Troubleshooting tomorrow and start on the next lab. Only a few days left....the clock is ticking....
Tuesday, July 6, 2010
What is missing?
I have typed so many ip addresses on this keyboard. And no, its not a cheap one.
Published with Blogger-droid v1.4.1
Monday, July 5, 2010
INE Workbook Vol 2 Lab 9, 10, 11
By default, the EIGRP hello interface is 60 seconds for low speed NBMA interfaces and 5 seconds for all other media. So if you change the hold timer on a NBMA interface to less than 60 seconds, you better change the hello interval as well - to 1/3 the hold timer.
Also, EIGRP hold-time is transmitted in the hello packets and locally configured EIGRP hold-time actually specifies the hold-time for the remote side. So you only need to configure one side.
I believe I would have still gotten the points, BUT Narbik teaches something very important. BE VERY SPECIFIC and don't do more than what is needed. Not only is there not a discrepency in your solution, but the proctor will know that you really know the protocol/feature/etc inside and out.
When doing key accept/send lifetimes and you need to specify the start time as the present or in the past - set it to Jan 1 1993. This way there is no discrepancy since the router will always understand this date regardless of configured time/ntp parameters. I took the long way of setting the start lifetime for now, and then manually setting the clock.
'show ip eigrp interface detail fastEthernet 1/5' will show you the interface details for EIGRP. Not 'show ip eigrp interface fa1/15 det' like you would expect.
You can use the cli command 'renew dhcp FastE0/0' to renew an IP address. Subsequently, you can schedule this using Kron.
MQC uses the mincir value in the frame-relay map-class to determine the available bandwidth on a vc. Since mincir defaults to half the configured CIR, it may be required to adjust the MINCIR values higher if the reserved bandwidth exceeds half of the configured CIR.
When implementing IOS Firewall, it will only inspect after an access-group entry. So if you are permitting all TCP traffic on an access list, and then impement IOS firewall to inspect TCP traffic - it will never be inspected because the router will process the access-list before the inspection rules. Oversight like this can lose you 3 points. Also, be weary of the 'router-traffic option'. If you need to originate traffic from the router itself, you will need to add router-traffic to the inspection rule. IE; initiate H.323 call from R6 to BB1. To allow the return traffic to come in from BB1 to R6, you must add 'router-traffic'.
Here is a pretty interesting way of only allowing IP traffic...
bridge 56 route ip
bridge 56 route ipx
!
interface FastEthernet0/0
ip address 187.1.56.6 255.255.255.0
speed 100
full-duplex
ipv6 address FE80::6 link-local
ipv6 address 2001:187:1:56::6/64
ipv6 ospf 6 area 1 instance 99
bridge-group 56
bridge-group 56 input-lsap-list 201
!
access-list 201 permit 0x0800 0x0000
INE leads me to believe that if you use a rate-limit access-list to police traffic for a specified precedence, it will treat all other traffic differently, so you need to 'catch' the remaining traffic with precedence values accordingly.
access-list rate-limit 3 3
access-list rate-limit 1 mask FF
The first line just matches prec 3. The 2nd line matches any precedence value (mask FF). Now just configure CAR accordingly. I would have assumed you could have just done a standard rate-limit command without matching on any traffic. I will need to lab this up to verify.
Overall, these labs were not too difficult again. These were a difficulty level 8 or 9. I don't believe these labs to be hard at all - just very intense and time consuming. You would need to be very fast and efficient to complete these labs in 6 hours. And no I didn't do all these labs in a day - I've just been accumulating notes for multiple labs.
Man...only one more week and I'll be sitting in RTP.....
Also, EIGRP hold-time is transmitted in the hello packets and locally configured EIGRP hold-time actually specifies the hold-time for the remote side. So you only need to configure one side.
I believe I would have still gotten the points, BUT Narbik teaches something very important. BE VERY SPECIFIC and don't do more than what is needed. Not only is there not a discrepency in your solution, but the proctor will know that you really know the protocol/feature/etc inside and out.
When doing key accept/send lifetimes and you need to specify the start time as the present or in the past - set it to Jan 1 1993. This way there is no discrepancy since the router will always understand this date regardless of configured time/ntp parameters. I took the long way of setting the start lifetime for now, and then manually setting the clock.
'show ip eigrp interface detail fastEthernet 1/5' will show you the interface details for EIGRP. Not 'show ip eigrp interface fa1/15 det' like you would expect.
You can use the cli command 'renew dhcp FastE0/0' to renew an IP address. Subsequently, you can schedule this using Kron.
MQC uses the mincir value in the frame-relay map-class to determine the available bandwidth on a vc. Since mincir defaults to half the configured CIR, it may be required to adjust the MINCIR values higher if the reserved bandwidth exceeds half of the configured CIR.
When implementing IOS Firewall, it will only inspect after an access-group entry. So if you are permitting all TCP traffic on an access list, and then impement IOS firewall to inspect TCP traffic - it will never be inspected because the router will process the access-list before the inspection rules. Oversight like this can lose you 3 points. Also, be weary of the 'router-traffic option'. If you need to originate traffic from the router itself, you will need to add router-traffic to the inspection rule. IE; initiate H.323 call from R6 to BB1. To allow the return traffic to come in from BB1 to R6, you must add 'router-traffic'.
Here is a pretty interesting way of only allowing IP traffic...
bridge 56 route ip
bridge 56 route ipx
!
interface FastEthernet0/0
ip address 187.1.56.6 255.255.255.0
speed 100
full-duplex
ipv6 address FE80::6 link-local
ipv6 address 2001:187:1:56::6/64
ipv6 ospf 6 area 1 instance 99
bridge-group 56
bridge-group 56 input-lsap-list 201
!
access-list 201 permit 0x0800 0x0000
INE leads me to believe that if you use a rate-limit access-list to police traffic for a specified precedence, it will treat all other traffic differently, so you need to 'catch' the remaining traffic with precedence values accordingly.
access-list rate-limit 3 3
access-list rate-limit 1 mask FF
The first line just matches prec 3. The 2nd line matches any precedence value (mask FF). Now just configure CAR accordingly. I would have assumed you could have just done a standard rate-limit command without matching on any traffic. I will need to lab this up to verify.
Overall, these labs were not too difficult again. These were a difficulty level 8 or 9. I don't believe these labs to be hard at all - just very intense and time consuming. You would need to be very fast and efficient to complete these labs in 6 hours. And no I didn't do all these labs in a day - I've just been accumulating notes for multiple labs.
Man...only one more week and I'll be sitting in RTP.....
Friday, June 25, 2010
INE Workbook Vol 2 Lab 8
You can use bandwidth to adjust STP costs as opposed to using the 'spanning-tree vlan x' command.
When you are doing PPP authentication over MLPPP, you need to enable the authentication parameters on the virtual-template interface and NOT the multilink group interface.
Always be on the lookout for split-horizon issues!! ALWAYS!
I found a big problem with doing the following:
R5
router eigrp 1024
redistribute rip metric 1 1 1 1 1
If, you need to adjust the metrics on neighboring EIGRP routers (variance, traffic share), your metric values will be too small to manipulate. EIGRP will take the smallest bandwidth in the path (1 as configured with the redistribute command) leaving you will only DELAY to manipulate. Usually this is a good thing, but even setting delay to the highest on one interface, and the lowest on the other interface, you will never get a traffic share of roughly 1:2. So - if you need to traffic share 1:4, you are screwed. Now - is it best to do 1 1 1 1 1 or something more like 1544 1 255 1 1500 for metric values? That I cannot say for sure. If you read through your lab and you see you will need to traffic share/load balance, I would set the metrics to more normal values.
You can fix BGP next-hop reachability by using a route-map and using 'set ip next-hop peer-address'. Just make sure that your peer address is reachable throughout your bgp domain.
By default BGP routers will only compare MED between prefixes learned from the same autonomous system. So if you need to influence the backbone routers for inbound traffic, you COULD use MED provided all your BGP routers are in the same AS, but you could also use AS-path prepending.
I always forget that you can attach a route-map to a network statement. So if you get a task for filtering a bgp originated route, and you cannot use prefix-lists or access-lists, a route-map attached to the network statement will be the way to go.
You can attach a group access-list to the 'ip pim send-rp-annouce' command to set a router to only advertise itself as the auto-rp candidate for a certain subset of multicast groups. This configuration is done at the Auto-RP candidate. You also set the rp-announce-filter on the auto-rp mapping agent.
ip pim send-rp-discovery Loopback0 scope 10
ip pim rp-announce-filter rp-list R1_RP group-list R1_Groups
ip pim rp-announce-filter rp-list R2_RP group-list R2_Groups
ip access-list standard R1_Groups
permit 224.0.0.0 0.255.255.255
permit 226.0.0.0 0.255.255.255
permit 228.0.0.0 0.255.255.255
permit 230.0.0.0 0.255.255.255
permit 232.0.0.0 0.255.255.255
permit 234.0.0.0 0.255.255.255
permit 236.0.0.0 0.255.255.255
permit 238.0.0.0 0.255.255.255
ip access-list standard R1_RP
permit 150.1.1.1
ip access-list standard R2_Groups
permit 225.0.0.0 0.255.255.255
permit 227.0.0.0 0.255.255.255
permit 229.0.0.0 0.255.255.255
permit 231.0.0.0 0.255.255.255
permit 233.0.0.0 0.255.255.255
permit 235.0.0.0 0.255.255.255
permit 237.0.0.0 0.255.255.255
permit 239.0.0.0 0.255.255.255
ip access-list standard R2_RP
permit 150.1.2.2
What I am not sure about is if you are required to do both. I suppose this would depend on your multicast topology but it's probably safer to do both.
I wasn't getting my RP mappings across my frame-relay interfaces. There was two solutions to this problem - one that wasn't solved by INE. R1 (the hub F/R router) had the wrong RPF interface for R2 and R3. A simple mroute fixed this issue. The other issue is PIM NBMA. Multicast traffic coming in from a spoke to another spoke will not work without PIM NBMA mode. Think of this like a split-horizon type issue. The pim nbma-mode takes the multicast traffic and treats each PIM neighbor like a point-to-point interface. Why listen to me drabble on about it - get it right from the horse's mouth..... Using IP Multicast over Frame-Relay Networks
Multicast helper is used to transfer broadcast traffic between two end points across a multicast network. There are several caveats such as using 'ip forward-protocol' to process-switch the traffic instead of fast-switching. You also need to apply the multicast helper map on the INCOMING interface of the last hop router (facing the multicast network) and not on the OUTGOING interface of the last hop router (facing the client). DocCD is your friend. If you see this in the lab, you should know exactly where to go....http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_inter_mc_helper_ps6441_TSD_Products_Configuration_Guide_Chapter.html
INE presents an interesting way to prevent transit traffic between two end nodes. R5 interface Fa0/1 has two subinterfaces - one to BB2 and one to BB3. By matching the input interface and dropping that traffic, R5 can no longer be used as a transit between the two nodes.
class-map match-all FROM_BB3
match input-interface FastEthernet0/1
class-map match-all FROM_BB2
match input-interface FastEthernet0/1
policy-map TO_BB2
class FROM_BB3
drop
policy-map TO_BB3
class FROM_BB2
drop
interface FastEthernet0/1.52
ip address 192.10.1.5 255.255.255.0
service-policy output TO_BB2
interface FastEthernet0/1.53
ip address 204.12.1.5 255.255.255.0
service-policy output TO_BB3
A little out there, but still feasible.
In order to tune a shapers queue, you need to apply a nested service-policy.
policy-map CBWFQ
class class-default
bandwidth percent 100
queue-limit 10
policy-map FRTS
class class-default
shape average 128000
service-policy CBWFQ
And with that, lab 8 is done. Again, not difficult at all and at points can be very tricky. I am getting much better at paying very close attention and doing exactly what is asked in the scenario. Going forward, I need to work on getting much faster as well. Tomorrow I plan to hit Narbik's troubleshooting scenario and then next Monday and Tuesday I've rented some rack time from INE and I plan to complete a few of their troubleshooting labs.
When you are doing PPP authentication over MLPPP, you need to enable the authentication parameters on the virtual-template interface and NOT the multilink group interface.
Always be on the lookout for split-horizon issues!! ALWAYS!
I found a big problem with doing the following:
R5
router eigrp 1024
redistribute rip metric 1 1 1 1 1
If, you need to adjust the metrics on neighboring EIGRP routers (variance, traffic share), your metric values will be too small to manipulate. EIGRP will take the smallest bandwidth in the path (1 as configured with the redistribute command) leaving you will only DELAY to manipulate. Usually this is a good thing, but even setting delay to the highest on one interface, and the lowest on the other interface, you will never get a traffic share of roughly 1:2. So - if you need to traffic share 1:4, you are screwed. Now - is it best to do 1 1 1 1 1 or something more like 1544 1 255 1 1500 for metric values? That I cannot say for sure. If you read through your lab and you see you will need to traffic share/load balance, I would set the metrics to more normal values.
You can fix BGP next-hop reachability by using a route-map and using 'set ip next-hop peer-address'. Just make sure that your peer address is reachable throughout your bgp domain.
By default BGP routers will only compare MED between prefixes learned from the same autonomous system. So if you need to influence the backbone routers for inbound traffic, you COULD use MED provided all your BGP routers are in the same AS, but you could also use AS-path prepending.
I always forget that you can attach a route-map to a network statement. So if you get a task for filtering a bgp originated route, and you cannot use prefix-lists or access-lists, a route-map attached to the network statement will be the way to go.
You can attach a group access-list to the 'ip pim send-rp-annouce' command to set a router to only advertise itself as the auto-rp candidate for a certain subset of multicast groups. This configuration is done at the Auto-RP candidate. You also set the rp-announce-filter on the auto-rp mapping agent.
ip pim send-rp-discovery Loopback0 scope 10
ip pim rp-announce-filter rp-list R1_RP group-list R1_Groups
ip pim rp-announce-filter rp-list R2_RP group-list R2_Groups
ip access-list standard R1_Groups
permit 224.0.0.0 0.255.255.255
permit 226.0.0.0 0.255.255.255
permit 228.0.0.0 0.255.255.255
permit 230.0.0.0 0.255.255.255
permit 232.0.0.0 0.255.255.255
permit 234.0.0.0 0.255.255.255
permit 236.0.0.0 0.255.255.255
permit 238.0.0.0 0.255.255.255
ip access-list standard R1_RP
permit 150.1.1.1
ip access-list standard R2_Groups
permit 225.0.0.0 0.255.255.255
permit 227.0.0.0 0.255.255.255
permit 229.0.0.0 0.255.255.255
permit 231.0.0.0 0.255.255.255
permit 233.0.0.0 0.255.255.255
permit 235.0.0.0 0.255.255.255
permit 237.0.0.0 0.255.255.255
permit 239.0.0.0 0.255.255.255
ip access-list standard R2_RP
permit 150.1.2.2
What I am not sure about is if you are required to do both. I suppose this would depend on your multicast topology but it's probably safer to do both.
I wasn't getting my RP mappings across my frame-relay interfaces. There was two solutions to this problem - one that wasn't solved by INE. R1 (the hub F/R router) had the wrong RPF interface for R2 and R3. A simple mroute fixed this issue. The other issue is PIM NBMA. Multicast traffic coming in from a spoke to another spoke will not work without PIM NBMA mode. Think of this like a split-horizon type issue. The pim nbma-mode takes the multicast traffic and treats each PIM neighbor like a point-to-point interface. Why listen to me drabble on about it - get it right from the horse's mouth..... Using IP Multicast over Frame-Relay Networks
Multicast helper is used to transfer broadcast traffic between two end points across a multicast network. There are several caveats such as using 'ip forward-protocol' to process-switch the traffic instead of fast-switching. You also need to apply the multicast helper map on the INCOMING interface of the last hop router (facing the multicast network) and not on the OUTGOING interface of the last hop router (facing the client). DocCD is your friend. If you see this in the lab, you should know exactly where to go....http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_inter_mc_helper_ps6441_TSD_Products_Configuration_Guide_Chapter.html
INE presents an interesting way to prevent transit traffic between two end nodes. R5 interface Fa0/1 has two subinterfaces - one to BB2 and one to BB3. By matching the input interface and dropping that traffic, R5 can no longer be used as a transit between the two nodes.
class-map match-all FROM_BB3
match input-interface FastEthernet0/1
class-map match-all FROM_BB2
match input-interface FastEthernet0/1
policy-map TO_BB2
class FROM_BB3
drop
policy-map TO_BB3
class FROM_BB2
drop
interface FastEthernet0/1.52
ip address 192.10.1.5 255.255.255.0
service-policy output TO_BB2
interface FastEthernet0/1.53
ip address 204.12.1.5 255.255.255.0
service-policy output TO_BB3
A little out there, but still feasible.
In order to tune a shapers queue, you need to apply a nested service-policy.
policy-map CBWFQ
class class-default
bandwidth percent 100
queue-limit 10
policy-map FRTS
class class-default
shape average 128000
service-policy CBWFQ
And with that, lab 8 is done. Again, not difficult at all and at points can be very tricky. I am getting much better at paying very close attention and doing exactly what is asked in the scenario. Going forward, I need to work on getting much faster as well. Tomorrow I plan to hit Narbik's troubleshooting scenario and then next Monday and Tuesday I've rented some rack time from INE and I plan to complete a few of their troubleshooting labs.
Wednesday, June 23, 2010
INE Workbook Vol 2 Lab 7
Remember that by default 3560 switches do not trust CoS values and will re-write all CoS values with 0. So you either need to trust the ip phone, or trust CoS5 or whatever CoS values the phone is sending. 'switchport priority extend cos 1' will set the CoS on frames attached to the appliance (PC) instead of re-writing to 0. Verify all this with the 'show interface fa1/3 switchport' as well as 'show mls qos interface fa1/3'.
Rack1SW2(config-if)#do sh int fa1/3 switchport
Name: Fa1/3
Switchport: Enabled
Administrative Mode: dynamic access
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: Disabled
Access Mode VLAN: 5 (VLAN0005)
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Enabled: ALL
Trunking VLANs Active: none
Protected: false
Priority for untagged frames: 0
Override vlan tag priority: FALSE
Voice VLAN: 4
Appliance trust: 1
Rack1SW2(config-if)#do sh mls qos int fa1/3
FastEthernet1/3
trust state: trust cos
trust mode: trust cos
COS override: dis
default COS: 0
I got killed again but not paying attention. Words like 'only' can mean a lot. In my instance, I forgot to set a distribute-list on RIP to advertise ONLY the summary routes. I also got killed because I filtered all updates to a RIP neighbor, instead of only one route. These are very simple mistakes, but I got tossed 4 very easy points out the windows...sigh....
Very important - with OSPF always make sure you do NOT have dis contiguous area 0's. In the OSPF scenario, I accomplished everything they wanted me to - except I had dis-contiguous area 0's. And remember, that there are two ways to connect area 0's - a tunnel interface running in area 0, or a virtual-link. Be careful, because both methods will not produce the same exact results. Another 5 points lost....but hey, I'm still learning here!
The redistribution scenario was pretty crazy. I won't get into details, but I need more practice...just need to take it one step at a time. I always knew this was one of my weaknesses, and something I hope these fulls labs teach me to do. Nothing like repetition I say...
INE has a nice table describing BGP best path selection...
Rack1SW2(config-if)#do sh int fa1/3 switchport
Name: Fa1/3
Switchport: Enabled
Administrative Mode: dynamic access
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: Disabled
Access Mode VLAN: 5 (VLAN0005)
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Enabled: ALL
Trunking VLANs Active: none
Protected: false
Priority for untagged frames: 0
Override vlan tag priority: FALSE
Voice VLAN: 4
Appliance trust: 1
Rack1SW2(config-if)#do sh mls qos int fa1/3
FastEthernet1/3
trust state: trust cos
trust mode: trust cos
COS override: dis
default COS: 0
I got killed again but not paying attention. Words like 'only' can mean a lot. In my instance, I forgot to set a distribute-list on RIP to advertise ONLY the summary routes. I also got killed because I filtered all updates to a RIP neighbor, instead of only one route. These are very simple mistakes, but I got tossed 4 very easy points out the windows...sigh....
Very important - with OSPF always make sure you do NOT have dis contiguous area 0's. In the OSPF scenario, I accomplished everything they wanted me to - except I had dis-contiguous area 0's. And remember, that there are two ways to connect area 0's - a tunnel interface running in area 0, or a virtual-link. Be careful, because both methods will not produce the same exact results. Another 5 points lost....but hey, I'm still learning here!
The redistribution scenario was pretty crazy. I won't get into details, but I need more practice...just need to take it one step at a time. I always knew this was one of my weaknesses, and something I hope these fulls labs teach me to do. Nothing like repetition I say...
INE has a nice table describing BGP best path selection...
Attribute Direction Applied Traffic Flow Affected
--------------------------------------------------------------
Weight Inbound Outbound
Local-Pref Inbound Outbound
AS-Path Outbound Inbound
MED Outbound Inbound
The only one that trips me up is MED. Just remember that you set MED outbound to influence INBOUND traffic.
When setting BGP timers, you must also disable 'bgp fast-external-fallover', otherwise the routes are immediately withdrawn upon the BGP session tear-down.
Again, be very careful with the wording of each scenario and check and verify everything. I need to unsupress from routes to certain neighbors, which I accomplished correctly, but that task also stated to only those neighbors in AS300 should see the specific summary routes, all others should still get the summary. Well, if you don't set community no-export in your unsupress map, your routers that should have only had the aggregate, now have your unsupressed routes as well. Doh!
Also a good tip - it is best to always consolidate all attribute settings in a single route-map. Otherwise, the BGP order of operations can give you un-desirable results. Do not mix and match the application of route-maps, unsupress-maps, attribute-maps, distribute-lists, prefix-lists or filter-lists to the same neighbor in the same direction. Great tip...thanks INE!
Apply IPv6 access-lists with 'ipv6 traffic-filter' instead of 'ip access-group'. It's nice for cisco to right the ship and make the command syntax sounds like what we are actually doing it - but why not make everything consistent? There is no 'ip traffic-filter' and there is no 'ipv6 access-group'. This is one of my biggest pet peeves with Cisco IOS.......by the way Apple, enjoy paying Cisco just for calling your os iOS.....how stupid....
A very important but often overlooked point, the 'ip igmp join-group' command should be place on the client interface, or on the interface receiving traffic from the group, not the other way around.
When filtering on HTTP requests using a class-map, remember that this is a regex express. Thus to filter root.exe, you should configure 'match protocol http url "*root.exe*". Notice the double-quotes as this is important.
Local Area Mobility (LAM) is something I haven't seen in INE's or Narbik's Volume 1 workbooks. What gives? Anyway, it offers hosts a simple way to roam around the network. When 'ip mobile arp' is issued on an interface, the LAM process starts listening for ARP requests received on the interface that are from hosts which are not in the IP subnet of that interface. When these request are received, the LAM process knows these came from a mobile host. The hosts IP address is then installed in the IP routing table as a mobile host route. The access-group command tells the router which hosts to listen for arp requests from. You would then need to redistribute mobile routes into your IGP.
interface FastEthernet0/0
ip address 163.1.6.6 255.255.255.0
ip mobile arp access-group 2
!
router rip
version 2
redistribute mobile metric 1
network 54.0.0.0
network 150.1.0.0
network 163.1.0.0
network 204.12.1.0
distribute-list prefix RIP out FastEthernet0/1
distribute-list gateway BB1-BB3 in
no auto-summary
!
access-list 2 permit 163.1.5.25
From the above, the hosts in VLAN6 can now receive traffic for 163.1.5.25.
Remember that you can apply a netflow sampler-map using policy-maps. At this point, I'm not sure why would would have to do this (unless you were selectively exporting certain traffic) over just using the 'flow-sampler' interface command. Also, with PPP, you apply the flow ingress/egress or service-policies on the physical interface.
With RSH, you need to configure the remote-host based on hostnames as well as a username. At least that is what I take out of it. I have yet to find the configuration guide.
Lab 7 is done and complete. For being a difficulty level 9, I didn't think it was that hard. It was tricky at times, but is totally do-able. The worry here is the amount of work between a level 7 and a level 9 is pretty great, so you would really have to know your stuff to complete the level 9 lab in 6 hours. I liked this lab and thoroughly enjoyed it - even though it took me three days to complete. It took me three days because I was consumed with work - not because it took me that long! All in all though, it probably took me closer to 8 hours to complete as opposed to 5-6 hours. That's why I am doing these labs - to take my time and learn, and then to get faster. I don't know why I was scared of the difficulty level 9 labs....
Hopefully I'll squeeze in a full lab tomorrow, and then troubleshooting on Friday. For now, I'm off to load up my routers for tomorrow and call it a day.
When filtering on HTTP requests using a class-map, remember that this is a regex express. Thus to filter root.exe, you should configure 'match protocol http url "*root.exe*". Notice the double-quotes as this is important.
Local Area Mobility (LAM) is something I haven't seen in INE's or Narbik's Volume 1 workbooks. What gives? Anyway, it offers hosts a simple way to roam around the network. When 'ip mobile arp' is issued on an interface, the LAM process starts listening for ARP requests received on the interface that are from hosts which are not in the IP subnet of that interface. When these request are received, the LAM process knows these came from a mobile host. The hosts IP address is then installed in the IP routing table as a mobile host route. The access-group command tells the router which hosts to listen for arp requests from. You would then need to redistribute mobile routes into your IGP.
interface FastEthernet0/0
ip address 163.1.6.6 255.255.255.0
ip mobile arp access-group 2
!
router rip
version 2
redistribute mobile metric 1
network 54.0.0.0
network 150.1.0.0
network 163.1.0.0
network 204.12.1.0
distribute-list prefix RIP out FastEthernet0/1
distribute-list gateway BB1-BB3 in
no auto-summary
!
access-list 2 permit 163.1.5.25
From the above, the hosts in VLAN6 can now receive traffic for 163.1.5.25.
Remember that you can apply a netflow sampler-map using policy-maps. At this point, I'm not sure why would would have to do this (unless you were selectively exporting certain traffic) over just using the 'flow-sampler' interface command. Also, with PPP, you apply the flow ingress/egress or service-policies on the physical interface.
With RSH, you need to configure the remote-host based on hostnames as well as a username. At least that is what I take out of it. I have yet to find the configuration guide.
Lab 7 is done and complete. For being a difficulty level 9, I didn't think it was that hard. It was tricky at times, but is totally do-able. The worry here is the amount of work between a level 7 and a level 9 is pretty great, so you would really have to know your stuff to complete the level 9 lab in 6 hours. I liked this lab and thoroughly enjoyed it - even though it took me three days to complete. It took me three days because I was consumed with work - not because it took me that long! All in all though, it probably took me closer to 8 hours to complete as opposed to 5-6 hours. That's why I am doing these labs - to take my time and learn, and then to get faster. I don't know why I was scared of the difficulty level 9 labs....
Hopefully I'll squeeze in a full lab tomorrow, and then troubleshooting on Friday. For now, I'm off to load up my routers for tomorrow and call it a day.
Wednesday, June 16, 2010
INE Workbook Vol 2 Lab 6
While in transparent mode, VTP advertisements can be carried through the transparent switch to other connected switches over trunk ports. If you are using DTP and the domains are mis-matched, the trunk will not form. You can override this by enabling static trunk mode, and disabling DTP. Also, VTP version 2 does NOT do any version checking.
Ok, I will say the MPLS section really tripped me up here, not because the scenario was particularly hard, but because partial configurations were there, and I thought I needed to add more configuration to make it work than was really necessary. This proves I need work troubleshooting MPLS. I can build a MPLS pretty easy from the ground up (at least in the CCIE realm) but make an existing one work is still a little bit of a weakness.
Multicast stub routing is accomplished by using the 'ip igmp helper-address x.x.x.x'. The address here is where group membership reports and leave messages will be sent to. When using the helper, typically there is no PIM neighbors between the two routers. Make the proxy router has another PIM interface to forward multicast traffic in the event that your neighbor-filter filtered the only connection.
You can stop communication with a malicious host by configuring a static mac entry and pointing it to an unused or dead interface. You could also use drop, as well as VACL.
I'm starting to get these dynamic ACLs w/ access-enable, but I still can't get there 100%. To prevent access to SW1 without being authenticated, here is the pertinent configurations. Once authenticated with the specified username/password - you can telnet to the host.
username TELNET password 0 CISCO
username TELNET autocommand access-enable
username CLI password 0 CISCO
interface Serial0/0
ip access-group DYNAMIC1 in
!
interface Serial0/1
ip access-group DYNAMIC1 in
!
ip access-list extended DYNAMIC1
dynamic PERMIT_TELNET permit tcp any any eq telnet
deny tcp any host 191.1.27.7 eq telnet
deny tcp any host 191.1.7.7 eq telnet
deny tcp any host 191.1.77.77 eq telnet
deny tcp any host 191.1.177.7 eq telnet
deny tcp any host 150.1.7.7 eq telnet
permit ip any any
!
line vty 0 4
password cisco
login local
line vty 5 903
login local
Fear not! If you do get this on the lab, it's easily found in the DocCD under Security -> Securing the Data Plan -> Configuring Lock and Key Security (dynamic access lists). Here is the directly link which I highly suggest you read... http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_lock_key_secrty_ps6441_TSD_Products_Configuration_Guide_Chapter.html
I get it. You create a regular extended access at list, but at the top you specify a permit statement to match the dynamic ACL. The autocommand access-enable will add the authenticated user to the dynamic access-list. Wow, now that I see it and read through the DocCD, it makes total sense. It's just one of those things you wont see very often. One important point - I believe you can attach the autocommand to either the username or the vty line. Attached to the username means only the specified username, attached to the vty line and it's any authenticated user. Also, when you attach a timeout value to the dynamic ACL, that is the absolute timeout. When you attach timeout to the autocommand, that is the idle timeout. Moving on...
When you are configuring RMON, you can send a trap, or you can log. Whichever one you chose, make sure you setup the proper logging/snmp server (logging 191.1.7.100 or snmp-server host 191.1.7.100 traps public). Again, CLOSE attention to details. Failing to do so would mean you missed out on 3 easy points. You may also need to add 'snmp-server ifindex persist' if not already enabled. I would as to not miss out on those points...if not given the ifindex, find them with 'do sh snmp mib ifmib ifindex'.
Not that I would expect Cisco to want you to know this, but UDP chargen is port 9. You can test UDP small servers with the traceroute command.
There was a tricky scenario that asked you to drop HTTP traffic, but not guarantee it any bandwidth. I simply added random-detect to the class default, as this will indeed drop HTTP traffic before the interface is congested. Now, is this the right answer? I can't be sure as the scenario said nothing about dropping ONLY http traffic. In any event, here is the 100% right answer.
class-map NOT_HTTP
match not proto http
policy-map Voice
class RTP
priority percent 25
class NOT_HTTP
class class-default
fair-queue
random-detect
In short, we removed everything except for HTTP from the class-default so when we enable random detect, only HTTP packets will be dropped in anticipation for interface congestion. Very tricky, but very cool.
With header compression, when it says 32 bi-directional connection, your compression-connections number should actually be 64. Again, another easy 2 points lost.
And with that, I am done with Lab 6. Overall, not really all the difficult, but lack of attention to details and the will to verify can absolutely kill you. My notes above reflect several small items that would have killed me. I love doing these full labs. These vendors all know how to present these to you, just like Cisco does. Is that breaking NDA? No. These guys have taken the exam themselves and have taught and mentored probably thousands of students when it comes to the CCIE. So if for nothing else, these full labs help you get familiar with the language you are likely to see in the real lab.
My time was pretty good on this lab - about 5 hours. I need to get faster, but overall I'm pretty happy with 5 hours right now. Short night, I've had kind of a rough day so I am going to prepare my racks for the next lab and start fresh tomorrow.
Ok, I will say the MPLS section really tripped me up here, not because the scenario was particularly hard, but because partial configurations were there, and I thought I needed to add more configuration to make it work than was really necessary. This proves I need work troubleshooting MPLS. I can build a MPLS pretty easy from the ground up (at least in the CCIE realm) but make an existing one work is still a little bit of a weakness.
Multicast stub routing is accomplished by using the 'ip igmp helper-address x.x.x.x'. The address here is where group membership reports and leave messages will be sent to. When using the helper, typically there is no PIM neighbors between the two routers. Make the proxy router has another PIM interface to forward multicast traffic in the event that your neighbor-filter filtered the only connection.
You can stop communication with a malicious host by configuring a static mac entry and pointing it to an unused or dead interface. You could also use drop, as well as VACL.
I'm starting to get these dynamic ACLs w/ access-enable, but I still can't get there 100%. To prevent access to SW1 without being authenticated, here is the pertinent configurations. Once authenticated with the specified username/password - you can telnet to the host.
username TELNET password 0 CISCO
username TELNET autocommand access-enable
username CLI password 0 CISCO
interface Serial0/0
ip access-group DYNAMIC1 in
!
interface Serial0/1
ip access-group DYNAMIC1 in
!
ip access-list extended DYNAMIC1
dynamic PERMIT_TELNET permit tcp any any eq telnet
deny tcp any host 191.1.27.7 eq telnet
deny tcp any host 191.1.7.7 eq telnet
deny tcp any host 191.1.77.77 eq telnet
deny tcp any host 191.1.177.7 eq telnet
deny tcp any host 150.1.7.7 eq telnet
permit ip any any
!
line vty 0 4
password cisco
login local
line vty 5 903
login local
Fear not! If you do get this on the lab, it's easily found in the DocCD under Security -> Securing the Data Plan -> Configuring Lock and Key Security (dynamic access lists). Here is the directly link which I highly suggest you read... http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_lock_key_secrty_ps6441_TSD_Products_Configuration_Guide_Chapter.html
I get it. You create a regular extended access at list, but at the top you specify a permit statement to match the dynamic ACL. The autocommand access-enable will add the authenticated user to the dynamic access-list. Wow, now that I see it and read through the DocCD, it makes total sense. It's just one of those things you wont see very often. One important point - I believe you can attach the autocommand to either the username or the vty line. Attached to the username means only the specified username, attached to the vty line and it's any authenticated user. Also, when you attach a timeout value to the dynamic ACL, that is the absolute timeout. When you attach timeout to the autocommand, that is the idle timeout. Moving on...
When you are configuring RMON, you can send a trap, or you can log. Whichever one you chose, make sure you setup the proper logging/snmp server (logging 191.1.7.100 or snmp-server host 191.1.7.100 traps public). Again, CLOSE attention to details. Failing to do so would mean you missed out on 3 easy points. You may also need to add 'snmp-server ifindex persist' if not already enabled. I would as to not miss out on those points...if not given the ifindex, find them with 'do sh snmp mib ifmib ifindex'.
Not that I would expect Cisco to want you to know this, but UDP chargen is port 9. You can test UDP small servers with the traceroute command.
There was a tricky scenario that asked you to drop HTTP traffic, but not guarantee it any bandwidth. I simply added random-detect to the class default, as this will indeed drop HTTP traffic before the interface is congested. Now, is this the right answer? I can't be sure as the scenario said nothing about dropping ONLY http traffic. In any event, here is the 100% right answer.
class-map NOT_HTTP
match not proto http
policy-map Voice
class RTP
priority percent 25
class NOT_HTTP
class class-default
fair-queue
random-detect
In short, we removed everything except for HTTP from the class-default so when we enable random detect, only HTTP packets will be dropped in anticipation for interface congestion. Very tricky, but very cool.
With header compression, when it says 32 bi-directional connection, your compression-connections number should actually be 64. Again, another easy 2 points lost.
And with that, I am done with Lab 6. Overall, not really all the difficult, but lack of attention to details and the will to verify can absolutely kill you. My notes above reflect several small items that would have killed me. I love doing these full labs. These vendors all know how to present these to you, just like Cisco does. Is that breaking NDA? No. These guys have taken the exam themselves and have taught and mentored probably thousands of students when it comes to the CCIE. So if for nothing else, these full labs help you get familiar with the language you are likely to see in the real lab.
My time was pretty good on this lab - about 5 hours. I need to get faster, but overall I'm pretty happy with 5 hours right now. Short night, I've had kind of a rough day so I am going to prepare my racks for the next lab and start fresh tomorrow.
Monday, June 14, 2010
OSPF Sham-Links
Pretty cool article that explains and shows how the sham link works. Important point here that I have not picked up from any vendors workbook - the Sham Links makes they MPLS transported routes appear as intra-area (instead of the default inter-area) and thus the reason why you can now tweak the ospf costs between your MPLS link and your backup link.
http://blog.ipexpert.com/2010/06/14/ospf-sham-links/
http://blog.ipexpert.com/2010/06/14/ospf-sham-links/
Saturday, June 12, 2010
INE Workbook Vol 2 Lab 3
Whats that? You heard me say I was going to work on troubleshooting? Well - troubleshooting with Dynamips doesn't work so well and I just couldn't load all the features on my dynamips switches. So I plan to rent some rack time next week. In the mean time, I am moving on to Lab 3. I skipped lab 2 because it was a difficulty 6 and since I'm getting low on time, I am only going to tackle difficulty 7 and above to start. If I have time - I will circle back to the other labs.
With CRB briding, a protocol can be routed on one interface while bridged on another interface. Traffic in the routing domain cannot be passed to the bridged domain. With IRB, a protocol can be routed and bridged on the same interface. For example, with CRB, IPX can be bridged while IP is routed. CRB is legacy and replaced by IRB with the addition of the BVI. Steps to create a bridge include:
With CRB briding, a protocol can be routed on one interface while bridged on another interface. Traffic in the routing domain cannot be passed to the bridged domain. With IRB, a protocol can be routed and bridged on the same interface. For example, with CRB, IPX can be bridged while IP is routed. CRB is legacy and replaced by IRB with the addition of the BVI. Steps to create a bridge include:
- Create a transparent bridge group using 'bridge 1 protocol ieee'. This creates a bridge for non-IP protocols. Add the pertinent interfaces to the bridge with 'bridge-group [num] where num is your bridge group number. These interfaces can now bridge non-IP protocols (aka - fallback bridging).
- To enable IRB, and thus bridge IP protocols, issue the 'bridge irb'. Now you need to select which protocols to route; 'bridge 1 route ip'. Now IP will be routed and bridged. This is not specific to IP and can be accomplished with other protocols..
- Now you need to create the bvi with 'interface bvi 1'. Now all traffic that passed through the bridged domain to the routed domain, and vice versa, must pass through the BVI. Now add any logical configuration such as IP address.
That's it! I am finally getting this bridging thing. I was able to accomplish this except I forget to add the IP address and route IP - mostly because the instructions weren't clear that I needed to do this. You can verify with 'show interface irb'. This will show you what protocols are bridged, and which ones are routed.
Remember that a virtual link IS an Area 0 adjacency so if you are required to authenticate all area 0 adjacencies, you must include authentication on your virtual links!
Boy did I get tripped on the redistribution scenario for a pretty stupid reason - I couldn't figure out how to prefer one route in OSPF over the other...METRIC STUPID! Sheesh. I didn't come up with the solution INE did, but had I altered the metric, my solution would have been the same....This is why I am doing full labs - so I can learn and remember stuff like this!
'timers lsa arrival 2000' will protect against flooding with the same LSA during network instability.
To prevent your BGP AS from being used as a transit AS, use the community NO EXPORT which will prevent advertisement to EBGP neighbors.
Use 'mpls ldp discovery transport-address interface ' to set ldp/tdp to use the specified interface as the TCP connect source instead of what you have set as the router-id (most likely loopback0).
The IGMP static-group command causes the devices to process switch the group specified.
The follow are required in an ACL to permit traceroute to complete.
1 permit icmp any any time-exceeded
2 permit icmp any any port-unreachable
In TCP intercept 'watch' mode, incomplete sessions will be terminated with a RST after 30 seconds. You can set the time with ' ip tcp intercept watch-timeout 15'.
If you get a scenario pointing you to a TFTP server on a vlan and NOT a particular host, you need to set the ip helper-address to the broadcast address of that subnet. Also, you need to enable 'ip directed-broadcast' on the VLAN interface.
'frame-relay interface-dlci 555 protocol ip 136.1.5.2' will assign and IP address via BOOTP to the host on dlci 555 when used on a point-to-point interface. With P2M, a frame-relay map will accomplish the same.
When using subinterfaces with rsvp, the 'ip rsvp' commands will need to be applied on the physical interface as well. If there are multiple subinterfaces, the physical rates should be the sum of all subinterfaces. Also - frame-relay requires fair-queue to be enabled. So if you are using FRTS, be aware...
And with that, I've finished lab 3. To be honest, this lab was not kind to me. I've used the blog here to take notes on the things that tripped me up. Other things that I didn't note here are just oversights that will kill me in the real lab. Read twice, and verify twice. That is my motto. My biggest weakness was the BGP section. If I have time, I would like to tackle both INE and Narbik's BGP sections for a little reinforcement. Well, I won't be studying tomorrow and will instead be traveling to Chicago for work. Hopefully I can get a few labs done next week, and touch back on BGP. We will see how that goes...
To prevent your BGP AS from being used as a transit AS, use the community NO EXPORT which will prevent advertisement to EBGP neighbors.
Use 'mpls ldp discovery transport-address interface ' to set ldp/tdp to use the specified interface as the TCP connect source instead of what you have set as the router-id (most likely loopback0).
The IGMP static-group command causes the devices to process switch the group specified.
The follow are required in an ACL to permit traceroute to complete.
1 permit icmp any any time-exceeded
2 permit icmp any any port-unreachable
In TCP intercept 'watch' mode, incomplete sessions will be terminated with a RST after 30 seconds. You can set the time with ' ip tcp intercept watch-timeout 15'.
If you get a scenario pointing you to a TFTP server on a vlan and NOT a particular host, you need to set the ip helper-address to the broadcast address of that subnet. Also, you need to enable 'ip directed-broadcast' on the VLAN interface.
'frame-relay interface-dlci 555 protocol ip 136.1.5.2' will assign and IP address via BOOTP to the host on dlci 555 when used on a point-to-point interface. With P2M, a frame-relay map will accomplish the same.
When using subinterfaces with rsvp, the 'ip rsvp' commands will need to be applied on the physical interface as well. If there are multiple subinterfaces, the physical rates should be the sum of all subinterfaces. Also - frame-relay requires fair-queue to be enabled. So if you are using FRTS, be aware...
And with that, I've finished lab 3. To be honest, this lab was not kind to me. I've used the blog here to take notes on the things that tripped me up. Other things that I didn't note here are just oversights that will kill me in the real lab. Read twice, and verify twice. That is my motto. My biggest weakness was the BGP section. If I have time, I would like to tackle both INE and Narbik's BGP sections for a little reinforcement. Well, I won't be studying tomorrow and will instead be traveling to Chicago for work. Hopefully I can get a few labs done next week, and touch back on BGP. We will see how that goes...
Thursday, June 10, 2010
INE Workbook Vol 2 Lab 1
When redistributing between protocols, be careful about connected interfaces. If you have redistributed a connected interface using a route-map, and you redistribute between two protocols - anything not specified in that route-map will not be redistributed. Those interfaces will be treated as connected interfaces. Here is a redistribution example.
router eigrp 10
redistribute ospf 1 metric 1 1 1 1 1
network 54.1.1.6 0.0.0.0
no auto-summary
eigrp router-id 150.1.6.6
!
router ospf 1
router-id 150.1.6.6
log-adjacency-changes
redistribute connected subnets route-map Redist
redistribute eigrp 10 subnets tag 10
network 150.1.6.6 0.0.0.0 area 46
network 183.1.46.6 0.0.0.0 area 46
router bgp 100
!
route-map Redist permit 10
match interface FastEthernet0/1
We are redistributing the connected interface f0/1 into OSPF. Now when eigrp is redistributed into OSPF, the eigrp connected interface (54.1.1.6) will not be present in OSPF and those route unreachable. Simple fix is to also redistribute the EIGRP connected interface.
route-map Redist permit 20
match interface Serial0/0
In the lab, if you need to redistribute between protocols and connected interface, you should immediately investigate this!
Sometimes, you may to use the neighbor x next-hop-self command to work around recursive lookup issues. For instance, from AS 100 we want to prefer the route to 150.1.11.0/24 in AS200 through the connection between R5 and SW4. So off we go and we set the metric out from AS200 to AS100. Poof! The route to R5 is preferred from within R1.
Rack1R3#sh ip bgp
BGP table version is 33, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
.....
*>i150.1.11.0/24 183.1.105.10 100 100 0 200 i
* 183.1.123.1 200 0 200 i
Using a metric value of 100 over 200, we prefer 150.1.11.0/24 going through SW4 via 183.1.105.10. Let's see where that takes us.
Rack1R3#sh ip route 183.1.105.10
Routing entry for 183.1.105.0/24
Known via "eigrp 100", distance 90, metric 2689536, type internal
Redistributing via eigrp 100, ospf 1
Advertised by ospf 1 subnets route-map EIGRP->OSPF
Last update from 183.1.123.2 on Serial1/0, 03:12:41 ago
Routing Descriptor Blocks:
* 183.1.123.2, from 183.1.123.2, 03:12:41 ago, via Serial1/0
Route metric is 2689536, traffic share count is 1
Total delay is 40300 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 4
Ugh, no - that's not what we wanted. The route to 150.1.11.0/24 will go out via the Serial1/0 connection based on the next-hop value. So how to get around this? If on AS100 router R5, we set the 'neighbor next-hop-self' command for R3, the next-hop will be the connected interface.
Rack1R3#sh ip bgp
BGP table version is 34, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
......
*>i150.1.11.0/24 183.1.0.5 100 100 0 200 i
* 183.1.123.1 200 0 200 i
Rack1R3#sh ip route 183.1.0.5
Routing entry for 183.1.0.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 100
Advertised by eigrp 100 metric 1000 0 255 1 1500 route-map EIGRP-Connected
Routing Descriptor Blocks:
* directly connected, via Serial1/1
Route metric is 0, traffic share count is 1
I need to learn to not make stupid mistakes. In a MPLS VPN environment, I tried to ping across the MPLS VPN but I didn't see the source interface on my ping command. Forgetting something like that could send me on a 'troubleshooting' spree for something that isn't really a problem...sigh...
I've said it before, I'll say it again - 'no ip mroute-cache' and 'debug ip mpacket' can be a lifesaver when troubleshooting multicast.....
INE presents things like you may see in the lab. I got a requirement to rate-limit ICMP packets. My only restriction was to not use 'match protocol'. So I configured the legacy rate-limit command with an access-list. That should be an acceptable solution. Their solution was the CBWFQ policing method (which I prefer) using an access-list to match ICMP packets. In my eyes, both are viable solutions.
With CBWFQ, you can't use percent and bandwidth commands, but you can use percent with priority commands. Unfortunately INE left out the fact that the voice traffic should be prioritized. They simply said 'allocate 64kbps to VOIP bearer traffic'. Standard practices says to use priority here, but the lab is certainly NOT based on best practices.
And with that, I've completed Lab 1 with a difficulty level of 8. I really didn't think that it was too hard. There was just way too many scenarios where they weren't real specific about what you should do, or left out important details. I guess this is where you would ask the proctor in the real lab and hope that they are more helpful than the last proctor I had. I just made a few simple mistakes that I need to keep track of because they can KILL YOU in the real lab. I need lots more practice doing redistribution, and these full labs should help me. I could also use some more help with EEM - mostly I need to know what all the variables are for an action....
I was almost regretting doing full labs because I thought I would get murdered, but really it was not that bad. I think I am going to fire up troubleshooting and work on that tomorrow and Saturday. I'll be leaving town Sunday for a week, but hopefully I'll be able to get a few full labs completed while I am out of town working....
router eigrp 10
redistribute ospf 1 metric 1 1 1 1 1
network 54.1.1.6 0.0.0.0
no auto-summary
eigrp router-id 150.1.6.6
!
router ospf 1
router-id 150.1.6.6
log-adjacency-changes
redistribute connected subnets route-map Redist
redistribute eigrp 10 subnets tag 10
network 150.1.6.6 0.0.0.0 area 46
network 183.1.46.6 0.0.0.0 area 46
router bgp 100
!
route-map Redist permit 10
match interface FastEthernet0/1
We are redistributing the connected interface f0/1 into OSPF. Now when eigrp is redistributed into OSPF, the eigrp connected interface (54.1.1.6) will not be present in OSPF and those route unreachable. Simple fix is to also redistribute the EIGRP connected interface.
route-map Redist permit 20
match interface Serial0/0
In the lab, if you need to redistribute between protocols and connected interface, you should immediately investigate this!
Sometimes, you may to use the neighbor x next-hop-self command to work around recursive lookup issues. For instance, from AS 100 we want to prefer the route to 150.1.11.0/24 in AS200 through the connection between R5 and SW4. So off we go and we set the metric out from AS200 to AS100. Poof! The route to R5 is preferred from within R1.
Rack1R3#sh ip bgp
BGP table version is 33, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
.....
*>i150.1.11.0/24 183.1.105.10 100 100 0 200 i
* 183.1.123.1 200 0 200 i
Using a metric value of 100 over 200, we prefer 150.1.11.0/24 going through SW4 via 183.1.105.10. Let's see where that takes us.
Rack1R3#sh ip route 183.1.105.10
Routing entry for 183.1.105.0/24
Known via "eigrp 100", distance 90, metric 2689536, type internal
Redistributing via eigrp 100, ospf 1
Advertised by ospf 1 subnets route-map EIGRP->OSPF
Last update from 183.1.123.2 on Serial1/0, 03:12:41 ago
Routing Descriptor Blocks:
* 183.1.123.2, from 183.1.123.2, 03:12:41 ago, via Serial1/0
Route metric is 2689536, traffic share count is 1
Total delay is 40300 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 4
Ugh, no - that's not what we wanted. The route to 150.1.11.0/24 will go out via the Serial1/0 connection based on the next-hop value. So how to get around this? If on AS100 router R5, we set the 'neighbor next-hop-self' command for R3, the next-hop will be the connected interface.
Rack1R3#sh ip bgp
BGP table version is 34, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
......
*>i150.1.11.0/24 183.1.0.5 100 100 0 200 i
* 183.1.123.1 200 0 200 i
Rack1R3#sh ip route 183.1.0.5
Routing entry for 183.1.0.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 100
Advertised by eigrp 100 metric 1000 0 255 1 1500 route-map EIGRP-Connected
Routing Descriptor Blocks:
* directly connected, via Serial1/1
Route metric is 0, traffic share count is 1
I need to learn to not make stupid mistakes. In a MPLS VPN environment, I tried to ping across the MPLS VPN but I didn't see the source interface on my ping command. Forgetting something like that could send me on a 'troubleshooting' spree for something that isn't really a problem...sigh...
I've said it before, I'll say it again - 'no ip mroute-cache' and 'debug ip mpacket' can be a lifesaver when troubleshooting multicast.....
INE presents things like you may see in the lab. I got a requirement to rate-limit ICMP packets. My only restriction was to not use 'match protocol'. So I configured the legacy rate-limit command with an access-list. That should be an acceptable solution. Their solution was the CBWFQ policing method (which I prefer) using an access-list to match ICMP packets. In my eyes, both are viable solutions.
With CBWFQ, you can't use percent and bandwidth commands, but you can use percent with priority commands. Unfortunately INE left out the fact that the voice traffic should be prioritized. They simply said 'allocate 64kbps to VOIP bearer traffic'. Standard practices says to use priority here, but the lab is certainly NOT based on best practices.
And with that, I've completed Lab 1 with a difficulty level of 8. I really didn't think that it was too hard. There was just way too many scenarios where they weren't real specific about what you should do, or left out important details. I guess this is where you would ask the proctor in the real lab and hope that they are more helpful than the last proctor I had. I just made a few simple mistakes that I need to keep track of because they can KILL YOU in the real lab. I need lots more practice doing redistribution, and these full labs should help me. I could also use some more help with EEM - mostly I need to know what all the variables are for an action....
I was almost regretting doing full labs because I thought I would get murdered, but really it was not that bad. I think I am going to fire up troubleshooting and work on that tomorrow and Saturday. I'll be leaving town Sunday for a week, but hopefully I'll be able to get a few full labs completed while I am out of town working....
Tuesday, June 8, 2010
Dynamips with 3725 and NM-16ESW modules
Does no one else have a problem with this setup? I've tried windows. I've tried multiple linux distros. Tried GNS3. I've tried dozens of idle-pc values, several IOS versions, multiple servers, different configurations and I still have issues.
What are the issue? Sometimes layer 2 sometimes layer 3. Sometimes arp entries will be incomplete on one of my four switches to a directly connected neighbor. CDP shows up fine. Almost always, all my layer 3 interfaces on one switch will just fail to work. What gives? The other three switches will be just fine!!
At first, I thought it was load. Ok, I have a few servers laying around. Fired it up, installed ubuntu 10, dynamips and dynagen and fired up only my 4 switch instances. Guess what? Still problems. I tried Windows. Still problems. Tried CentOS. Still problems. It is not just me - I've had several friends who have also had the same issues with NM16-ESW modules with the 3725 images.
So what was my solution? Use the 3640 image. It works EVERY DAMN TIME. Now granted, the feature set is different, and I can't do things like EIGRPv6 and I can't use the now-standard vlan commands in configuration mode like on t he 3725 - but it WORKS. I wasted a whole day trying to get this to work (again) instead of working on a full lab. Sigh. I've searched google to no extent. I've searched the dynamips/dynagen forums, INE's forums and still, I can't find anyone else with this issue.
So if anyone out there has a solution, I would be glad to hear it.
....now back to starting my full labs tomorrow.....
What are the issue? Sometimes layer 2 sometimes layer 3. Sometimes arp entries will be incomplete on one of my four switches to a directly connected neighbor. CDP shows up fine. Almost always, all my layer 3 interfaces on one switch will just fail to work. What gives? The other three switches will be just fine!!
At first, I thought it was load. Ok, I have a few servers laying around. Fired it up, installed ubuntu 10, dynamips and dynagen and fired up only my 4 switch instances. Guess what? Still problems. I tried Windows. Still problems. Tried CentOS. Still problems. It is not just me - I've had several friends who have also had the same issues with NM16-ESW modules with the 3725 images.
So what was my solution? Use the 3640 image. It works EVERY DAMN TIME. Now granted, the feature set is different, and I can't do things like EIGRPv6 and I can't use the now-standard vlan commands in configuration mode like on t he 3725 - but it WORKS. I wasted a whole day trying to get this to work (again) instead of working on a full lab. Sigh. I've searched google to no extent. I've searched the dynamips/dynagen forums, INE's forums and still, I can't find anyone else with this issue.
So if anyone out there has a solution, I would be glad to hear it.
....now back to starting my full labs tomorrow.....
Narbik MPLS
Remember that LDP advertises it's LDP router-id as the transport address in the LDP discovery messages and you must provide reachability for that router-id. There should be an exact match for the LDP-ID in the routing table. Pay close attention as a lot of MPLS troubleshooting scenarios seem to at least touch this topic.
'show mpls ldp discovery detail' can be key to uncovering these scenarios. If you see something like 'no host route to transport address' your router does not have the route to the LDP neighbors transport (or router-id) address. Check your IGP routing table.
BB1(config)#do sh mpls ldp disc det
Local LDP Identifier:
7.7.7.7:0
Discovery Sources:
Interfaces:
FastEthernet0/0 (ldp): xmit/recv
Enabled: Interface config
Hello interval: 5000 ms; Transport IP addr: 7.7.7.7
LDP Id: 6.6.6.6:0
Src IP addr: 10.1.67.6; Transport IP addr: 6.6.6.6
Hold time: 15 sec; Proposed local/peer: 15/15 sec
Reachable via 6.6.6.6/32
'mpls ldp holdtime 90' will set the holdtime to 90 seconds, and the keep alive to 1/3 the hold timer.
When you are filtering label advertisements, you need to first disable label advertisement with 'no mpls ldp advertise-labels'. Otherwise your filtering will have no effect. The RD will make the non-unique customer IPv4 address into a unique 96-bit unique VPNV4 address. RD does not indicate which VRF a prefix belongs to and it is NOT a vpn identifier. The route-target is a bgp extended community saying which communities will be imported or exported with the specified VRF.
I finally get and understand the sham link. I just forget to put the loopback interface in the VRF! No wonder my bgp routes didn't show up!
I am slowly starting to get this SoO stuff. It's very easy to understand, but can be a bear to construct and setup.Simply use route-maps to set and filter the SoO extended communities. Chances are if you have redundant connections, you will need to set/filter SoO.
I really enjoy Narbik's MPLS labs. Something about how the labs are constructed and how he explains it makes total sense.
Now it's off to full labs....joy, joy....
'show mpls ldp discovery detail' can be key to uncovering these scenarios. If you see something like 'no host route to transport address' your router does not have the route to the LDP neighbors transport (or router-id) address. Check your IGP routing table.
BB1(config)#do sh mpls ldp disc det
Local LDP Identifier:
7.7.7.7:0
Discovery Sources:
Interfaces:
FastEthernet0/0 (ldp): xmit/recv
Enabled: Interface config
Hello interval: 5000 ms; Transport IP addr: 7.7.7.7
LDP Id: 6.6.6.6:0
Src IP addr: 10.1.67.6; Transport IP addr: 6.6.6.6
Hold time: 15 sec; Proposed local/peer: 15/15 sec
Reachable via 6.6.6.6/32
'mpls ldp holdtime 90' will set the holdtime to 90 seconds, and the keep alive to 1/3 the hold timer.
When you are filtering label advertisements, you need to first disable label advertisement with 'no mpls ldp advertise-labels'. Otherwise your filtering will have no effect. The RD will make the non-unique customer IPv4 address into a unique 96-bit unique VPNV4 address. RD does not indicate which VRF a prefix belongs to and it is NOT a vpn identifier. The route-target is a bgp extended community saying which communities will be imported or exported with the specified VRF.
I finally get and understand the sham link. I just forget to put the loopback interface in the VRF! No wonder my bgp routes didn't show up!
I am slowly starting to get this SoO stuff. It's very easy to understand, but can be a bear to construct and setup.Simply use route-maps to set and filter the SoO extended communities. Chances are if you have redundant connections, you will need to set/filter SoO.
I really enjoy Narbik's MPLS labs. Something about how the labs are constructed and how he explains it makes total sense.
Now it's off to full labs....joy, joy....
Subscribe to:
Posts (Atom)
