Browsed by
Category: Technology

CCIE: Blueprint Practice Configs – IP Services

CCIE: Blueprint Practice Configs – IP Services

IP Services

ARP:

ARP is the process of resolving unknown L2 (MAC) information FROM known L3 (IP) information. Inverse ARP is learning unknown L3 (IP) information from known L2 (DLCI) information. 

Proxy ARP, as defined in RFC 1027, was implemented to enable devices that are separated into physical network segments connected by a router in the same IP network or subnetwork to resolve the IP-to-MAC addresses. When devices are not in the same data link layer network but in the same IP network, they try to transmit data to each other as if they are on the local network. However, the router that separates the devices will not send a broadcast message because routers do not pass hardware-layer broadcasts. The addresses cannot be resolved.

Proxy ARP is enabled by default so the “proxy router” that resides between the local networks will respond with its MAC address as if it is the router to which the broadcast is addressed. When the sending device receives the MAC address of the proxy router, it sends the datagram to the proxy router that in turns sends the datagram to the designated device.

Proxy ARP is invoked by the following conditions:

  • The target IP address is not on the same physical network (LAN) on which the request is received.
  • The networking device has one or more routes to the target IP address.
  • All of the routes to the target IP address go through interfaces other than the one on which the request is received.

When proxy ARP is disabled, a device will respond to ARP requests received on its interface only if the target IP address is the same as its IP address, or the target IP address in the ARP request has a statically configured ARP alias.

Sample Proxy ARP Configuration:

interface fa0/0
ip proxy-arp (no ip proxy-arp to disable)
ip local-proxy-arp

The local proxy ARP feature allows the Multilayer Switching Feature Card (MSFC) to respond to ARP requests for IP addresses within a subnet where normally no routing is required. With the local proxy ARP feature enabled, the MSFC responds to all ARP requests for IP addresses within the subnet and forwards all traffic between hosts in the subnet. Use this feature only on subnets where hosts are intentionally prevented (isolated/pVLAN) from communicating directly to the switch on which they are connected.

Before the local proxy ARP feature can be used, the IP proxy ARP feature must be enabled. The IP proxy ARP feature is enabled by default.

Internet Control Message Protocol (ICMP) redirects are disabled on interfaces where the local proxy ARP feature is enabled.

HSRP:

Preemption is recommend for deterministic behavior.
Use groups that relate to VLAN ID or IP addressing scheme.
HSRP vV1: Virtual MAC address is 0000:0c07:ac XX where XX = the group ID.
For example group 146 would be 0000:0c07:ac92
HEX to DEC 142 = 92 or Binary 1001 0010

HSRP version 2 is designed to address the following issues relative to HSRP version 1:

Previously, millisecond timer values are not advertised or learned. HSRP version 2 advertises and learns millisecond timer values. This change ensures stability of the HSRP groups in all cases.

Group numbers are restricted to the range from 0 to 255. HSRP version 2 expands the group number range from 0 to 4095.

HSRP version 2 provides improved management and troubleshooting. With HSRP version 1, there is no method to identify from HSRP active hello messages which physical router sent the message because the source MAC address is the HSRP virtual MAC address. The HSRP version 2 packet format includes a 6-byte identifier field that is used to uniquely identify the sender of the message. Typically, this field is populated with the interface MAC address.

The multicast address 224.0.0.2 is used to send HSRP hello messages. This address can conflict with Cisco Group Management Protocol (CGMP) leave processing.

Version 1 is the default version of HSRP.

HSRP version 2 permits an expanded group number range, 0 to 4095, and consequently uses a new MAC address range 0000.0C9F.F000 to 0000.0C9F.FFFF. The increased group number range does not imply that an interface can, or should, support that many HSRP groups. The expanded group number range was changed to allow the group number to match the VLAN number on subinterfaces.

 

 

 

 

 

 

CCIE: R&S Lab Attempt and Next Steps

CCIE: R&S Lab Attempt and Next Steps

So, it’s been over a week since my last lab attempt and I have had plenty of time to reflect.

I will say that I underestimated the troubleshooting section considerably. My advise is when you hit a difficult question, do not linger on it, move on and try to come back if you have time. It’s hard to assess which tickets are the challenging ones without a little investigation. I will say that if you cannot solve the ticket within 10-15 minutes… MOVE ON. Next the configuration section was challenging, but very very passable. This is the CCIE lab after all, should we expect anything less that a formidable challenge?

