One more note

1. IPSec unnumbered tunnel interfaces (DVTI) cannot ping each other IP. "show crypto session" is the fastest way to verify that IPSec tunnel is up.
The following commands are required to configure the DVTI hub:

crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
crypto isakmp key PASS address 0.0.0.0
crypto isakmp profile NAME
 keyring default
 match identity address 0.0.0.0
 virtual-template X
!
crypto ipsec transform-set TS_NAME esp-3des esp-md5-hmac
 mode tunnel
!
crypto ipsec profile PROFILE_NAME
 set transform-set TS_NAME
!
interface Virtual-TemplateX type tunnel
 ip unnumbered LoopbackX
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile PROFILE_NAME

Note, that, even though IPSec is up, if we ping LoopbackX IP address of the peer (directly connected network via tunnel) there is no reply (even though debug shows that replies are leaving the hub when pinging from spoke). However, once I enabled OSPF on the tunnel interfaces and neighborship was formed, ping started to work.

IMPORTANT: All tunnel interfaces of all routers in VPN network MUST be unnumbered to a loopback IPs. When interfaces are unnumbered, OSPF advertises host routes for each loopback (nevertheless  all loopbacks are on directly connected DVTI network, host routes still must be advertised because without them OSPF DB is populated but no routes are not installed into the RIB).

Ping works between loopbacks that are announced on DVTI network (source AND destination IP must be any but not from directly connected tunnel network). Basically, it works between any NON-DVTI network.

P.S. It is sufficient to configure isakmp policy, isakmp key, ipsec TS and ipsec profile on the spokes. Tunnel configuration is the same as for the hub's Virtual-Template interface.

2. Are connected subnets included when redistributing EIGRP to OSPF? Looks like NO.
UPDATE: In fact, it depends. When redistributing distance-vector protocol, only routes that are actually in RIB are redistributed. Since connected route has lower AD, it takes precedence and directly connected EIGRP route is not redistributed. In this case "redistribute connected" must be used.

3. BGP loop prevention and MPLS VPN with BGP as PE-CE routing protocol. If customer uses the same AS number on both remote sites, then by default BGP will prevent the routes from different sites to be installed into the routing table because of the loop prevention mechanism. There are two solutions: A. Allowas-in on CE router. This command basically disables BGP loop prevention logic. B. As-override on PE router under customer VRF address family. This command will change AS-path attribute of the route by overriding customer AS, where route was originated, with provider's own AS. Best command to observe loop prevention behavior is "debug ip bgp updates".

4. How to drop certain packets with MQC:

class-map match-all ATTACK
 match protocol ipv6
 match SOMETHING
!
policy-map ATTACK
 class ATTACK
  drop
 class class-default
!
interface e0/0
 service-policy input ATTACK

5. Two approaches to QoS:

MQC:
-Some criteria to match traffic (ACL, for example)
-Class-map
-Policy-map with actions to matched class-map
-Service-policy input/output POLICY_MAP_NAME

CAR:
rate-limit input access-group X CR Burst BE conform-action transmit exceed-action drop

6. When MP-BGP sends an update for a prefix, it attaches multiple route attributes from redistributed protocol in form of communities. For example, it sends OSPF domain ID from remote site. By default, domain-id is equal to OSPF process number. It means that if different process numbers are configured on remote sites, on receiving end all routes will be marked as External (E2) and not IA. To specify domain-id use "domain-id number" router configuration command.

7. In order for EIGRP adjacency to form when authentication enabled, key Number that is sent must match received key number!

8. Import routes from global routing table to VRF. "import ipv4 unicast map ROUTE_MAP_NAME". Route-map must match routes via prefix lists or ACL, but the following restriction applies: ONLY BGP routes can be imported.

