Browsed by
Category: CCIE Studies

Private VLANs (PVLANs)

Private VLANs (PVLANs)

I recently had one of my customers asked about private VLANs and the benefits/use cases. I thought this was a good opportunity to refresh my knowledge of PVLANs because it was a weak area of mine during my last CCIE lab.

What are Private VLANs?

The main objective with PVLANs is conserving IP space, but still allowing L2 separation for security purposes. Typically, VLAN design calls for a single IP subnet for each VLAN. Here we are able to create multiple (secondary VLAN/s) VLANs for isolation, but conserve space by using a single subnet for all the secondary VLANs.


Primary VLAN: These are promiscious ports that can send and recieve frames with any other port Type (P-Port,C-Port,I-Port).
Secondary VLAN or VLANs:

  • Isolated: Any switch ports associated with an Isolated VLAN can reach the primary VLAN, but not any other Secondary VLAN. In addition, hosts associated with the same Isolated VLAN cannot reach each other. Only one Isolated VLAN is allowed in one Private VLAN domain.
  • Community: Any switch ports associated with a common community VLAN can communicate with each other and with the primary VLAN but not with any other secondary VLAN. There can be multiple distinct community VLANs within one Private VLAN domain.

Port Types: Promiscuous, Community, Isolated (easy way to remember this is PCI).

What is the use case?
Service Providers with multi-tenant buildings- HSRP Routers, switch, and multiple SMB customers sharing the same public IP space.
Hotel Internet Access- It would be undesired for the guests to see each other.
DMZ- Instead of creating multiple DMZ’s you could isolated the hosts within a DMZ from each other.
Cloud/Co-location Facilities- You want to use the same subnet but restrict traffic between customers/services.

Are there any vulnerabilities or exploits?
Here is the deal, I’ll be the first to say while by design this is not possible. I have found with network/data security to NEVER say NEVER. That being said. I-Ports are not allowed to send frames/IP packets to any other destination other than the P-Port (uplink). So, even if the D-MAC address, or  VLAN ID is changed, it will only flow to the P-port.

For more infomration on what I’m talking about, take a look at this link describing “Private VLAN attack”.
*** “Local-Proxy-arp” would have to be enabled on the router for the same subnet, “Proxy-Arp” for different subnets. ***
For the best protection make sure you leverage ACL’s to block unnecessary L3 communications between hosts.  

If a SP was going to use a separate VLAN ID for every customer we would be limited to 4000+ customers and that would really waste IP space if we were assigning separate subnet to each VLAN like best practice dictates. With PVLANs the broadcast domain of a single VLAN is split into sub-domains (I-ports and C-Ports). What does all this mean? Well for one you block L2 frames (CDP/STP/etc..) from the isolated hosts and are able to scale multi-tenant solutions while conserving IP space.

“If the private VLAN feature is properly deployed, it can be used at
Layer 2 to segregate individual users or groups of users from each
other: this segregation allows a network designer to more effectively
constrain Layer 2 forwarding so as to, for instance, block or contain
unwanted inter-device communication like port scans or Address
Resolution Protocol (ARP) poisoning attacks.” – RFC5517

My Test Configuration:
Private VLANs can ONLY be configured in VTP TRANSPARENT or VTPv3 mode.

VLAN 500 (Primary VLAN P-Port)
VLAN 501 (Secondary VLAN I-Ports)
VLAN 502 (Secondary VLAN C-Ports)
FA0/1 is the promiscuous port with the router attached. 

sw1#sh vlan private-vlan

Primary Secondary Type Ports
——- ——— —————– ——————————————
500 501 isolated Fa0/1, Fa0/31, Fa0/32
500 502 community Fa0/1, Fa0/33, Fa0/34, Fa0/35

sw1#ip routing

vlan 500
private-vlan primary
private-vlan association 501-502
vlan 501
private-vlan isolated
vlan 502
private-vlan community

interface FastEthernet0/1
switchport private-vlan mapping 500 501-502
switchport mode private-vlan promiscuous

interface FastEthernet0/31
switchport private-vlan host-association 500 501
switchport mode private-vlan host
interface FastEthernet0/32
switchport private-vlan host-association 500 501
switchport mode private-vlan host
interface FastEthernet0/33
switchport private-vlan host-association 500 502
switchport mode private-vlan host
interface FastEthernet0/34
switchport private-vlan host-association 500 502
switchport mode private-vlan host
interface FastEthernet0/35
switchport private-vlan host-association 500 502
switchport mode private-vlan host

