Labbed up the SP Vol2 Lab1 on IE Rack Rental today!
Guys, spent the day labbing up the Lab1 with the IE Rack Rentals through Graded Labs – this was the 1st of 8 sessions I have booked over the coming weeks. Access wise no issues whatsover – all worked flawlessly – created several tabs in SecureCRT for the various devices and got stuck in – a little annoying having to setup the initial configs given that the blocks are only 5 1/2 hours long. This took 13 minutes.
A couple of things caught me out – the rack rentals and the SP Labs don’t match exactly – Serial 0 not Serial 1 on R4, ATM0 not ATM3 on R9, etc. I will publish my SP Lab Plan shortly but to give you some of my timings.
- Switching – 15 minutes – 6 points
- Frame Relay – 32 minutes – 9 points
- OSPF – 33 minutes – 8 points
- BGP – 42 minutes – 12 points
- MPLS – 21 minutes – 9 points [I skipped the last TE Section and moved on missing 3 points]
- VPN – 63 minutes – 9 points [Skipped the last 3 sections missing 9 points]
- Multicast – 20 minutes – 3 points. [Only got the first section done]
So, lessons learned? Well, got my full IGP/EGP completed – tested with TCL script looked good – all outputs showed the routes I needed so that’s positive – Extrapolating based on this then assuming [A huge assumption!] that what I configured was correct then I would just about get 80 given the full 8 hours.
What caught me out? – I made a mistake configuring loopbacks requiring re-visits in OSPF [and reloads!], RIP caught me out, I was not getting RIP Updates and debug ip rip yielded authentication failures. Turns out the rack rental email states to use cisco for passwords but the Vol2 lab says use CISCO, I used lower case but the BB’s were upper case, took a few minutes of time. TCL Script took some time, getting the IP’s together from the outputs of sh ip int brief etc took time to assemble and also time to run on each router [perhaps up to 15 minutes!].On a positive note I did 3 CCO lookups and got my anserws within 2 minutes each – I also got caught cold on the VPN section when I had configured the VRF’s correctly but nothing being seen - Turns out the Ethernet Interface on one of the routers was administratively shut down.
Other notes, having to get up and stretch/toilet breaks/tea take time away from you – stamina, sleep beforehand, hunger, concentration and noise levels are all things we need to focus in on, some we need to maximise, some we need to minimise! It’s also so easy to get caught up on an issue and lose time – look at my VPN time – 1 hour for 9 points, in MPLS it took me 21 minutes to get 9 points!!!!
My final point is “point and task tracking” – you must have a plan for this – you must ensure that all tasks are accounted for – I have scanned in and attached my 1st rough sheet for the lab today – on the left I have the section breakdown, the timings and on the right the list of routers to be configured for that section.
Steve's SP Lab1 Rough Work
SP Countdown Continues…
Exactly 2 Months – 9 Weekends & 62 Days to go! My CCIE SP Lab Plan\Checklist will be published this weekend – I would appreciate feedback on it’s contents, stay tuned!
IEWB-SP Vol2 Lab1 System Mgt & IP Services
System Management:
Q. Logging:- Configure logging messages to be generated on two routers when their MPLS-TE tunnels are established or torn down. These messages should be sent to a syslog server with add 131.x.26.100.
Solution:- Configure mpls traffic-eng logging lsp setups & mpls traffic-eng logging lsp teardowns in global configuration mode along with logging 131.x.26.100 on both routers. Remember that standard system logging is enabled by default. If logging is disabled on your system (using the no logging on command), you must enter the logging on command to reenable logging before you can use the commands [Might be worth noting as part of troubleshooting!] The MPLS commands above are available in both configuration guide and command reference formats but the logging command is only available in command reference format on CCO.
Q. NTP – Network Time Protocol – Configure a router as time source for network with stratum = 3, all other devices in AS100 get time from this router. The NTP messages should be authenticated with MD5 hash of password CISCO
Solution:- Again, NTP can be found in Network Mgt Cmd Ref – for the source time server use ntp master 3 -> remember what a stratum is? – well a stratum one server is an NTP Server that is directly connected to radio receivers or atomic clocks; a stratum two server gets its time from a stratum one and so on => the greater the stratum the less accurate the source. Stratum range on Cisco IOS is 1-15. Default value for master stratum is 8. For authentication use the ntp authentication-key 1 md5 CISCO on the master and combine that command with ntp authenticate, ntp trusted-key 1 and ntp server 131.1.3.3 key 1 on the client routers where 131.1.3.3 is the master NTP router. Verification includes sh ntp stat and sh ntp assoc det.
- Systems Management = 6 Points.
IP Services:
Q. Service Provider Transparency – Configure the network such that if MPLS VPN users send traceroute packets they do not see intermediary next-hop values.
Solution:- Okay, the key here is traceroute so we focus on TTL and also specifying users, not other SP routers makes us think about forwarding. By default, the mpls ip propagate-ttl command is enabled and the IP TTL value is copied to the MPLS TTL field during label imposition. To disable TTL propagation for all packets, use the no mpls ip propagate-ttl command. To disable TTL propagation for only forwarded packets, use the no mpls ip propagate forwarded command. Disabling TTL propagation of forwarded packets allows the structure of the MPLS network to be hidden from customers, but not the provider. Therefore Router(config)# no mpls ip propagate-ttl forwarded is required. But we have to decide on which routers – the ones that our MPLS VPN users can see -> where is MPLS configured, which routers touch the backbone, which routers are isolated? Once these questions are answered then it’s obvious which 6 [in this case] the above command is required on in global configuration mode.
- IP Services = 3 Points.
IEWB-SP Vol2 Lab1 Security
I have skipped QoS and moved onto Security – a tactic I will more than likely employ in the Lab.
Q. DoS Prevention:- One of the routers is being used as a reflector for IBMP Smurf and UDP Fraggle attacks. Configure two of the routers to filter out the attack received from the relevant AS and configure this ACL in less than three lines.
Solution:- Okay I missed this section of my blueprint notes so here goes ->
ICMP is used by the IP layer to send one-way informational messages to a host. There is no authentication in ICMP, which leads to attacks using ICMP that can result in a denial of service, or allowing the attacker to intercept packets. There are a few types of attacks that are associated with ICMP shown as follows:
ICMP DOS Attack : Attacker could use either the ICMP “Time exceeded” or “Destination unreachable” messages. Both of these ICMP messages can cause a host to immediately drop a connection. An attacker can make use of this by simply forging one of these ICMP messages, and sending it to one or both of the communicating hosts. Their connection will then be broken. The ICMP “Redirect” message is commonly used by gateways when a host has mistakenly assumed the destination is not on the local network. If an attacker forges an ICMP “Redirect” message, it can cause another host to send packets for certain connections through the attacker’s host.
ICMP packet magnification (or ICMP Smurf): An attacker sends forged ICMP echo packets to vulnerable networks’ broadcast addresses. All the systems on those networks send ICMP echo replies to the victim, consuming the target system’s available bandwidth and creating a denial of service (DoS) to legitimate traffic.
Ping of death: An attacker sends an ICMP echo request packet that’s larger than the maximum IP packet size. Since the received ICMP echo request packet is larger than the normal IP packet size, it’s fragmented. The target can’t reassemble the packets, so the OS crashes or reboots.
ICMP PING flood attack: A broadcast storm of pings overwhelms the target system so it can’t respond to legitimate traffic.
ICMP nuke attack: Nukes send a packet of information that the target OS can’t handle, which causes the system to crash.
ICMP Attacks Mitigation:
Most ICMP attacks can be effectively reduced by deploying Firewalls at critical locations of a network to filter un-wanted traffic and from iffy destinations. In addition, to keep a reasonable balance between services and security, you should configure your ICMP parameters in your network devices as follows:
- Allow ping ICMP Echo-Request outbound and Echo-Reply messages inbound.
- Allow traceroute TTL-Exceeded and Port-Unreachable messages inbound.
- Allow path MTU ICMP Fragmentation-DF-Set messages inbound.
- Blocking other types of ICMP traffic
A fraggle attack is a type of denial-of-service attack where an attacker sends a large amount of UDP echo traffic to IP broadcast addresses, all of it having a fake source address. This is a simple rewrite of the smurf attack code.
Specifically referencing this question, the destination of the attack will be the broadcast address of the reflector therefore we will need to deny ICMP Echo for the Smurf and UDP Echo for the Fraggle attacks. However as the question states NG than 2 lines then we cannot be specific to deny icmp echo or UDP echo so our config will look like this ->
interface Fa0/0
ip access-group NO_DOS in
!
ip access-list extended NO_DOS
deny ip any host 191.x.x.x <- This is the broadcast address
permit ip any
Corresponding config on the 2nd router.
Q. Spoof Prevention:- There’s concern regarding TCP SYN attacks, configure the above two routers to drop any traffic from a designated AS where the traffic doesn’t have a route pointing out the incoming interface of the receiving traffic.
Solution:- The Unicast RPF feature helps to mitigate problems that are caused by the introduction of malformed or forged (spoofed) IP source addresses into a network by discarding IP packets that lack a verifiable IP source address. For Internet service providers (ISPs) that provide public access, Unicast RPF deflects such attacks by forwarding only packets that have source addresses that are valid and consistent with the IP routing table.
When Unicast RPF is enabled on an interface, the router examines all packets received as input on that interface to make sure that the source address and source interface appear in the routing table and match the interface on which the packet was received. This “look backwards” ability is available only when Cisco express forwarding (CEF) is enabled on the router, because the lookup relies on the presence of the Forwarding Information Base (FIB). CEF generates the FIB as part of its operation. Unicast RPF is an input function and is applied only on the input interface of a router at the upstream end of a connection.
When a packet is received at the interface where Unicast RPF and ACLs have been configured, the following actions occur:
Step 1 Input ACLs configured on the inbound interface are checked.
Step 2 Unicast RPF checks to see if the packet has arrived on the best return path to the source, which it does by doing a reverse lookup in the FIB table.
Step 3 CEF table (FIB) lookup is carried out for packet forwarding.
Step 4 Output ACLs are checked on the outbound interface.
Step 5 The packet is forwarded.
Specifically referencing this question -> the two routers simply require the ip verifiy unicast reverse-path statement under the appropriate interface to drop that traffic fulfilling the question criteria.
References:
http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a00800f67d5.shtml
Update & IEWB-SP Lab 1 IP Multicast
With 72 days to go I am studying in a slightly bizarre way but it suits my working/personal life so go figure. I am currently working 3 different lab scenarios and what I call my master lab document simultaneously. I have IEWB-SP labbed up on my home PC and from here I am posting this blog as I progress through the labs.
I have my own master lab document which is basically a word document split down the middle [Inserted table with two columns] and I document from every lab scenario I get through, the question on the left and the solutions on the right. Basically this gives me two things [1] the various ways of wording a question thus helping with interpretation in the lab and [2] the various ways to configure the same solution from different vendors.
I am also carrying around [as they are light] and studying, the NLI SP Labs simply by reading as I do not have time to lab them up but they help fill on the gaps of knowledge, take a look at their publicly available sample to see what I mean -> http://www.ccbootcamp.com/download/NLI_CCIE_SP_Lab-sample.pdf
Finally I have labbed up on my laptop, customised labs [entitled SB3 on my whiteboard] which are basically concept labs taken from CCO, Cisco Press, Soares, IEWB-SP Vol1, etc.
IEWB-SP Vol2 Lab1 Multicast:
Q. PIM:- Enable PIM on a number of interfaces to enable two routers to transport IPv4 multicast traffic, configure PIMv2 on a router so that is disseminates RP to group mappings & accepts all PIM related register messages for the multicast network.
Solution: In a nutshell, referencing the diagrams, the solution should present itself -> trace the route the packets will take getting from the source to the destination, note the interfaces listed in the table provided, identify the RP [Rendezvous Point], PIMv2 tells us BSR [Bootstrap Router]. Cross reference with CCO -> http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_basic_cfg_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1054362
Enable ip-multicast-routing on the relevant routers, enable ip pim sparse-mode on the interfaces listed, enable the BSR & RP via the ip pim bsr-candidate and ip pim rp-candidate commands on the router in the question. A multicast route [via ip mroute] is required to allow for RPF failure on a given route. Verification via sh ip pim nei command, noting the neighbour address and interfaces, also sh ip pim rp mapping and looking for the statements “This system is a candidate RP” and “this system is a Bootstrap Router”.
Q. Multicast over MPLS VPN’s:- Configure PIM sparse mode for a given VRF on two routers, one of which will be the RP, all multicast traffic between two routers should use admin scoped multicast address 239.100.0.1.
Solution:- First part completed with the ip pim sparse-mode command at the interface levels for the two routers and the ip multicast-routing VRF <name> command on both. Specify the RP for the VRF with the ip pim vrf <name> rp-address <ip address of interface facing the client> command. Finally we need to use MDT [Multicast Distribution Tree] to allow the multicast traffic between the two routers using the address given ->
ip vrf <name>
mdt default 239.100.0.1
This creates a tunnel across the network for the multicast traffic.
A nice treatment of MDT is available here ->
http://www.ciscopress.com/articles/article.asp?p=32100&seqNum=4
Verification, use sh ip pim mdt and sh ip mroute 239.100.0.1
Q. Multicast Testing:- When one router sends ICMP to a given 224.x.x.x address the other router sends corresponding echo-reply 192.x.x.x.
Solution:- Use the ip igmp join-group command with the specified 224.x.x.x address under the interface configured with the 192.x.x.x address thus allowing the router to accept multicast packets and respond, verification by way of ping and sh ip mroute commands .
Final Note: Internetworkexpert have a free v-seminar on Multicast here -> http://www.internetworkexpert.com/free_ccie_vseminar.htm
75 Days to go Update & New SP Links
As the title suggests, 75 days to Lab Day and labbing at the moment. I have come across some neat links which I think any aspiring SP Candicadte will appreciate. Some of these you might know but I get great value from them.
http://pwp.netcabo.pt/amsoares/ -> Antonio’s Soares has put some kick ass SP Scenarios together.
http://wiki.nil.com/Main_Page -> NIL’s Wiki pages authored by Ivan Pepelnjak & co, support discussion of SP topics, Ivan of course wrote the IEMentor SP Workbook and is a CCIE*5 -> Here is an example of his articles -> http://wiki.nil.com/PE-to-PE_troubleshooting_in_MPLS_VPN_networks - Superb.
http://www.nanog.org/presentations/archive/index.php -> NANOG’s Archives – Need I say more – a great free resource.
https://cisco.hosted.jivesoftware.com/community/certifications/ccie_service_provider/lab_exam?view=documents -> Some great SP Lab related documents from Cisco themselves.
http://supportwiki.cisco.com/ -> Cisco Users Support Wiki – Great for troubleshooting.
http://packetlife.net/cheatsheets/ -> Their cheat sheets are full of crammed info.
http://www.groupstudy.com/archives/ccielab/ -> Say no more – as close as it can get to having people in your sitting room discussing all things CCIE related.
http://www.cisco.com/web/psa/products/index.html -> Your best friend in the Lab!
http://www.routerie.com/cgi-bin/ultimatebb.cgi?category=14 -> NLI’s CCIE SP Support Forum – I have a copy of their SP workbook and it’s pretty good!
http://ieoc.com/forums/73.aspx - > Internetworkexpert CCIE SP General Forum
http://ieoc.com/forums/74.aspx -> Internetworkexpert CCIE SP Technical Forum
Finally I though you might like to see the Master Whiteboard which has changed since I first copied on one of my earliest posts. Also I have attached the Command Centre from where all this output comes from.
Steve's Command Centre
IEWB-SP Vol2 Lab1 Analysis – MPLS & VPN Sections
Guys, flat out in work with various production issues that are robbing me of study and blogging time which is annoying but at least this weeks issues were OSPF/BGP/Route Filtering related so I suppose a form of education!
MPLS: [Before starting, what needs to be running? - CEF!]
Q: Frame Mode Label Distribution:- Configure MPLS on a number of routers on two frame relay segments and an ethernet segment – use a standards based label distribution method.
Solution: A standards based label distribution method indicates the use of LDP or Label Distribution Protocol, the IETF standard. So enabing MPLS requires the “mpls label protocol ldp” on the routers in question followed by the “mpls ip” command on the relevant interfaces. Note that if you issue a sh run you may see tag switching shown which is the equivalent to the mpls ip command. Also keep an eye on IOS versions in this section as some default to tdp! Once complete, verification is via the sh mpls int, sh mpls ldp disc, and the sh mpls ldp nei commands. For the ldp neighbor command you are looking for the peer ldps specifying the loopback addresses for the peers. Running the sh mpls forwarding table command shows the local tag, outgong tag, prefix or tunnel id, outgoing interfaces, next hop, etc. If you see “Pop tag” in the outgoing tag field this means that the next hop advertised an implicit null label for the destination thus making the router ‘pop’ the top label. If the same field has a value of “Untagged” this means that there is no label for the destination from the next hop or that label switching is not available on the outgoing interface. Finally ping and traceroute complete the verification.
Q: Cell Mode Label Distribution:- Configure MPLS on the routers connected to the ATM cloud and use a Cisco proprietary label distribution.
Solution: Cell mode is ATM, Cisco Proprietary label distribution indicates TDP or Tag Distribution Protocol. Configuration requires the use of the ‘mpls label protocol tdp’ command coupled with the ‘mpls ip’ command under the ATM interface with the keyword ‘mpls’. What is key to this section is that finally OSPF adjacencies will establish between the routers connecting to the ATM cloud thus completing the OSPF IGP section – another example of a later section having a bearing on an earlier section of the lab. Verification is ping, trace route, sh mpls ldp nei and sh mpls forwarding table. Watch out for any ‘untagged’ outgoing labels.
Q. MPLS Security:- Enable authentication using an MD5 hash between two routers.
Solution: First of all ensure full reachability and adjacencies have been established prior to beginning this section – Why? Because implementing security can break configurations – If you do not check this and an issue arises then there are two questions, was it the implementation of the security or was there an underlying issue beforehand? Implement the security with the mpls ldp nei <ip address> password CISCO command combined with the mpls ldp router-id loopback0. Watch for spaces with the password and if you get this question then it will be the easiest 3 points in history. The Lab is difficult but this is a gimme. PS: Those commands are on the two routers in question.
Q. MPLS Traffic Engineering: [aka the "Fun Stuff"] – Will probably get some speel in the exam with a scenario I guess but sticking with the facts for this – Configure an MPLS TE Tunnel with 10Mbps guaranteed between two routers – Configure the path from one router to another through various network segments – if a link should fail, dynamically re-route the tunnel through another path and assume all FR links are DS3. I am obviously being cryptic with the questions here to ensure the integrity of the two Brian’s material!
Solution: Okay, take the 40000 ft view here, step back from the diagram, draw your own, look at the path, note the IP addressing, visualise the routing path, ‘become the packet’ as Scott Morris would say. Once clear in your mind – Begin, ensure full IGP reachability – check, ok - enable mpls traffic-eng tunnels on relevant routers and also on the interfaces, under the interface issue the bandwidth command with 45000 value to reflect DS3, configure ip rsvp bandwidth on each router in the transit path, under the OSPF routing process enable mpls traffic-eng area 0 which is required to enable OSPF to exchange MPLS TE information, for the defined path, we will create the tunnel interfaces with interface tunnel0, define an ip explicit-path command with relevant next-address commands in the sequence that the route is to take referencing the ip addresses of the interfaces encountered in order! – apply the tunnel destination and tunnel mode mpls traffic-eng commands, then finally add the various parameters for the tunnel mpls traffic-eng commands referencing the ip explicit-path previously defined.
We then repeat this process on the destination router but in reverse order for the interface addresses and we do not forget the keyword dynamic for the 2nd path. Some other notes, we give the tunnel an ip address through the ip unnumbered command beacuse it represents a unidirectional link, we use the autoroute annouce parameter to allow IGP to use the tunnel and the verification? Trace route naturally – if the hops match the requirements in both directions -> Bingo! as Cousin Eddie would say!
MPLS Complete -> 12 Points.
VPN
Q. VRF Configuration:- Configure a VRF on two routers using a particular RD [Route Distinguisher], Routes coming from one router to use route-target 100:xx and routes from a different router to have route target 100:yy.
Solution: Pretty straight forward, copy run start, take note of ip addressing! -> then issue the ip vrf <name> command to enter VRF configuration mode, use the rd 100:1 command to define the RD and create the routing and forwarding table, define your two route-targets with the export and import commands referencing the values in the question above, under the appropriate interface define the VRF with the ip vrf forwarding <name> command, then what? re-apply your ip addressing as this command removes it – hence the save and take note at the start of the solution. You will not forget this as you will be prompted that the ip address has been removed due to VRF enabling! Remember that the import and export commands will be in reverse on the two routers, verification is sh ip vrf detail.
Q. PE-CE Routing:- Configure Ripv2 inside the new VRF to exchange IPv4 prefixes, ensure RIPv2 updates are MD5 authenticated.
Solution: Two parts to this – will need to issue the address-family ipv4 vrf <name> command to place the router in address-family configuration mode, then it’s standard RIPv2 configuration, router rip, version 2, network statement, and configure your key-chain RIP, key 1 and key-string value to all the relevant routers. Again note any spacing with the password and enable ip rip authentication mode/key-chain on relevant interfaces. Verification is sh ip route vrf and debug ip rip if required.
Q.VPNv4 Exchange:- [Nice way of saying Redistribution!] – redistibute between RIPv2 and BGP on the two PE Routers for the VRF and VPNv4 routes to be advertised first to a given router. From what I have read/been told the lab will not say redistribute!
Solution: okay, three routers in question, under the address-family vpnv4 issue the neighbor <ip add> activate command to enable the advertisement of address information in the form of IP prefixes otherwise known as NLRI or Network Layer Reachabaility Information with BGP neighbors. For the redistibution from RIP into BGP, under the RIP routing process and the address-family mode use redistribute bgp 100 metric transparent command. For BGP into RIP, simply redistribute rip under the BGP routing process and again the address-family mode. Verifiaction? sh ip route rip and traceroute.
Q. Internet Access from MPLS VPNs:- If this were a lab, tiredness might be beginning to creep in as we would probably be in the early afternoon stages following lunch! That’s the plan – the schedule, not the tiredness!! – Devices in the VRF need access to the internet already connected to one of the routers, make it so and you are allowed to use one static route – hmmm, using a static route?
Solution: Okay, to get to the router in question, we need to traverse a router that is not in play VPN wise, so we have to add it -> How? Activate the traversing router under the BGP routing process on the route reflector – then on that router, activate the VRF configuration as per previous section with the ip vfr, route-target and address-family commands, define the static route ip route vfr <name> source subnet target global command, then redistribute the static route into BGP. Verification is sh ip route vrf <name>
Q. VRF Aware NAT:- Configure a router such that traffic attached to a different router is translated to the loopback of that router and all other traffic from the VRF translated to the 191.xx.yy.zz address.
Note: NAT can really mess things up so be aware!!!
Solution: Generic Solution – create an ip access-list for the traffic you wish to permit, create a route-map matching on that access-list, issue the ip nat inside command referencing the route map and applying it to the relevant interface with the vrf <name> overload parameter and finally issue the ip nat inside command on the interfaces themsolves. Complete this twice for the two requirements outlined in the question, verification includes pings and sh ip route. Require more detail? Buy the IEWB-SP Vol2 Book & Solutions or look at this Nice Free Example -> http://www.tech-recipes.com/rx/713/cisco_how_to_configure_nat_network_address_translation/
Q. VRF Configuration:- Configure VRF <name> on a VLAN with specified RD, limit connectivity to the VLAN, do not use export-map or import-map, configure a loopback on a router, and configure the network such that this router has full reachabilty in the VRF with the loopback.
Solution: The configuration of the VRF is the same as previous sections with ip vrf <name>, rd 100:xx, and route-targets defined, enable ip vrf forwarding on ethernet interface [watch ip addressing!!] and issue redistribute connected under the BGP Address-family configuration mode. Create the loopback, ip vrf forwarding under that interface, add the new interfaces details to the BGP route reflector as a neighbor and finally configure ip vrf on the router itself and redistribute connected under the BGP address-family configuration mode.
VPN Complete -> 20 Points.
Conclusion – This is the SP Exam so a long section, plenty of typing and easy mistakes can lose points and we have Multicast and QoS to come – oh, and there are maybe only 2-3 hours left in the lab – Crap! Might be worth hitting the Systems Management, IP Services and finally Security before QoS?