9. [GENERAL between VRF's] If only import map is configured under VRF (without route-target import), nothing will be imported into VRF except directly redistributed under BGP ipv4 VRf NAME address-family routes.

10. Import maps:
- Only import map - everything is blocked
- route-target import X - all routes with this RT are imported
- route-target import X + import map - All routes with RT X will be sent for the further filtering with route-map specified under "import map"

10. Export maps:
- Only export map - all routes permitted by route-map are allowed to be exported (usually used with SET clauses to set RT). Rest is dropped. If all routes must be exported, then permit statement in the end is needed.
- route-target export X -all routes with particular RT X will be allowed to be exported.
- route-target export X + export map - all routes are exported without restriction, but only routes permitted by the route-map are modified (set RT, for example).

Yet another note

1. On PE router, address families ipv4 vrf X and vpnv4 must be configured. Under vpnv4 address family neighboring PE router must be specified in order for them to start advertising vpvn4 capabilities to each other. Redistribution of customer routes occurs in ipv4 vrf X address family.

2. When redistributing route to IPv6 EIGRP and then summarizing it out of interface, route gets into EIGRP tables of neighbors as INTERNAL EIGRP route instead of external.

3. QBBP. Allows router to mark and apply QoS policies to packets based on BGP destination route.

   route-map route-map-name [permit | deny [sequence-number]]
    match community {standard-list-number | expanded-list-number | community-list-name [exact]}
    set ip precedence [number | name]
   router bgp autonomous-system
    table-map route-map-name
   ip community-list standard-list-number {permit | deny} [community-number]
   interface type number
    bgp-policy {source | destination} ip-prec-map

4. What happens when DR is not a hub in DMVPN?

5. When applying filter-list at OSPF ABR, direction can be somewhat confusing, so always remember that it has the following meaning: IN - filters LSA from this ABR TO the specified area, OUT - filters updates FROM the specified area to ALL other areas.

6. Prefix lists permit any 0.0.0.0/32 le 32 not be confused with 0.0.0.0/0, which is default only

7. "ip rip v2-broadcast" interface command to force RIPv2 to broadcast updates

8. uRPF with ACL. Cisco docs: "If Unicast RPF does not find a reverse path for the packet, Unicast RPF can drop or forward the packet, depending on whether an ACL is specified in the Unicast Reverse Path Forwarding command. If an ACL is specified in the command, then when (and only when) a packet fails the Unicast RPF check, the ACL is checked to see if the packet should be dropped (using a deny statement in the ACL) or forwarded (using a permit statement in the ACL)."

9. Controlling redistribution. For example, mutual redistribution between OSPF and RIP on two routers. The least elegant way is to deny OSPF routes to enter OSPF domain back at all. Another way to control redistribution is to lower AD only for routes that are native to RIP (in case 2 OSPF ASBR and RIP routers share the same subnet, it's possible to change AD only for routes that have RIP router as a next-hop. Check Cisco 360 TS lab02 for reference.). In this case OSPF routes learned from another ASBR are not denied on the boundary and can be used in case primary link to OSPF domain fails (RIP domain will be used as a transit for OSPF prefixes). To be continued.

10. Continue. When RIP routers share the same subnet (hub and spoke, for example) and spoke sends an update to the hub, hub will use the IP of this spoke as a NH in routing updates that it will send to the rest of the spokes. Applying this knowledge to Section 9, we can assume that if 2 spokes are OSPF ASBRs, that mutually redistribute OSPF and RIP, it is possible to lower RIP AD on ASBR's only for RIP updates that have hub as a NH and not another ASBR.

11. Routes recieved from confederation BGP peers are still considered iBGP with AD of 200.


12. NTP:

Client:
ntp authentication-key 1 md5 073B08616B 7
ntp authenticate
ntp server 135.15.26.2 key 1

Server:
ntp authentication-key 1 md5 081565632C 7
ntp authenticate
ntp trusted-key 1
ntp master

Another quick CCIE note

1. When influencing route AD in BGP, the syntax is:
distance NUMBER "NEXT-HOP OF THE ROUTE(subnet+wildcard)" ROUTE-MAP (that matches routes to be modified)

2. BGP backdoor command is used to increase the AD of the recieved eBGP route (the easiest way to do it). Even though network statement is used, it doesn't advertise anything. Only changes AD of recieved route locally.
network x.x.x.x mask y.y.y.y backdoor


3. To filter BGP network with extended ACL, use source field as prefix, wildcard to match different prefixes and destination HOST as prefix mask.

4. To create tunnel in vrf default that will use source interface in diff. vrf, "tun vrf NAME" command must be used.

5. NHRP mappings do not start working without specifying NETWORK-ID

6. When configuring tunnel protection, the steps are:
- isakmp policy
- isakmp key
- ipsec transform set
- ipsec profile
- tunnel protection ipsec profile

7. ipv6 EIGRP is enabled via "ipv6 router eigrp AS"

8. Redistribution is done under address-family in ospfv3

9. If filtering has to be done with route-maps in EIGRP, it is possible to match a source-protocol. For example, It means that if connected route was redistributed to EIGRP, we can match it as "source-protocol connected" on any other router (dist-list X in).

10. Sham-links must be used in MPLS VPN environment when backdoor exists between customer sites that should be used as backup only. Sham-links allows two PE routers to form an OSPF adjacency that makes it possible to exchange LSA directly so routes between sites are seen as intra-area routes. Otherwise backdoor is always preferred regardless of the cost because OSPF always prefers intra-area in favor of inter-area routes.

Important to note here is that sham-link must be created between loopback IP's that are redistributed to MP-BGP customer VRF. Adjacency will not be formed if loopbacks are advertised to OSPF because in this case recursive routing lookup might occur.

Not sure what IOS exactly checks before bringing sham-link UP, but it seems that next hop for the sham-link destination IP must be learned from BGP (show ip route vrf VPN on PE must show BGP learned route). If loopback is redistributed to OSPF only and next hop for sham-link destination is learned via OSPF then link doesn't come up.

11. In order for BGP Synchronization to work, iBGP route must not only be known via IGP but, in case of OSPF, RID of iBGP peer must match OSPF RID of the router that advertises this prefix.

CCIE Notes

A BGP speaker only assigns a label to a prefix for which it is the next hop. This is an important rule to remember when looking at the behavior of a BGP RR for vpnv4 routes. Otherwise, it just forwards the route as it is.

Route feedback

Yes, I know that this drawing is ugly. Sorry, I'm not a good artist :) Unfortunately...

Entry data:
1. Routing protocol - RIPv2
2. R1 advertises summary route on both it's links
3. S1 is a multipoint interface. R1, R2 and R3 are in the same subnet
4. Split horizon is disabled on S1

Normal network condition: R2 receives update on both links and advertises it through S1 interface back to R1 and to R3 (Split horizon is off). Next-Hop address in the update is R1's serial interface. R1 receives it's own update, check that Next Hop IP in update it's on IP address and discards it. R3 installs the summary into it's routing table with two GW as an NH - R1 and R2. Remember, that R2 advertises both routes to the summary subnet - one through itself and the other one through R1 directly.


Now, suppose, on R2's S1 interface we filter this summary inbound. Now we advertise the summary route that we received on a point to point link (S0 int) back to R1 through the S1. R1 receives it and installs it as a valid route. After several seconds it realizes that it's own route and poisons it (sends this summary to frame-relay link with metric of 16 hops). R2 receives poisoned route, then poisons it back to R1. After some time the process repeats. If we are pinging this summary from R3 sometimes we will receive replies and sometimes we will receive Unreachables (the moment the route is poisoned).

Solution - it wouldn't be a problem at all if R1 installed  a summary to Null0 to it's routing table when it advertised this summary to its neighbors.


I would like to thank INE workbooks for this interesting scenarios. I duplicate it here for future reference and memorizing the concept.