28 Jul

Condensed Notes – Lab2

Posted by Kerry Cordero, CCNP | Internetwork Expert,Lab2
0

1.1 (Link Aggregation)

When told to configure interface fa1/13-15 on SW1 and interface fa1/7-9 on SW4 to be bound to one logical l2 link:

SW1:
int range fa1/13 – 15
sw tr encap dot1q
sw mo tr
channel-group 1 mode on

SW4:
int range fa1/7 – 9
sw tr encap dot1q
sw mo tr
channel-group 1 mode on

When told that SW1 should not activly negotiate this link through any protocol:

SW1:
int range fa1/13 – 15
switchport nonegotiate

1.2 (802.1x Authentication)

When told to put authentication on ports Fa1/2 and Fa1/4 using a Radius server 204.12.1.100 and the key CISCO:

SW1:
aaa new-model
aaa authentication login default none
aaa authentication dot1x default group radius
!
dot1x system-auth-control
!
int fa1/2
switchport mode access
dot1x port-control auto
!
intfa1/4
switchport mode access
dot1x port-control auto
!
radius-server host 204.12.1.100
radius-server key CISCO

When told the source of the packets should come from 150.1.7.7:

SW1:
ip radius source-interface loopback0

2 (IPv4)
2.1 (OSPF)

When told to make sure there is not DR or BDR elections on the segment between R1,R2,R3, and R4. Do not use the “neighbor” statement:

R1, R2, R3, and R4:
int s0/0
ip ospf network point-to-multipoint <–they don’t have DR/BDR elections

When told to authenticate between R1 and SW1 using clear-text password CISCO and you can NOT use “ip ospf authentication” command:

R1:
int fa0/0
ip ospf authentication-key CISCO
!
Router ospf 1
area 17 authentication

SW1:
int fa1/1
ip ospf authentication-key CISCO
!
router ospf 1
area 17 authentication

2.2 (EIGRP)

When told to enable EIGRP on VLAN26 between R2 and R6 and make sure nobody can intercept EIGRP communication:

R2:
router eigrp 10
network 132.1.26.2 0.0.0.0 <–specifires specific interface
neigh 132.1.26.6 fa0/0 <–changes to unicast with this command

R6:
router eigrp 10
network 132.1.26.6 0.0.0.0 <–specifires specific interface
neigh 132.1.26.2 fa0/0.26 <–changes to unicast with this command

When told to configure R6 so that the rest of the EIGRP domain routers only have one router to the prefixes learned from BB1 with the first octet of 200. This router should no unnessarily overlap IP address space:

R6:
int fa0/0.26
ip summary-address eigrp 10 200.0.0.0 255.255.252.0

2.3 (RIP Filtering)

When told to configure SW1 to NOT receive routes with an EVEN second octet from BB3. This ACL should not use more than one line and you can not use “distribute-list” or “distance” keywords:

SW1:
router rip
offset-list EVEN_SECOND_OCTET in 16 vlan783
!
ip access-list standard EVEN_SECOND_OCTET
permit 0.0.0.0 255.254.255.255

2.4 (IGP Redistribution)

When told to redistribute RIP and OSPF on SW1:

SW1:
router ospf 1
redist rip subnets
!
router rip
redis ospf 1 metric 1
distance 109 <–locally helps to prevent re-learning the route and then preferring it via OSPF

When told to redistribute OSPF and EIGRP on R2, R3, and R4:

R2:
router eigrp 10
redistribute ospf 1 metric 1 1 1 1 1
!
router ospf 1
redistribute eigrp 10 subnets metric 20
distance ospf external 171

R3:
router eigrp 10
redistribute ospf 1 metric 1 1 1 1 1
!
router ospf 1
redistribute eigrp 10 subnets metric 30
distance ospf external 171

R4:
router eigrp 10
redistribute ospf 1 metric 1 1 1 1 1
!
router ospf 1
redistribute eigrp 10 subnets metric 10
distance ospf external 171

When told to ensure full reachability:

R2, R3, R4:
ip access-list stan EXTERNAL_VIA_OSPF
permit 132.1.8.0
permit 150.1.7.0
permit 150.1.8.0
permit 204.12.1.0
permit 31.0.0.0 0.255.255.255
permit 30.0.0.0 0.255.255.255
!
route opsf 1
distance 110 0.0.0.0 255.255.255.255 EXTERNAL_VIA_OSPF