I’m bummed out, but now it’s time to hit my study material and work on areas that need attention such as PfR, 802.1s, IPv6, ZBF, IPS, 802.1x, WCCP, EEM, and LAN QoS.

I’m going to try things a little different. I have used INE, CCBOOTCAMP, and Narbik materials in the past. This time I’m using two things. The Blueprint, and Cisco documentation. I’m going to work my way through (bottom up) the blueprint and after I’ve completed go back to my INE Mock Labs and see the results. My plan is to so engrain the theory and configs into my head, that I don’t need to worry about accessing the reference material when I take my next lab. I would highly recommend the vendors workbooks (INE’s worked the best for me) as the starting point, but I need to try something a little different and the Cisco documentation goes into much more detail.

 

Cisco: Jabber Video for TelePresence

Cisco: Jabber Video for TelePresence

Experience telepresence with your family/friends/coworkers. Try our free Jabber Video client today. HD video camera recommended.

https://www.ciscojabbervideo.com/home

http://www.cisco.com/en/US/prod/collateral/ps7060/ps11303/ps11310/ps11328/data_sheet_c78-628609.html

Jabber Video system requirements

Windows

Windows 7, Vista, or XP (SP 2 or newer), with:
• OpenGL 1.2 or newer
• For 720p HD calls, Intel Core2Duo @ 1.2 GHz or better
• For VGA calls, Intel Atom @ 1.6 GHz or better

Webcam (built-in or external; you’ll need an HD webcam for the other side to see you in HD)

Broadband Internet connection with a recommended bandwidth of 768 kbps upstream and downstream. A 720p HD call will require approximately 1.2 Mbps upstream and downstream.

Mac

Apple Intel x86 processor computer, running OS X 10.6 (Snow Leopard) or newer, with:
• For 720p HD calls, Intel Core2Duo @ 1.2 GHz or better
• For optimal performance, we recommend Intel Core2Duo @ 2 GHz, with 2MB L2 cache per core

Webcam (built-in or external; you’ll need an HD webcam for the other side to see you in HD)

Broadband Internet connection with a recommended bandwidth of 768 kbps upstream and downstream. A 720p HD call will require approximately 1.2 Mbps upstream and downstream.

 

 

 

 

 

 

CCIE: QoS

CCIE: QoS

Hold-Queue & Hardware TX Ring:

TX-Ring DEFAULT on 1841 (128) packets on a FastEthernet interface
“tx-ring-limit X” verify with “sh controller fa 0/1 | in tx”

FIFO Ingress queue is 75 packets by default and 40 packets on an 1841 FastEthernet interface

“hold-queue X in|out” verify with “sh interface fa0/1 | in queue”

Keep in mind that the software queue is only invoked when the hardware (TX-RING/FIFO) is full. CPU/packet spikes can tie up CPU cycles causing the router to use the queues.

WFQ: Fair-queue can be configured using the following commands. FLOW BASED (IP S/D, Port S/D, Protocol type)

 bandwidth 128 (helps WFQ choose best settings, but does not directly influence the algorithm)
 tx-ring-limit 1 (forces the software queue to take affect)
 tx-queue-limit 1
 fair-queue 16 128 8 (16 packets, 128 conversations, 8 RSVP queues)
 hold-queue 256 out
 ip mtu 996 (+ 4B overhead due to HDLC) This is L3 fragmentation and is NOT recommended because it's going to reduce effective throughput for large size packets.

Tc = Bc/CiR

1536000 bits per second, 1 sec = 1000ms, 1000B (MAX SIZE), 1000B * 8 (8000 bits)
8000/1536000 = .005 * 1000(ms) = 5ms
Now let's say I want a Tc of 8 ms. Use this formula CiR * (8/1000)
1536000 * .008 = 12288 (Bc)

8ms = 12288/1536000

If we need to use a TC of 12ms on the same pvc:

1 Bc = CIR x (TC/1000)
2 Bc = 1536000 x (12/1000)
3 Bc = 18432
Legacy RTP Prioritization and Reserved Queue:
ip rtp priority range-start range-end BW
ip rtp reserved range-start range-end BW  
max-reserved-bandwidth percentage up to 100 (default is 75%)
Selective Packet Discard (Input Queue Priority): Input FIFO Queue Modification, Control Plane protocols such as HSRP, BGP Updates, IGP's, PIM, L2 keepalives, etc... Processor switched, or erroneous packets. 
***HIDDEN IOS COMMAND***
  spd enable
  spd headroom 120
  ip spd mode agg (normal and aggressive modes) Malformed packets are dropped as soon as the hold queue grows above minimum threshold. 
  ip spd queue max-thres 150
 "sh ip spd" to verify configuration.
