Friday, September 5, 2014

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