2.5 (BGP Peering)

When told to configure BGP peering between R5 and BB2 but you need to authenticate the BGP peering session using the password CISCO:

R5:
router bgp 200
neighbor 192.10.1.254 remote-as 254
neighbor 192.10.1.254 password CISCO

When told to configure BGP peering between SW1 and BB3 but you need to configure AS400 so that BB3 still thinks SW1 is still in AS100:

SW1:
router bgp 400
neighbor 204.12.1.254 remote-as 54
neighbor 204.12.1.254 local-as 100 no-prepend

2.6 (BGP Filtering)

When told AS400 will not provide transit for traffic coming from AS54 and its customers that is destined for AS254. Configure AS400 to reflect this policy:

SW1:
router bgp 400
neigh 204.12.1.254 route-map STOP_TRANSIT_TO_AS254 out
!
ip as-path access-list 1 permit _254$
!
route-map STOP_TRANSIT_TO_AS254 deny 10
match as-path 1
!
route-map STOP_TRANSIT_TO_AS254 permit 20

2.7 (BGP Summarization)

When told that R5 should keep its BGP table as small as possible by advertising only one route representing your entire network 132.1.0.0 to BB2. Do not use “access-list” or “prefix-list” filtering:

R5:
router bgp 200
aggregate-address 132.1.0.0 255.255.0.0 summary-only <–The aggregated address is advertised, along with the more specific routes. The exception to this rule is through the use of the summary-only command. The “summary-only” keyword suppresses the more specific routes and announces only the summarized route.

When told to make sure all other routers within your network should not see the summary route:

R5:
ip prefix-list DENY_AGGREGATE seq 10 permit 132.1.0.0/16
!
route-map DENY_AGGREGATE deny 10
match ip address prefix-list DENY_AGGREGATE
!
Route-map DENY_AGGREGATE permit 20
!
router bgp 200
neighbor 132.1.35.3 route-map DENY_AGGREGATE out
neighbor 132.1.45.4 route-map DENY_AGGREGATE out

2.8 (BGP Tuning)

When told to have R5 respond to IGP events with 15 seconds delay:

R5:
router bgp 200
bgp nexthop trigger delay 15

When told to have R5 batch and send routing updates to BB2 every 3 seconds:

R5:
router bgp 200
neighbor 192.10.1.254 advertisement-interval 3

3 (IPv6)
3.1 (IPv6 Deployment)

When told to configure IPv6 on the FR clould network between R2 and R3 with addresses 2001:CC1E:X::Y/128 under their loopback 0 interfaces:

R2:
ipv6 unicast-routing
!
int loopback0
ipv6 address 2001:CC1E:1::2/128

R3:
ipv6 unicast-routing
!
int loopback0
ipv6 address 2001:CC1E:1::3/128

When told to use 2001:CC1E:X:2323::Y/64 for the FR network:

R2:
int s0/0
ipv6 address 2001:CC1E:1:2323::2/64
frame-relay map ipv6 2001:CC1E:1:2323::3 203 broadcast

R3:
int s1/0
ipv6 address 2001:CC1E:1:2323::3/64
frame-relay map ipv6 2001:CC1E:1:2323::2 302 broadcast

When told a static route is permitted for testing reachability:

R2:
ipv6 route 2001:CC1E:1::3/128 s0/0 2001:CC1E:1:2323::3

R3:
ipv6 route 2001:CC1E:1::2/128 s1/0 2001:CC1E:1:2323::2

4 (MPLS VPN)
4.1 (L2 VPN)

When told to configure a L2 VPN between R4 and R6 to provide transparency between VLAN6 and VLAN4. Use AToM for encapsulation and two static routes with the creation of additional interfaces:

R4:
mpls ldp router-id loopback100 force <–specifies a preferred interface for determining the Label Distribution Protocol (LDP) router ID. If you use the force keyword with the mpls ldp router-id command, the router ID takes effect more quickly.
!
int loopback100
ip address 150.1.44.44 255.255.255.255
!
int tunnel 46
tunnel source loopback0
tunnel destination 150.1.6.6
ip address 132.1.46.4 255.255.255.0
mpls ip
!
ip route 150.1.66.66 255.255.255.255 tunnel46
!
int fa0/0.4
encap dot1q 4 native
xconnect 150.1.66.66 46 encap mpls <–Use the xconnect peer-ip-address vcid encapsulation mpls command to bind an 802.1Q VLAN attachment circuit to an Any Transport over MPLS (AToM)

