Otherwise you’ll spend an hour beating your head against the wall trying to figure out why ssh slavehost date works, but send2slaves -t slavehost doesn’t.

In this example, we want to manipulate the routing as follows:

• Traffic between the 192.168.1.0/24 local network and 10.0.1.0/24 remote network should prefer PATH #1
• Traffic between the 192.168.2.0/24 local network and 10.0.2.0/24 remote network should prefer PATH #2

Note: for the purpose of this example we will assume that the specified local and remote networks only talk to each other. We don’t need to consider traffic between 192.168.1.0/24 and other remote networks, for example.

router bgp 65000
  network 192.168.1.0 mask 255.255.255.0
  network 192.168.2.0 mask 255.255.255.0
  !
  neighbor 1.1.1.1 remote-as 65534
  neighbor 1.1.1.1 send-community
  neighbor 1.1.1.1 route-map PATH1-LEARN in
  neighbor 1.1.1.1 route-map PATH1-ADVERTISE out
  !
  neighbor 2.2.2.2 remote-as 65534
  neighbor 2.2.2.2 send-community
  neighbor 2.2.2.2 route-map PATH2-LEARN in
  neighbor 2.2.2.2 route-map PATH2-ADVERTISE out
!

First we need to define our ACLs to specify which traffic prefers which path

ip access-list standard PREFER-PATH1-LOCAL
  permit 192.168.1.0 0.0.0.255
!
ip access-list standard PREFER-PATH1-REMOTE
  permit 10.0.1.0 0.0.0.255
!
ip access-list standard PREFER-PATH2-LOCAL
  permit 192.168.2.0 0.0.0.255
!
ip access-list standard PREFER-PATH2-REMOTE
  permit 10.0.2.0 0.0.0.255
!

As we learn routes, we raise the local preference on routes coming from the preferred path, so they are chosen over the same routes learned on the other path with a default of 100.

The permit 999 ensures all routes are still learned from both peers, even if they’re not being manipulated.

route-map PATH1-LEARN permit 10
  match ip address PREFER-PATH1-REMOTE
  set local-preference 110
!
route-map PATH1-LEARN permit 999
!
route-map PATH2-LEARN permit 10
  match ip address PREFER-PATH2-REMOTE
  set local-preference 110
!
route-map PATH2-LEARN permit 999
!

For incoming traffic, we need to influence the ISP’s routing decisions. There are several ways of doing this, including the MED. In our case, we’ll use the ISP’s pre-defined community values to force them to set a local preference on certain routes.

Again, the permit 999 rules ensure that we’re still sending all our routes to both peers, even if they don’t get tagged.

route-map PATH1-ADVERTISE permit 10
  match ip address PREFER-PATH1-LOCAL
  set community 65534:110
!
route-map PATH1-ADVERTISE permit 999
!
route-map PATH2-ADVERTISE permit 15
  match ip address PREFER-PATH2-LOCAL
  set community 65534:110
!
route-map PATH2-ADVERTISE permit 999
!

Section 1: Layer 2 configuration

- when creating an SVI for a given VLAN, always make sure the VLAN itself exists on all switches in the transit path for that VLAN.

- if the lab specifies restricting “management access”, don’t forget to check if the HTTP server is enabled and add a similar access class to it as to the VTY’s.

- Filtering traffic by ethertype

mac access-list extended F0_15
  deny   any any 0x1234 0x0
  permit any any
!
int fa0/15
  mac access-group F0_15 in
!

- VLAN filtering by MAC address

mac access-list extended VL123
  permit host 0000.1234.4321 host 0000.4321.1234
!
vlan access-map VL123 10
  action forward
  match mac address VL123
vlan access-map VL123 999
  action drop
!
vlan filter VL123 vlan-list 123

No real problems with this section other than interpretation on the VLAN filtering. In a lab, I’d ask the proctor if they meant traffic from this *range* of MAC addresses or just between the two.

Section 2: Pix / ASA Configuration

- When originating a default route and running RIP on both inside & outside, use a route-map with ‘match interface’ to control which side we send the default route to.

- don’t be so quick to assume an answer. Configured HTTP/HTTPS and missed that the question said a “Web/SMTP/DNS” server so left out a bunch of the ACL.

- when configuring AAA through a firewall, don’t forget to set the source int on the remote device if required.

- remember that a transparent firewall will not pass anything inbound by default (except ARP) without an access-list. Just like a routed firewall.

- a transparent firewall must have a management IP address configured or it will not pass any traffic, even if that traffic would otherwise be allowed.

- always check for required single/multiple changes, since it needs a reboot of the device and wastes time.

- basic process for setting up contexts

admin-context FOO
context FOO
  config-url disk0:/FOO.txt
!
context BAR
  config-url disk0:/BAR.txt
  allocate-interface eth0/0
  allocate-interface eth0/1
!

- when configuring local authentication on the ASA, don’t forget to explicitly enable it, for ssh/telnet

hostname ASA1
domain-name ipexpert.com
crypto key generate rsa general-keys
ssh 1.2.3.0 255.255.255.0 inside
username cisco password cisco
aaa authentication ssh console LOCAL

Section 3: IDS Configuration

- I need to spend time learning the IDS command line. I’m fairly solid through IDM but not through the CLI.

- IOS IPS basic config

ip ips name FOO
ip ips notify log
logging host 1.2.3.4
logging on
int se0/1/0
ip ips FOO in
!

Section 7: VPN Configuration

- when configuring L2L VPN’s on the VPN3000 through the GUI, be careful when configuring the interesting traffic. The mask is specified as a *wildcard* mask, e.g. 0.0.0.255, not a subnet mask.

• IPExpert’s one week R&S bootcamp in San Jose
• IPExpert’s one week mock lab workshop in San Jose
• InternetworkExpert’s “Open Lecture” multicast troubleshooting (in progress)
• InternetworkExpert’s 5-day lab bootcamp CoD (in progress)
• InternetworkExpert’s Adv. Technology CoD on redistribution (in progress)
• Working through IEWB3 to get better at core technology, especially redistribution