[info]1.1 (Traffic Control)[/info]
[success]When told to enable pruning because SW1 and SW3 do not have VLAN8 locally assigned. Ensure that traffic from this VLAN is not allowed over their lowest numbered trunk link to SW2. Traffic for VLAN8 should be received over any of the other trunk links:[/success]
SW1:
int fa1/7
switchport trunk allowed vlan except 8 <–adds all the vlans to the allowed list except vlan 8. Remove removes the VLAN(s) from the list already created
SW3:
int fa1/10
switchport trunk allowed vlan except 8
[error]The vlan-list format is all | none | add | remove | except vlan-list[,vlan-list...] where:
•all—Specifies all VLANs from 1 to 1005. This keyword is not supported in the switchport trunk pruning vlan command.
•none—Indicates an empty list. This keyword is not supported in the switchport trunk allowed vlan command.
•add—Adds the defined list of VLANs to those currently set, instead of replacing the list.
•remove—Removes the defined list of VLANs from those currently set instead of replacing the list.
•except—Lists the VLANs that should be calculated by inverting the defined list of VLANs.
•vlan-list—Is either a single VLAN number from 1 to 1005 or a continuous range of VLANs described by two VLAN numbers, the lesser one first, separated by a hyphen that represents the VLAN IDs of the allowed VLANs when this port is in trunking mode.[/error]
[info]1.2 (Spanning-Tree Protocol)[/info]
[success]When told to configure SW1 to be the root for VLAN258:[/success]
SW1:
spanning-tree vlan 258 root primary
[success]When told to configure SW3 to be the root for VLAN258 if SW1 becomes unavailable:[/success]
SW3:
spanning-tree vlan 258 root secondary
[success]When told all VLAN258 traffic from SW2 to SW1 should transit SW4 and if SW2′s path to SW1 through SW3 is down, SW2 should use the directly connected trunk links to reach SW1 directly. Use the fewest number of commands to accomplish this and do no alter SW1′s port-priorities (must be cost then):[/success]
SW2:
int range fa1/7 – 9
spanning-tree vlan 258 cost 100 <–Affects how the local switch elects its root port. Lower the cost, the better.
[info]1.4 (Spanning-Tree Protocol)[/info]
[success]When told ensure that the output of the sh spanning-tree vlan 258 command on SW3 matches below:[/success]
SW3#sh spanning-tree vlan 258 br
VLAN0258
Spanning tree enabled protocol ieee
FastEthernet1/15 128.56 128 19 FWD 32768 c209.0c7e.000b 16.56:
SW4:
int fa1/15
spanning-tree vlan 258 port-priority 16
[error]When going away from the root of the tree = port-priority
When going towards the root of the tree = Cost[/error]
[info]1.5 (Rate-Limiting)[/info]
[success]When told to make sure that if unicast traffic exceeds 10Mbps traffic is dropped until it goes below 100Kbps. Configure this on SW1:[/success]
SW1:
int fa1/1
bandwidth 10000
storm-control unicast level 100 1
[error]Rack1SW1(config-if)#storm-control unicast level 100 ?
<0 – 100> Enter Integer part of lower suppression level[/error]
[info]1.6 (QOS)[/info]
[success]When told to configure SW2 with:
-Cos 0 mapped to DSCP 0
-Cos 1 mapped to DSCP 0
-Cos 2 mapped to DSCP 0
-Cos 3 mapped to DSCP 0
-Cos 4 mapped to DSCP 32
-Cos 5 mapped to DSCP 40
-Cos 6 mapped to DSCP 0
-Cos 7 mapped to DSCP 0[/success]
SW2:
mls qos map cos-dscp 0 0 0 0 32 40 0 0
[info]1.7 (QOS)[/info]
[success]When told to configure SW2 to match this output:[/success]
SW2#sh mls qos int fa1/2
Fa1/2
trust state: trust cos
trust mode: trust cos
COS override: dis
default COS: 0
pass-through: none
SW2:
int fa1/2
mls qos trust cos
[info]2 (IPv4)
2.1 (OSPF)[/info]
[success]When told that SW2′s memory is running low and the routing table on the SW is large. To fix it, they want you to setup SW2 so that routers in OSPF area 1 do NOT see any inter-area or external OSPF routes. Ensure that devices in area 1 maintain full reachability to the rest of your network:[/success]
R2:
router ospf 1
area 1 nssa no-summary <–this command is issued on NSSA ABR’s only. No type 3 or 4 summary LSA’s are allowed in Area1 (no inter-area routes allowed in area1). A default router is injected into the NSSA totally stub area as a type 3 summary LSA.
R5:
router ospf 1
area 1 nssa no-summary
SW2:
router ospf 1
area 1 nssa <–this command must be configured on every single router in Area1
[info]2.2 (OSPF)[/info]
[success]When told to configure OSPF area 2 on the ethernet, frame relay, and serial segments between R4 and R5 making sure you advertise loopback0 interface on R4 and R5 into area 2. Your allowed to add one additional IP subnet to accomplish this:[/success]
R2:
int tunnel0 <–a virtual-link cannot be created over a stub area
ip address 141.1.25.2 255.255.255.0
tunnel source fa0/0
tunnel destination 141.1.0.5
!
router ospf 1
network 141.1.25.2 0.0.0.0 area 0
R4:
int s0/0
ip ospf network point-to-point
!
router ospf 1
network 141.1.45.4 0.0.0.0 area 2
network 141.1.54.4 0.0.0.0 area 2
network 141.1.145.4 0.0.0.0 area 2
network 150.1.4.4 0.0.0.0 area 2
R5:
int s0/0
ip ospf network point-to-point
!
int tunnel0 <–a virtual-link cannot be created over a stub area
ip address 141.1.25.5 255.255.255.0
tunnel source fa0/1
tunnel destination 141.1.0.2
!
router ospf 1
network 141.1.25.5 0.0.0.0 area 0
network 141.1.45.5 0.0.0.0 area 2
network 141.1.54.5 0.0.0.0 area 2
network 141.1.145.5 0.0.0.0 area 2
network 150.1.5.5 0.0.0.0 area 2
[success]When told to mutually redistribute between RIP and OSPF on R3:[/success]
R3:
router opsf 1
redistribute rip subnets
!
router rip
redistribute ospf 1 metric 1
[error]Because Area 2 is discontiguous from OSPF area 0, we needed a GRE tunnel. Again virtual links can not be used because of the NSSA we configured in Area 1.[/error]
[info]3 (IPv6)
3.1 (OSPFv3)[/info]
[success]When told to configure IPv6 on the FR link between R1 and R2 using addresses 2001:141:1:12::Y/64. Advertise this link into OSPFv3 area 0:[/success]
R1:
int s0/0.1 point-to-point
ipv6 address 2001:131:1:12::1/64
ipv6 address FE80::1 link-local
ipv6 ospf 1 area 0
R2:
int s0/0
ipv6 address 2001:141:1:12::2/64
ipv6 address FE80::2 link-local
ipv6 ospf network point-to-point
ipv6 ospf 1 area 0
frame-relay map ipv6 FE80::1 201 <–local link must be mapped
frame-relay map ipv6 2001:141:1:12::1 201 broadcast
[success]When told to configure IPv6 on the Ethernet link between R2, R5, and SW2 using addresses 2001:141:1:25::Y/64. Avertise this segment into OSPFv3 area 1:[/success]
R2:
int fa0/0
ipv6 address 2001:141:1:25::2/64
ipv6 ospf 1 area 1
R5:
int fa0/1
ipv6 address 2001:141:1:25::5/64
ipv6 ospf 1 area 1
SW2:
int vlan258
ipv6 address 2001:141:1:25::A/64
ipv6 ospf 1 area 1
[info]3.2 (OSPFv3 Summarization)[/info]
[success]When told to create two loopback interfaces on R5 and SW2 with IPv6 addresses 2001:150:1:Y::Y/64 and advertise them into OSPFv3 area 1:[/success]
R5:
int loopback100
ipv6 address 2001:150:1:5::5/64
ipv6 ospf 1 area 1
SW2:
int loopback100
ipv6 address 2001:150:1:8::8/64
ipv6 ospf 1 area 1
[success]When told to configure R2 to advertise a summary including both loopback subnets to R1. This summary should overlap the minimum amount of address space necessary:[success]
R2:
ipv6 router ospf 1
area 1 range 2001:150:1::/60
[error]Convert the eighth octet of 2001:150:1:5::5/64, 5 = 00000101
convert the eighth octet of 2001:150:1:8::8/64, 8 = 00001000
The common bit for both addresses will be 7×8 + 4 =60 that why the we use 2001:150:1::/60.[/error]
[info]4 (MPLS VPN)
4.1 (PE-CE Routing)[/info]
[success]When told to configure RIP on the link between BB1 and BB3 to R6 and R4. Note that BB1 and BB3 are in a VPN named VPN_A and connect to R6 and R4:[/success]
R4:
router rip
address-family ipv4 vrf VPN_A
network 204.12.1.0
R6:
router rip
address-family ipv4 vrf VPN_A
network 54.0.0.0
[success]When told that routes learning from BB1 that have an EVEN third octet should be seen with a metric of 10 on R6. This ACL should only have one line and should be effective for any additional networks learned from BB1 in the future:[/success]
R6:
access-list 1 permit 0.0.0.0 255.255.254.255
[info]4.2 (Tunneling)[/info]
[success]When told to allow MPLS exchange between R4 and R6 using LDP and do not rely on dynamic routing for endpoint IP address discovery. You are allowed to create additional interfaces:[/success]
R4:
int tunnel 46
ip address 141.1.46.4 255.255.255.0
tunnel source loopback0
tunnel destination 150.1.6.6
mpls ip
!
ip route 150.1.66.66 255.255.255.255 tunnel 46
!
int loopback100
ip address 150.1.44.44 255.255.255.255
!
router bgp 400
neigh 150.1.66.66 remote-as 100
neigh 150.1.66.66 update-source loopback100
neigh 150.1.66.66 ebgp-multihop
address-family ipv4 vrf VPN_A
redistribute rip
address-family ipv4
no neigh 150.1.66.66 active
address-family vpnv4 unicast
neigh 150.1.66.66 active
neigh 150.1.66.66 send-community both
R6:
int tunnel 46
ip address 141.1.46.6 255.255.255.0
tunnel source loopback0
tunnel destination 150.1.4.4
mpls ip
!
ip route 150.1.44.44 255.255.255.255 tunnel 46
!
interface loopback100
ip address 150.1.66.66 255.255.255.255
!
router bgp 100
neigh 150.1.44.44 remote-as 400
neigh 150.1.44.44 update-source loopback100
neigh 150.1.44.44 ebgp-multihop
address-family ipv4 vrf VPN_A
redistribute rip
address-family ipv4
no neigh 150.1.44.44 active
address-family vpnv4 unicast
neigh 150.1.44.44 activate
neigh 150.1.44.44 send-community both
[error]What is the difference between address-family ipv4 and vpnv4? The answer is so simple, we always accept and forward ip packets to customers, for this we need to use ipv4 address-family. When the customers packets are being received by PE they become labeled one and to forward labeled packets to different PE/RR; address-family vpnv4 is required. In short we can say that ipv4 address-family is being used for customers and vpnv4 address-family is used by SP core.[/error]
[success]When told RIPv2 prefixes are to be exchanged accross the VPN with their metric preserved:[/success]
R4:
router rip
address-family ipv4 vrf VPN_A
redistribute bgp 400 metric transparent
R6:
router rip
address-family ipv4 vrf VPN_A
redistribute bgp 100 metric transparent
[error]The command router rip enables RIP on the PE router. RIP version 2 is then configured using the command version 2. Next comes the address-family ipv4 vrf vrf_name command. RIP configuration for the VRF is configured under the IPv4 address family. By specifying version 2 globally (directly under router rip), it is inherited by all the address families configured under RIP.Under the address family, be sure to specify redistribution from MP-BGP or BGP into RIP. Alternatively, you can originate a default route into RIP if it is a large network. Remember that customer routes are advertised between PE routers using MP-BGP. These routes are then imported into the customer VRFs. The command redistribute bgp autonomous_system metric transparent can then be used to redistribute these routes into RIP for advertisement to the attached customer site or sites.
Note the use of metric transparent. RIP metrics are preserved when they are advertised in MP-BGP (they are copied into the MED attribute), which ensures that these metrics are redistributed back into RIP unmodified.Make sure that a metric, whether a specific metric or the keyword transparent, is configured when redistributing MP-BGP routes into RIP. If one is not specified, the routes may not be redistributed.[/error]
–Another Explanation–
[error]Redistribute MP-iBGP VPNv4 prefixes into RIP:
Redistribute the MP-iBGP VPNv4 prefixes from remote R4 into RIP per VRF routing context on R6 router. In RIP PE-CE routing, the RIP metric is copied into the BGP multi-exit discriminator (MED) attribute. This metric can be preserved across the CE network by configuring the metric transparent option during redistribution from BGP into RIPv2, and, by doing so, it is copied back from the BGP MED attribute into the RIP version 2 metric.[/error]
[info]4.3 (BGP)[/info]
[success]When told to enable BGP as the PE/CE protocol between R6 – R4, and BB1 – BB3. BB3 expects R4 to be in AS100 and make sure to configure the PE routers so that the respective CE’s will not reject the advertised BGP prefixes due to AS_PATH loops:[/success]
R4:
router bpg 400
address-family ipv4 vrf VPN_A
neigh 204.12.1.254 remote-as 54
neigh 204.12.1.254 as-override <–needed to override the last AS with local AS
neigh 204.12.1.254 local-as 100 no-prepend <–”no-prepend” needed to make R6 learn prefixes from AS54
R6:
router bpg 100
address-family ipv4 vrf VPN_A
neigh 54.1.1.254 remote-as 54
neigh 54.1.1.254 as-override
[error]Enabling the AS override feature allows routes originating from an AS to be accepted by a router residing in the same AS. Without AS override enabled, the router refuses the route advertisement once the AS path shows that the route originated from its own AS. This is done by default to prevent route loops. The as-override statement overrides this default behavior. no-prepend option “configures the router to not prepend the local autonomous system number to routes that are received from external peers. “[/error]
[info]5 (IP Multicast)
5.1 (Auto-RP)[/info]
[success]When told to configure R2 to announce its loopback0 interface as a candidate RP via auto-rp for the multcast groups 225.0.0.0 through 225.255.255.255:[/success]
R2:
ip pim send-rp-announce loopback0 scope 16 group-list 10
!
access-list 10 permit 225.0.0.0 0.255.255.255.255
[success]When told to configure R5 to announce its loopback0 interface as a candidate RP via auto-rp for the multcast groups 239.0.0.0 through 239.255.255.255:[/success]
R5:
ip pim send-rp-announce loopback0 scope 16 group-list 10
!
access-list 10 permit 239.0.0.0 0.255.255.255.255
[success]When told SW2 should be responsible for the group to RP mappings:[/success]
SW2:
ip pim send-rp-discovery loopback0 scope 16
[info]5.2 (Multicast Testing)[/info]
[success]When told to configure R3′s interface fa0/0 as a member of the multicast group 225.25.25.25 and int fa0/1 as a member of 239.39.39.39:[/success]
R3:
int fa0/0
ip igmp join-group 225.25.25.25
!
int fa0/1
ip igmp join-group 239.39.39.39
[success]When told to make sure that R3 responds to pings sent to these multicast groups from VLANs 12 and 45:[/success]
R2:
int s0/0
ip pim nbma-mode <–solves the problem where R2 will not forward multicast packets received on its interface s0/0 causing multicast pings from R1 to not reach R3
!
int tunnel0
ip pim sparse-mode
R5:
int tunnel0
ip pim sparse-mode
[info]5.3 (Multicast Rate Limiting)[/info]
[success]When told that engineers in you NOC report that execessive amount of multicast traffic is being received on R3s interface E0/0. It appears that a new app on VLAN7 is the problem. Conigure SW1 so that no more than 1Mbps of multicast traffic is sent out towards R3:[/success]
SW1:
int fa1/3
ip multicast rate-limit out 1000
[info]6 (Security)
6.1 (Traffic Filtering)[/info]
[success]When told to configure a filtering policy on R6′s connection to VLAN6 with these requirements:
-Permit ICMP packets accross thefirewall (either direction)
-Permit telnet to servers in VLAN7 and VLAN77
-Permit HTTP and SSl access to a web server at 141.1.88.100
-Permit any TCP and UDP sessions ititiated from behind R6 to return
-Limit the aggregate rate of DNS and ICMP packets inbound to 128Kbps
Use ZBF syntax:[/success]
R6:
ip access-list ext ACL_OUTSIDE_TO_INSIDE_TELNET
permit tcp any 141.1.7.0 0.0.0.255
permit tcp any 141.1.77.0 0.0.0.255
!
class-map type inspect CMAP_OUTSIDE_TO_INSIDE_HTTP
match access-group name ACL_OUTSIDE_TO_INSIDE_TELNET
match protocol telnet
!
ip access-list ext ACL_OUTSIDE_TO_INSIDE_HTTP
permit tcp any host 141.1.88.100
!
class-map type inspect match-any CMAP_HTTP_HTTPS
match protocol http
match protocol https
!
class-map type inspect CMAP_OUTSIDE_TO_INSIDE_HTTP
match access-group name ACL_OUTSIDE_TO_INSIDE_HTTP
match class-map CMAP_HTTP_HTTPS
!
class-map type inspect match-any CMAP_OTHER_PROTOCOLS
match protocol dns
match protocol icmp
policy-map type inspect PMAP_OUTSIDE_TO_INSIDE
class CMAP_OUTSIDE_TO_INSIDE_TELNET
inspect
class CMAP_OUTSIDE_TO_INSIDE_HTTP
inspect
!
class CMAP_OTHER_PROTOCOLS <–rate limit DNS and ICMP
inspect
police rate 128000 burst 8000
!
class-map type inspect match-any CMAP_INSIDE_TO_OUTSIDE
match protocol udp
match protocol tcp
match protocol icmp
police-map type inspect PMAP_INSIDE_TO_OUTSIDE
class CMAP_INSIDE_TO_OUTSIDE
inspect
!
zone-pair security ZP_INSIDE_TO_OUTSIDE source INSIDE destination
OUTSIDE
service-policy type inspect PMAP_INSIDE_TO_OUTSIDE
!
int fa0/1
zone-member security OUTSIDE
!
int fa0/0
zone-member security INSIDE
[info]6.2 (Spoof Protection)[/info]
[success]When told to configure R4′s VLAN43 interface to protect against spoofed IP packets and do NOT use any ACLs to accomplish this:[/success]
R4:
ip cef
!
int fa0/1
ip verify unicast source reachable-via any <–the router examines all packets that are received on that interface. The router checks to make sure that the source address appears in the FIB. If the rx keyword is selected, the source address must match the interface on which the packet was received. If the any keyword is selected, the source address must be present only in the FIB. This ability to “look backwards” is available only when Cisco Express Forwarding (CEF) is enabled on the router because the lookup relies on the presence of the FIB. CEF generates the FIB as part of its operation.
[info]6.3 (Infrastructure Security)[/info]
[success]When told protect from flooding attacks by configureing R6 so that it will limit the average rate of packets going to the routers CPU to 10000 per second. Make sure this config does not affect BPG peering sessions and router management via SSH and telnet:[/success]
R6:
ip access-list ext ALLOWED_TRAFFIC
permit tcp any any eq bgp
permit tcp any eq bgp any
permit tcp any any eq telnet
permit tcp any any eq 22
!
class-map match-all ALLOWED_TRAFFIC
match access-group name ALLOWED_TRAFFIC
!
policy-map CONTROL_PLANE_POLICING
class ALLOWED_TRAFFIC
class class-default
police rate 1000 pps
!
control-plane
service-policy input CONTROL_PLANE_POLICING
[info]7 (Network Services)
7.1 (SNMP)[/info]
[success]When told to configure R3 and R6 to be managed via SNMP and the SNMP servers are 141.1.7.100 and 141.1.77.100. Both expect RO and RW community strings CISCORO and CISCORW:[/success]
R3 and R6:
snmp-server community CISCORO RO 2
snmp-server community CISCORW RW 2
!
access-list 2 permit 141.1.77.100
access-list 2 permit 141.1.7.100
[success]R3 and R6 should generate SNMP traps for changes relating to HSRP status and should only be sent to 77.100. 7.100 should be SNMPv1 and 77.100 should be SNMPv2c:[/success]
R3 and R6:
snmp-server enable traps hsrp
snmp-server host 141.1.7.100 CISCO tty
snmp-server host 131.1.77.100 version 2c CISCO hsrp
[info]7.2 (IOS Menu)[/info]
[success]When told that first level of support need to have access to R2 to ping and traceroute to R5 and R6′s loopback0 interfaces. Create menu to accomplish this. The menu should be activated whenever the user NOC logs in using the password CISCo. They should not have access to the CLI and should be able to exit the menu:[/success]
R2:
username NOC password 0 CISCO
username NOC autocommand menu NOC
!
menu NOC title # Menu for NOC Users #
menu NOC prompt # Choose your selection: #
menu NOC text 1. Ping R5
menu NOC command 1. ping 150.1.5.5
menu NOC options 1. pause
menu NOC text 2. Ping R6
menu NOC command 2. ping 150.1.6.6
menu NOC options 2. pause
menu NOC text 3. Traceroute to R5
menu NOC command 3. trace 150.1.5.5
menu NOC options 3. pause
menu NOC text 4. Traceroute to R6
menu NOC command 4. trace 150.1.6.6
menu NOC options 4. pause
menu NOC text 5. Exit
menu NOC command 5. exit
menu NOC clear-screen
!
line vty 0 15
login local
[info]7.3 (DNS)[/info]
[success]When told to fix a DNS entry that resolves to the wrong ip 141.1.0.22 without applying this IP Address to any interface. Also do not use NAT:[/success]
R2:
ip alias 141.1.0.22 23
[info]7.4 (Gateway Redundancy)[/info]
[success]When told to that hosts on VLAN36 suffered long hours of downtime due to a hardware failure on R6. This didn’t get resolved until the DHCP servers were updated to assign R3 as the default gateway for this segment. To prevent the problem the admins configured half the host on VLAN36 to default to R3 and the other half to default to R6. You need to configure the network so that in the event either R3 or R6 becomes unavailable, host on this segment should still have access to the rest of the routing domain:[/success]
R3:
int fa0/1
standby 1 ip 141.1.36.1
standby 1 priority 200
standby 1 preempt
standby 2 ip 141.1.36.2
R6:
int fa0/0
standby 1 ip 141.1.36.1
standby 2 ip 141.1.36.2
standby 2 priority 200
standby 2 preempt
[info]7.5 (Failure Message)[/info]
[success]When told to configure R3 to display a “Host Failed” message fo “Connection Unsuccessful” when a telnet session to R4′s loopback0 interface fails:[/success]
R3:
ip host R4 150.1.4.4
!
busy-message R4 “Connection Unsuccessful”
[info]8 (QOS)
8.1 (Congestion Avoidance)[/info]
[success]When told to configure R1 to start dropping packets with an IP precedence of routine on R1′s ethernet link when there are at least 15 packets in output queue:[/success]
R1:
int fa0/0
random-detect
random-detect precedence 0 15 40 10
[info]8.2 (Congestion Management)[/info]
[success]When told to configure R5 so that all SMTP packets are guaranteed at least 1.5Mbps of the output queue on VLAN258 interface. DO not use an ACL:[/success]
R5:
class-map match-all SMTP
match protocol smtp
!
policy-map QOS
class SMTP
bandwidth 1500
!
int fa0/1
service-policy output QOS
[info]8.3 (Rate Limiting)[/info]
[success]When told to configure R5 so that packets over 1250 bytes are limited to 2.5Mbps outbound on its connection to BB3:[/success]
R5:
class-map match-all ABOVE_1250_BYTES
match packet length min 1251
!
policy-map QOS
class ABOVE_1250_BYTES
police cir 2500000
[info]8.4 (Link Efficiency)[/info]
[success]When told to configure R4 and R5 to maximize efficiency on the PPP link by guessing character streams in frames send over the link:[/success]
R4 and R5:
int s0/1
compress predictor <–predictor will try to predict the next sequence of characters in the data stream.