R6:
mpls ldp router-id loopback100 force
!
int loopback100
ip address 150.1.66.66 255.255.255.255
!
int tunnnel 46
tunnel source loopback0
tunnel destination 150.1.4.4
ip address 132.1.46.6 255.255.255.0
mpls ip
!
ip route 150.1.44.44 255.255.255.255 tunnel46
!
int fa0/0.6
xconnect 150.1.44.44 46 encap mpls

5 (Multicast)
5.1 (Multicast Testing)

When told to use R2′s most reliable interface as the RP for multicast groups:

R1, R2, R3, R6, Sw1:
ip pim rp-address 150.1.2.2

When told to have testing reachability throughout the multicast domain but in order to do that you will have to configure Sw1′s VLAN interface to participate in the multicast group 228.28.28.28. You also need to ensure that SW1 will respong to ICMP echo-requests sent from VLAN26 to the multicast group address:

SW1:
int vlan 783
ip igmp join-group 228.28.28.28 <–the join-group accepts the multicast packets in addition to forwarding them unlike static that will just fastswitch the packets and pings will drop

5.2 (Multicast Traffic Control)

When told R3 is receiving traffic sourced from VLAN6 destined for the multicast group 228.28.28.28 even though it does not have any attached members and R1 is also receiving traffic from R2 for feeds destined for R3. Resolve it:

R2:
int s0/0
ip pim nbma-mode <–allows the router to forward data destined for a particular multicast group to only those neighbors that have joined that particular group

6 (Security)
6.1 (Router Hardening)

When told to have R5 comply to these security recommendations:
-Drop all source routed packets: no ip source-route
-Disable CDP and Proxy arp ont the ethernet segment to BB2:
int fa0/1
no cdp enable
no ip proxy-arp
-Disable BOOTP server: no ip bootp server

When told to have a banner that displays “Access to this device or the attached networks is prohibited with express written permission. Violators will be shot on sight.”:

banner login “Access to this device or the attached networks is prohibited with express written permission. Violators will be shot on sight.”

6.2 (Zone-Based Firewall)

When told to have ALL SNMP requests received from BB1 and BB2 filtered out by R5 and R6 because R2 and R4 are being polled by an unauthorized source:

R5:
ip access-list ext ACL_SNMP
permit udp any any eq SNMP
!
class-map type inspect CMAP_SNMP
match access-group name ACL_SNMP
!
policy-map type inspect PMAP_FROM_OUTSIDE2INSIDE
class type inspect CMAP_SNMP
drop
class class-default
pass
!
policy-map type inspect PMAP_FROM_INSIDE2OUTSIDE
class class-default
pass
!
zone security OUTSIDE
zone security INSIDE
!
zone-pair security ZP_OUTSIDE2INSIDE source OUTSIDE destination INSIDE
service-policy type inspect PMAP_FROM_OUSIDE2INSIDE
!
zone-pair security ZP_INSIDE2OUTSIDE source INSIDE destination OUTSIDE
service-policy type inspect PMAP_FROM_INSIDE2OUTSIDE
!
int fa0/1
zone-member security OUTSIDE
!
int fa0/0
zone-member security INSIDE
!
ints0/0.1
zone-member security INSIDE
!
int s0/1
zone-member security INSIDE

R6:
ip access-list ext ACL_SNMP
permit udp any any eq SNMP
!
class-map type inspect CMAP_SNMP
match access-group name ACL_SNMP
!
policy-map type inspect PMAP_FROM_OUTSIDE2INSIDE
class type inspect CMAP_SNMP
drop
class class-default
pass
!
policy-map type inspect PMAP_FROM_INSIDE2OUTSIDE
class class-default
pass
!
zone security OUTSIDE
zone security INSIDE
!
zone-pair security ZP_OUTSIDE2INSIDE source OUTSIDE destination INSIDE
service-policy type inspect PMAP_FROM_OUSIDE2INSIDE
!
zone-pair security ZP_INSIDE2OUTSIDE source INSIDE destination OUTSIDE
service-policy type inspect PMAP_FROM_INSIDE2OUTSIDE
!
int s0/0
zone-member security OUTSIDE
!
int fa0/0.26
zone-member security INSIDE