interface Vlan500
ip address
private-vlan mapping 501,502 (optional if the SVI is the gateway)


Verify port mapping with “sh vlan private”
Verify isolation with a ping to from each router/host.



CCIE: Blueprint Practice Configs – IP Services

CCIE: Blueprint Practice Configs – IP Services

IP Services


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.


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




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. 
  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. 
int ser 0/1/0
encap hdlc
compress stac

int ser 0/0/0
 frame-relay map ip 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 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. 


interface loopback 0
ip pim sparse-dense-mode (required dense mode SPT for and, 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

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

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

access-list 7 deny
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 (leaf) (group) output will trace back to the root (RP). Preform on the RP.



MPLS: Autoconfig (enable LDP on all interfaces) only available when using OSPF as IGP.

LDP send discovery packets via UDP to (all routers) port 646. Route-ID is highest loopback but can be forced “mpls ldp route-id x.x.x.x force”. To use the physical connection of the interface (not the loopback due to lack of reachability) use this command on the interface. ” mpls ldp discovery transport-address interface”. Once communications is established, via TCP 646, authentication is verified (MD5 only). After peer is established prefix/label information is exchanged and LFIB is built.


Two Labels: Transport and VPN Label

View Transport label with “sh mpls forwarding-table” and VPN label with “sh ip bgp vpn4 vrf XXX”

OSPF on MPLS VPN: MP-BGP cloud is super area 0 (super backbone), treated as T-3 LSA’s. SAME VPN, SAME DOMAIN_ID (PROCESS ID) T3, different DomainID, T5.

Creating a Sham-Link

Sham-Links allows MPLS network to override backdoor links.
Before you create a sham-link between PE routers in an MPLS VPN, you must:
  • Configure a separate /32 address on the remote PE so that OSPF packets can be sent over the VPN backbone to the remote end of the sham-link. The /32 address must meet the following criteria:
    • Belong to a VRF.
    • Not be advertised by OSPF.
    • Be advertised by BGP.

You can use the /32 address for other sham-links.

  • Associate the sham-link with an existing OSPF area.
EIGRP: Site of Origin – SoO
Used between the PE and CE to prevent route feedback and loops. Could be accomplished with tag and filter but that is too complex. Multi-homed CE’s and CE’s with backdoor links are ideal candidates. Also, used in BGP when the same ASN is used at all remote locations.
CE: Same ASN on both sides will not allow bgp prefixes to be advertised because of BGP’s loop prevention (same asn). You can override on the PE with the neighbor statement and “as-override” command. “Allowas-in” is another option but NOT RECOMMENDED.


Unlink IGP’s, BGP does not use metrics to select best path. Instead, BGP is vector based. This path is determined with Path Attributes (PA’s). The default PA, if no others are set is AS-PATH. Shortest path to destination prefix is the best path.

Building the neighbor relationship:

TCP Port 179 (established based on neighbor address), Open, Established, and finally Updates (contains the prefix information). If there is a problem/error a “notification” message is sent.

Keepalive is 60 and hold time is 3 times or 180sec. Sent in Open message and they DO NOT have to match. Lower of the two is used mutually.

Authentication: MD5 only
Loopbacks require extra TTL hop, so multihop may be necessary for eBGP neighbors. (iBGP TTL is 255, eBGP TTL is 1). Overcome eBGP with “ebgp-multihop 255”

Two components to the BGP Table
1) NRLI: Prefix and mask
2) PA’s (NRLI’s that share the same PA’s)

Redistribution: When redistributing INTO BGP, if the metric is set it will alter the MED PA.
Auto-summary only affects network injection locally either through redistribution or the “network” command.  

Use “aggregate-address” to preform manual summarization. AS-SET will hold a list of the unordered ASN’s in the component subnets. Without this option the AS_PATH is set to NULL. Could be good to hide originating path, bad because it can create a route loop.
A summayr can also be made with a local static route to null0 and injected with the “network” command. This will NOT suppress component subnets.

BGP Sync: Not really used today because the BGP table (full) is too big to redistribute into IGP. Use RR’s or Confeds. It was designed to prevent black-holing but in reality, is not used anymore because in order for a BGP route to be considered best an IGP has to have the route. If concerned about the number of devices that have to run BGP, you could use MPLS.

Redistribution solves the routing to black-hole and sync solves the problem of advertising a black-hole route to another AS. USE WITH CAUTION WHEN REDISTRIBUTING BGP INTO IGP. 

