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....