6.3 (Traffic Logging)

When told that the source that was polling R2 and R4 is internal and not external. Now you have to generate a log message whenever a device attempt to poll them using Read-Only community string of “public”. Also, these logs should be sent to the syslog server 132.1.33.100:

R2 and R4:
snmp-server community public RO 1
access-list 1 deny any log
logging 132.1.33.100

6.4 (ICMP Filtering)

When told after a smurf attack you want to limit the amount of ICMP traffic that R5 permits inbound on its interface attached to VLAN52 but it’s only allowed if it comes from VLAN52 sourced from R5. Users are still allowed to tracerotue behind R5 and you can not use CBAC or ZBF:

R5:
int fa0/1
ip access-group DENY_SNMP in
ip access-group EVALUATE_ICMP out
!
ip access-list ext DENY_SNMP
permit icmp any any time-exceeded
permit icmp any any port-unreachable
evaluate icmp <–evaluate keyword uses reflexive entries that have been automatically added to the name (ICMP) extended ACL.
deny icmp any any
permit ip any any
!
ip access-list ext EVALUATE_ICMP
permit icmp any any reflect ICMP
permit ip any any

7 (Network Services)
7.1 (RMON)

When told to have R5 and R6 generate SNMP traps based on:
-whenever the average 5 minute CPU utilization (lsystem.58.0) reaches 75%:
-sampling interval once per minute
-when 75% threshold is reached, the event should read “Five Minute CPU Average Above 75%”
-when the utilization falls back below 40%, the event should read “Five Minute CPU Average Below 40%”
-the SNMP server to send to is 132.1.33.100
-the SNMP community string should be IETRAP

R5 and R6:
rmon event 1 trap IETRAP description “Five Minute CPU Average Above 75%”
rmon event 2 trap IETRAP description “Five Minute CPU Average Below 40%”
rmon alarm 1 lsystem.58.0 60 absolute rising-threshold 75 1 falling-threshold 40
!
snmp-server host 132.1.33.100 IETRAP

7.2 (Remote Access)

When told to have R4 be configure for your NOC with these requirements:
-users will expect the username NOC and password CISCO
-all telnet sessions should be disconnected after 5 minutes of inactivity
-the maximum amount of time a user is allowed on the router is 15 minutes
-60 second prior to automtically logging off, there should be a messag warning the user so they can finish up and save the config:

R4:
username NOC password 0 CISCO
!
line vty 0 4
exec-timeout 5 0
logout-warning 60
absolute-timeout 15
login local

7.3 (Remote Access Security)

When told to increase the security to your password database on R4 so that the password for the NOC is stored as an MD5 hash:

R4:
no username NOC password CISCO
username NOC secret CISCO

7.4 (Syslog)

When told to have R3 log all severity 7 and below messages to a syslog server 132.1.33.100:

R3:
logging 132.1.33.100
logging trap debugging

When told that R3 should not generate a log when its interface S1/0 changes status but should when a FR DLCI changes status:

R3:
int s1/0
no logging event link-status
logging event dlci-status-change

7.5 (Traffic Accounting)

When told to collect usage statics on packets that violate R5 and R6′s traffic filtering policy by configuring R5 and R6 to collect these statistics and store them locally. They should store up to 2500 entries in memory:

R5:
int fa0/1
ip accounting access-violations
!
ip accounting-threshold 2500

R6:
int s0/0
ip accounting access-violations
!
ip accounting-threshold 2500

8 (QOS)
8.1 (Congestion Management)

When told there is congestion on the FR link between R3 and R5 because users behind BB2 accessing SMTP server 132.1.3.100 complained it was slow. You now want to guarentee at least 256Kbps for SMTP packets during times of congestion assuming R3 and R5 have a port speed of 512Kbps:

R3:
class-map match-all SMTP_TRAFFIC
match access-group name SMTP_TRAFFIC
!
policy-map CBWFQ
class SMTP_TRAFFIC
bandwidth 256
!
int s1/1
bandwidth 512
service-policy output CBWFQ
!
ip access-list ext SMTP_TRAFFIC
permit tcp host 132.1.3.100 eq smtp any