Without RR or Confederations, a full mesh of iBGP peers is required. If you have more than 3 BGP nodes, this would be a royal pain in the tush. Full Mesh formula is n(n-1)/2.

 (8) Node Example:  8*(8-1)/2 = 28 TCP connections! That’s too many. 

BGP: Server/Client (Use update source to force the “client”). Only necessary on one side, but it should be one both to ensure clarity.

eBGP neighbors must be directly connected. So, if your using loopbacks to peer the “disable-connected-check” command is required without modifying “eBGP-multihop”. The other option is just to modify the eBgp multihop.

Route Reflector: 

Route reflector violates the ability to learn routes from another iBGP neighbor. A new loop prevention mechanism must be used.

Originator ID: Originator of the prefix sent by the RR (used to prevent loops between the clients)
Cluster List/ID: Route reflector ID (used to prevent loops between RR’s)

An alternative to Route Reflectors, accomplishes the same functionality (no need for a full mesh), but is more intricate. Used for LARGE scale BGP deployments.

AS to be presented outside the Confederation (eBGP) is configured with the “bgp confederation id xxxxx”
For example my private ASN in the confed is 64512 and my public ASN is 75

router bgp 64512
bgp confederation id 75

SUB AS’s count as a single AS no matter how many sub AS’s are included in path. Lowest router-id wins metric tie.

If recursion cannot occur for the  “next-hop-ip” and “next-hop-self” is not enabled. The prefix will show in the BGP database but not in the route table because it’s not a “best” path “>”.

Another way to change the next-hop IP is using a route-map on the neighbor and “set ip next-hop x.x.x.x”. If you leave the match empty it will match all prefixes coming from the specified neighbor. This can be used in a TE use case, where the next-hop is not even the originating router.

Redistributing BGP into IGP: USE WITH CAUTION! If necessary, make sure to use AS-PATH access-list to limit the routes to the prefixes originating on the peer router. IGP’s can be overwhelmed by a full BGP Internet route table. On a side note: RIB failures in BGP are advertised to neighbors, to prevent this default behavior issue the following command under the BGP process. “BGP suppress-inactive”

iBGP into IGP redistribution is NOT recommended because of the potential of loops to occur. Remember with iBGP the as_path is NOT preserved. If you MUST do so with caution… You have been warned.

Override default behavior (not allowed to redistribute into IGP): BGP> “BGP redistribute-internal”

BGP “auto-summary” works with 1) Redistribution of routes into BGP or 2) using the network command to advertise a classful address.

BGP Best Path Selection:

1) Weight – (non-transitive/local only) Can be set per neighbor or per an inbound route-map
2) Local Preference (transitive within a single AS)- Can be set per an inbound route-map

Un-suppress on a per neighbor basis and use route-map to un-suppress/suppress globally. IN the route-map use deny on the prefix to be allowed and permit to suppress.

Local-AS: Use this is allow a peer to use a different ASN from the global. Could be used for an AS migration. “no-prepend” will remove oldAS from the sting for INCOMING prefixes. This does NOT work for advertised prefixes. “replace-as” will remove newAS from string. Finally, “dual-AS” allows for a peer to use either ASN for peering.

“Remove-private-AS” on external peers only.

BGP Timers:

BGP Scanner: Default of 60 seconds, Conditional route advertisements, next-hop check, imports routes, route dampening. Change with “bgp scan-time”

Route Refresh/Soft Reconfiguration: RR replaced Soft Reconfiguration.

Batch routing updates: Updates and keepalives change with “neighbor x.x.x.x  advertisement-interval <seconds)”.

Timers Hello/Hold: Default of 60 hello and 180 sec. hold.

BGP Fast Failover: By default, if an interface goes down the peer session will go down. This feature is good for PTP links but not so good for shared links. Disable it with “no bgp fast-external-fallover”

Fast peering: Use “neighbor x.x.x.x fall-over” iBGP or eBGP based on route availability to the peer.

BGP Nexthop trigger: Event drived and enabled by default. Change with “bgp nexthop trigger delay xx”.




auto-summary in RIP affects what is advertised, but not the local RIB.
Preventing route feedback: Prevent router feedback (RIP) with static route to null0 or distribute-list (IN) on originating router.
interface> ip rip advertise (interval different than the global)
default sent out specific interface: use route-map that sets interface and default-information originate.
ACL to filter even/odd octets:
ip access permit : permit 3rd octet odd only
ip access permit : permit 3rd octet even only
Track route with route-map for default route injection. 