Payload Compression on Serial Interfaces: STAC: CPU Intensive, replaces repetitive data with index value. Predictor: Memory Intensive, not as effective as STAC/LZ algorithm  Only allowed on HDLC/PPP/FR links with 2Mbps or less of bandwidth. HDLC only supports STAC, PPP supports Predictor. Something to remember is that with MQC vs. legacy QoS, packets are compressed BEFORE the burst or queue weight is calculated. 
Configs:
int ser 0/1/0
encap hdlc
compress stac

int ser 0/0/0
 frame-relay map ip 155.17.0.5 205 broadcast ietf payload-compression FRF9 stac one-way-negotiation

int ser 0/1/0
encap ppp
compress predictor

Verify with "sh compress detail" and "sh frame-relay map".
Test with repetitive data ping. "ping x.x.x.x size 500 rep 100 data ABAB"
TCP/RTP Header Compression:
  int ser 0/1/0
  ip tcp header-compression
  ip tcp compression-connections 32 (TCP/RTP is bi-directional requires a context on each side)
  ip rtp header-compression
  ip rtp compression-connections 32
Verify with "sh ip rtp/tcp header-compression"
MLP (multilink PPP): 
Configure with either "ppp multilink group#" & "int multilink group#" or 
"ppp multilink", int virtual-templateX, "multilink virtual-template X" (Single Interface in MLP group) or
Dialer interface
LFI: "ppp multilink fragment", "ppp multilink interleave" Use WFQ (fair-queue) on the virtual link to further give voice packets a better chance of being serviced. 
Also, I don't believe interleaving will work with FIFO!   
Frame-Relay Broadcast Queue:
  Broadcast queue 0/64, broadcasts sent/dropped 22932/0, interface broadcasts 5735
Modify with "frame-relay broadcast-queue 16(total for ALL pvc) 1280B 10pps



							
CCIE: Multicast

CCIE: Multicast

Preface: To clear old entries in the multicast table, use “clear ip mroute *”. This command usually will allow changes to be sync:ed, but not always. In the worst case scenario, you may have to reload the device. Modifications to a working multicast environment is not recommended if you cannot interrupt traffic forwarding. Be sure to schedule maintenance window in a REAL production environment. 

PIM: Signaling protocol that uses the unicast routing table to preform RPF checks.

Dense mode: Flood to all multicast enabled interfaces and downstream routers prune back. Interface is excluded from the OIL for the pruned group. This results in excessive flooding as the state expires in 3 minutes by default and then flooding out that interface will resume. This is a plug & play method, but is not scaleable. State Refresh is enabled by default to send control messages (60 seconds) and keep interfaces pruned if necessary.

RPF Failure: This is one of the most common issues in a multicast routing domain. Unicast shortest paths not matching the multicast distribution tree is a common example. Simple fix would be a static mroute.”ip mroute 0.0.0.0 0.0.0.0 x.x.x.x (correct RPF interface).

Be very careful of static routes in a multicast environment as they change the local routers perception of shortest path.

In the output of “sh ip mroute” look for an S,G entry that has an incoming (towards the source) interface of NULL. This is an indication that the multicast path is different from the unicast route table entry for the source.

“debug ip mpacket”
enable process switching on the multicast interface
“no ip mroute-cache”

PIM Assert Message vs. PIM DR:
This is something that took me sometime to fully understand. On a multi-access (LAN) network, one router may win the assert process, while another may become the IGMP querier (PIM DR or IGMP Querier v2). The winner of the Assert is the one responsible for forwarding multicast one the LAN and the IGMP querier is responsible for managing the IGMp process and sending IGMP query messages on the LAN.

IGMP v1 had not querier, so it required a PIM-DR. 

Auto-RP:

interface loopback 0
ip pim sparse-dense-mode (required dense mode SPT for 224.0.1.40 and 224.0.1.39), make sure to use “no ip pim dm-fallback” in a live network. You could also define static RP for the Auto-RP groups with “override” option. The best option for Auto-RP is SM with auto-rp listener.

ip pim send-rp-announce loopback 0 scope 12 (cRP)
ip pim send-rp-discovery loopback 0 scope 12  (Mapping Agent) selects best RP for group range