R5:
class-map match-all SMTP_TRAFFIC
match access-group name SMTP_TRAFFIC
!
policy-map CBWFQ
class SMTP_TRAFFIC
bandwidth 256
!
int s0/0
bandwidth 512
service-policy output CBWFQ
!
ip access-list ext SMTP_TRAFFIC
permit tcp host 132.1.3.100 eq smtp any

8.2 (Policy Routing)

When told since users in VLAN26 are complaining about slow response time to a FTP server located in VLAN33 with the ip address 132.1.33.33 should be using the serial link between R2 and R3 and NOT the FR link. All other traffic should uses the normal paths. The FTP server does not support PASV FTP connections:

R2:
int fa0/0
ip policy route-map POLICY_ROUTE
!
ip access-list ext FTP_FROM_VLAN6
permit tcp 132.1.26.0 0.0.0.255 host 132.1.33.33 eq ftp
permit tcp 132.1.26.0 0.0.0.255 host 132.1.33.33 eq ftp=data
!
route-map POLICY_ROUTE permit 10
match ip address FTP_FROM_VLAN6
set ip next-hop 132.1.23.3

R3:
int fa0/1
ip policy route-map POLICY_ROUTE
!
ip access-list ext FTP_FROM_SERVER
permit tcp host 132.1.33.33 eq ftp 132.1.26.0 0.0.0.255
permit tcp host 132.1.33.33 eq ftp-data 132.1.26.0 0.0.0.255
!
route-map POLICY_ROUTE permit 10
match ip address FTP_FROM_SERVER
set ip next-hop 132.1.23.2
!
ip access-list stan EXT_VIA_OSPF
permit 132.1.26.0
!
router ospf 1
distance 89 0.0.0.0 255.255.255.255 EXT_VIA_OSPF

8.3 (Congestion Management)

When told to that they want to have guarenteed at least 256Kbps on the serial link between VLAN 26 (R2) and the file server (R3) during times of congestion:

R2:
class-map match-all FTP_FROM_VLAN6
match access-group name FTP_FROM_VLAN6
!
policy-map FTP_256K
class FTP_FROM_VLAN6
bandwidth 256
!
int s0/1
bandwidth 1536
service-policy output FTP_256K

R3:
class-map match-all FTP_FROM_SERVER
match access-group name FTP_FROM_SERVER
!
policy-map FTP_256K
class FTP_FROM_SERVER
bandwidth 256
!
int s1/3
bandwidth 1536
service-policy output FTP_256K

8.4 (Frame Relay Traffic Shaping)

When told that VOICE traffic will be used on the pipe between R2 (DLCI 204) and R4 (DLCI 402), you know have to configure FRTS based on:
-R2′s link to the FR cloud has a port speed of 512Kpbs
-R2 has had a CIR of 128Kbps provisioned for DLCI 204 by the telco
-R4′s link to the FR cloud has a port speed of 512Kbps
-R4 has had a CIR of 128Kbps provisioned for DLCI 402 by the telco
-There should be no burst above provisioned CIR for both DLCIs
-To make sure you are not oversubscribing, limit all other DLCI’s on R2 and R4 to a rate of equal to half the remaining bandwidth (port speed minus provisioned CIR)
-Use lowest interval (Tc) available for the DLCI’s between R2 and R4
-All other DLCI’s should use the default interval (Tc)

R2:
int s0/0
frame-relay traffic-shaping
frame-relay class REMAINING_BW
frame-relay interface-dlci 204
class DLCI_204
!
map-class frame-relay DLCI_204
frame-relay cir 128000
frame-relay bc 1280
!
map-class frame-relay REMAINING_BW
frame-relay cir 192000
frame-relay bc 24000

R4:
int s0/0
frame-relay traffic-shaping
frame-relay class REMAINING_BW
frame-relay interface-dlci 402
class DLCI_204
!
map-class frame-relay DLCI_402
frame-relay cir 128000
frame-relay bc 1280
!
map-class frame-relay REMAINING_BW
frame-relay cir 192000
frame-relay bc 24000

Share|
About Kerry Cordero, CCNP

Kerry Cordero is a MCSE, MCSA, CCNA, CCNP, and Cisco Specialist: Firewall and VPN who lives in Miami, Florida and Nassau, Bahamas. He has more than 10 years of experience in designing, implementing, troubleshooting, and managing medium and large enterprise LAN and WAN networks.

Comments are closed.