Reliable Conditional Default Routing:
track 1 ip sla 1 reachability router rip
 version 2
 default-information originate route-map SLA ip route Null0 name BOGUS track 1
ip prefix-list SLA seq 5 permit
ip sla 1
 icmp-echo source-interface FastEthernet0/0
ip sla schedule 1 life forever start-time now
route-map SLA permit 10
 match ip address prefix-list SLA
RIP Unicast updates:
neighbor statement and passive interface command.
Without passive interface, broadcast and multicast updates will continue to be sent. RIP Broadcast Update: interface> ip rip v2-broadcast
RIP Triggered Updates: interface> ip rip triggered  RIP Source Validation: (Do I have a path bath in the RIB?) Router RIP no validate-update-source (to disable check) 
CCIE: GRE Tunneling/Recursive Routing

CCIE: GRE Tunneling/Recursive Routing

Here is a subject and burned me in my last lab. I had a much more complex environment, but the fundamentals are the same.

Recursive routing errors occur when the tunnel destination is dynamically learned across the tunnel interface itself. Here are two simple methods to correct this behaivor.

1) Static route to the tunnel destination via any interface/path, but the tunnel interface (lower metric then a dynamic learned IGP). On the CCIE lab static routes are generally a no-no, that being said I would use method #2 or another filter method.

2) Distribution list to filter the tunnel destination from being learned via the IGP across the tunnel interface.

Example: Tunnel destination is on R2 and on R1

ip prefix-list RECURSIVE seq 10 deny
ip prefix-list RECURSIVE seq 20 permit le 32

Router (eigrp,rip,ospf,bgp)
distribute-list prefix RECURSIVE out tunnel(X)

ip prefix-list RECURSIVE seq 10 deny
ip prefix-list RECURSIVE seq 20 permit le 32

Router (eigrp,rip,ospf,bgp)
distribute-list prefix RECURSIVE out tunnel(X)



The Basics:

Link state routing protocol. Uses IP protocol 89. Hellos sent on

Uses Dijkstra SPF algorithm independently on each router against the local LSDB to calculate the best routes.

Hellos sent every 10 seconds on LAN and 30 seconds on WAN interfaces. Dead time is 4x hello, so 40sec and 120 sec respectively.

Router ID:

1) Configured “router id”
2) Highest loopback
3) Highest non loopback interface in up/up state.

Hello Process Sanity check:

Pass authentication (verify with “debug ip ospf adj”)
Same primary subnet (no secondaries used for neighbor)
Same OSPF area
Same OSPF area type (NSSA, STUB, etc…)
No duplicate RID’s
Hello/Dead times match

One a multiaccess network (LAN), DR are used to reduce LSDB flooding. Similar in concept to BGP route reflector. DR also create a type 2 LSA for the subnet. Non-DR routers send DD to the DR using (ALL DR), DR ack with unicast DD. DR floods a new DD packet to Highest priority ID wins DR election. Lookback/RID is the tie-breaker.

SPF Calculation: Lowest cost to destination. Uses OUTGOING interface cost.

Using areas will allow your routers to have smallers per-area LSDB’s ,requiring less memory.
Faster SFP computation due to the small LSDB.
Link failure in one area only requires partial SPF computation in another area.
ROUTES CAN ONLY BE SUMMARIZED ON ABR AND ASBR, this helps shrink the LSDB and improve SPF computation. “summary-address” only used on ASBR, “area X range” used on ABR, make sure that the area is where the actual routes reside/originate”.

E1= Include end-to-end metric
E2= Use metric calculated by ASBR only. (DEFAULT)

The big thing to remember, is that the ABR will not pass the dense type 1 & 2 LSAs, instead using a summary LSA type 3.

Let’s review LSA types real quick.
T1: Router – RID, and interface IP, neighbors, and Stub (one router with no other neighbors) – one per router
T2: Network – Created by DR on subnet, subnet and router interface on subnet WITH DR. – one per transit network (subnet with two or more routers).
T3: Summary – Created by ABR to summarize T1 & T2. Defines subnets and cost but not the topology.
T4: ASBR Summary – Host route to reach ASBR
T5: AS External – Created by ASBR’s for external routes redistributed into OSPF.
T7: NSSA External

Stub Area:

Prevent T5 LSA’s into area and ABR advertises default. Totally stubby areas also prevent T3 LSA’s into area. NSSA, allows routers to be redistributed into the stub area as a T7.

Interface Network Types:

non-broadcast: DR/BDR election, neighbor statement required, unicast hellos, no next-hop modification, so all spokes require recursive lookup
point-to-multipoint: no DR/BDR election, no neighbor, multicast hellos to, stub endpoint advertisement (/32) instead of a transit network.

Auto-cost Reference Bandwidth: Change bandwidth on local router to see updated cost. Should be consistent across all routers to prevent SPF based loops. Interface cost= Reference Bandwidth / Interface Bandwidth (this can also be used for P-to-MP neighbor costs).

Capability-Transit: Use non-backbone areas if a shorter path exists for summary LSA (inter-area), on by default. If you want to force the traffic to take the (0) path, issue “no capability-transit” on both ends.

Demand Circuit:

On point-to-point interfaces, only one end of the demand circuit must be configured with the ip ospf demand-circuit command. Periodic hello messages are suppressed and periodic refreshes of link-state advertisements (LSAs) do not flood the demand circuit. This command allows the underlying data link layer to be closed when the topology is stable. In point-to-multipoint topology, only the multipoint end must be configured with this command.

Paranoid flooding: Every 30 minutes re-flood by default. Disable with interface level: “ip ospf flood-reduction”, verify with DoNotAge (DNA) in OSPF LSA Database.

“Flood-War” in debug is an indication of identical router-id’s competing. Loop prevention mechanism.

Conditional Default Route:

router ospf 1
 default-information originate always route-map TRACK
ip prefix-list TRACK seq 5 permit
route-map TRACK permit 10
 match ip address prefix-list TRACK
Interface fa0/1
ip add
Reliable Conditional Default:
ip sla 1
timeout 2000
frequency 5
ip sla schedule1 life forever start-time now

Track 1 rtr 1
ip route null0 track1

ip prefix-list TRACK seq 5 permit
Route-map TRACK permit 10
match ip address prefix TRACK
router ospf 1
default-information-originate always route-map TRACK


Allows filtering of the database based on the role of the LSA. Stub flag is sent as part of the hellos, so they must agree.

Stub will remove external T5 LSAs and replace them with a default. T5 LSA is setting the advertising router as it’s router ID and the forward address to In that area, if the forward is set to traffic is directed to the advertising router id. Essentially, it requires the router-id to be found in the database via an LSA T1. This process is causing redundant information in the database due to T1, T4, T5 entires. Specifically, the T5’s and T4’s are replaced with a default.

This also implies that since T5’s are filtered, redistribution cannot occur in a STUB area. The workaround? NSSA.

Totally Stubby Areas:

“area x stub NO-SUMMARY” Inter-Area (T3’s) are removed and replaced with a default. Configured on ABR only.


Not So Stubby Areas (NSSA):

“area x NSSA” This generates an LSA T7 instead of a T5. These have N1 and N2 subtypes. Much like E1 and E2. N1 considers the full path where N2 considers only the ASBR metric and not the cost to get to the ASBR. 

When traversing into Area 0, the T7 is converted into a T5. NSSA does NOT automatically generate a default route, but could be added. Important to note that if there are multiple ABR’s the one with the highest Router-ID will do the translations. 

Translate T7 to T5 will instruct the ABR to NOT perserve the value in the forward address field.
“area x nssa translate type7 supress-fa”


Not So Totally-Stubby Areas (ARE YOU FREAKING KIDDING ME???!!!):

As if NSSA, STUB, and Totally-Stubby was not confusing enough. We have “Not so totally-stubby areas”. WTF!!!

Basically a combination of Total Stub and NSSA. T3,T4,T5 are replaced with a T3 default, but also allows redistribution into the area as T7’s.

Nuff said!

Summary Routes:

Create the summary (AREA x RANGE x.x.x.x) in the AREA WITH THE ROUTES BEING SUMMARIZED!
When a summary is created on an ABR a null 0 route is created. This could cause a black hole. Override with “no discard-route internal”.

OSPF Resource Limits:

Limit LSA’s in the database: “max-lsa 10000” NON-SELF-GENERATED
Limit Redistribution: “redistribute maximum-prefix 1000”
Limit processor: “process-min-time percent 25”

Verify with “sh ip ospf”
DNS Lookup on Neighbors: “ip ospf name-lookup”
Add local host with “ip host R1”