Negative ACL: “DENY” will cause group to fall back to dense mode. Effectively, a single cRP could announce a deny any and cause all groups to be treated as dense. The reason being is in the order process negative/deny are first.

Filter Auto-RP Messages with TTL Scoping (low number for boundary threshold) or “ip multicast boundary”. Multicast boundary filters at control plane (PIM/IGMP/Auto-RP) and data plane (multicast route state). WIth IOS 12.3(17)T and higher the in/out keywords are possible. In affects control and Out affects the data plane.

Bootstrap Router (BSR): 

Standards based for PIMv2, does not use any dense mode groups like Auto-RP.

Configure candidate RP with “ip pim rp-candidate interface | group-list | interval | priority ”
Configure BSR (MAPPING) with ” ip pim bsr-candidate interface | hash | priority|

Filtering BSR: Filter RP info with “ip pim bsr-border” on the edge of the multicast domain.

Stub Multicast (IGMP Helper):

Head-end/Hub runs sparse mode pim. Remote/stub uses dense mode. Remote router acts as a “dumb” packet forwarder.

R1: Stub/Remote

int fa0/0
ip pim dense-mode
ip igmp helper-address 10.0.0.5

int ser 0/0/0
ip pim dense-mode
ip add 10.0.0.1 255.255.255.0

R5: Hub
int ser 0/0/0
ip pim sparse-mode
ip add 10.0.0.5
ip pim neighbor-filter 7

access-list 7 deny 10.0.0.3
access-list 7 permit any

SW1: Client side
int fa 0/1
ip pim dense-mode
ip pim neighbor-filter 8 (disallows R1 and SW1 to become PIM neighbor)

access-list 8 deny any

IGMP Timers:

Reports are sent ASYNC, so some might be missed by the router. On a shared segment, one IGMP querier is elected designated and send membership queries to hosts. Lowest IP address win election. This is confusing because the DR is elected by highest IP. 60 seconds is the default query time and the timeout is 2x that value (120). IGMP v1 has no leave group message and introduces leave latency.

“ip igmp querier-timeout”

MTRACE: Trace from the leaf to the root. mtrace 150.17.10.10 (leaf) 239.1.1.1 (group) output will trace back to the root (RP). Preform on the RP.

New Edition to my Neo Collection!

New Edition to my Neo Collection!

Not sure if anyone really cares, but I’m a huge NeoGeo fan/collector.. Today I found quite a surprise at a local gaming store. English version of SvC Chaos (SNK vs. Capcom) for the NeoGeo AES. Needless to say, I did not even hesitate for a second and bought it. It’s in pristine condition and I’ll probably spend the rest of the night obsessing on how beautiful the condition is. Enjoy these pics and Thank You Play N Trade!

Game Data: 
AES
N.American version
708 MEGS (Mbits) / 88.5MB
Released: Nov. 2003 for AES , July 2003 MVS

CCIE: STP (802.1d)

CCIE: STP (802.1d)

So, first a little history on Spanning tree protocol (STP). Based on an algorithm created by Radia Pearlman in 1985. http://en.wikipedia.org/wiki/Radia_Perlman

Became a standard IEEE protocol in 1990. Still widely deployed. Flavors of spanning tree. 802.1d (ieee), 802.1w (rapid), and 802.1s (mst). Evolution of STP, Cisco vPC (2-way non blocking, still requires STP) and Fabric Path (eliminates STP completely). TRILL is a standardized version of Fabric Path. Both TRILL and Fabric Path utilize a link state protocol (IS-IS) as their loop prevention method.

Specific Cisco enhancement to 802.1d (prior to 802.1w): UplinkFast and BackboneFast

UplinkFast: The UplinkFast feature is designed to run in a switched environment when the switch has at least one alternate/backup root port (port in blocking state), that is why Cisco recommends that UplinkFast be enabled only for switches with blocked ports, typically at the access-layer. Do not use on switches without the implied topology knowledge of a alternative/backup root link typically to distribution and core switches in Cisco multilayer design. ONLY enable on NON-ROOT switches. 

In order to be effective, the feature needs to have blocked ports that provides redundant connectivity to the root. As soon as Uplink Fast is configured on a switch, switch automatically adjusts some STP parameters are adjusted in order to help achieve this:

  • The bridge priority of the switch is increased to a significantly higher value than the default. This ensures that the switch is not likely to be elected root bridge, which does not have any root ports (all ports are designated).
  • All the ports of the switch have their cost increased by 3000. This ensures that switch ports are not likely be elected designated ports.

BackboneFast: