Wednesday, May 13, 2015

What's next

After passing CCIE exam, I felt kind of lost for some period of time, during which I was coming up with different ideas about what to do next and some of them were so fundamental that it would take many months if not years to tackle them fully. This post's main target is to list all topics that interest me and try to layout my plan of tackling them.

How it all began....

I was going back and forth between CCIE SP, VMware NSX, CCDE, Python, Ansible and the likes.

Unfortunately, our time is always limited, so you have to prioritize. I decided to make a list of technologies that I would like to expand on and here it goes:

  1. CCIE SP. Honestly, I would not call this exam super exciting but I need to know these topics for CCDE, so I will pass it as a part of my CCDE studies.
  2. CCDE. This is what really interests me. When I began my CCIE studies, I truly believed that CCIE knowledge makes you a God of networking. What a shameful misconception! I was getting closer and closer to the exam and realized something more and more: CCIE doesn't bring you to the heaven of networking. CCIE engineer can simply translate what he has been told by an architect into CLI commands, but he doesn't necessarily understands why this particular technology was chosen. What were the business requirements? Why IS-IS was chosen over OSPF? When do you need to use this particular protocol? And this is what CCDE brings to the table. In fact, the next day after I passed CCIE, I was jumping like crazy because I had set myself new target - CCDE. That is my next try of getting closer to the heaven of networking.
The topics mentioned above will be the core of my studies. Plus, in parallel I will do my research on:
  • Ansible
  • VMware NSX
Out of all these topics, NSX deserves a few more words. Once I was done with CCIE RS (e.g. mastered DHCP on legacy IOS, you know), I was very excited to learn about VMware NSX. And their certification that allows you to pass VCIX-NV bypassing all pre-requisite exams if you hold CCIE DC or RS. I've started to play with it and was impressed by it's capabilities, but...doing everything via GUI just...feels so unnatural and inefficient for me (sorry Windows guys). So I guess I will put VCIX-NV on hold for some time, while I'm doing stuff that really moves me: network automation. That said I will focus on Ansible and of course my great friend Python.

Sounds like a plan.

Thursday, April 30, 2015

CCIE tips

This week my exciting journey to CCIE R&S ended in Toronto. I passed the lab on my first attempt.

As always, I want to share what I believe is important to successfully pass CCIE lab. This time I'm not going to talk about technical part. Enough was said by many people. Contrary to that, most of the time CCIE candidates miss one very important part of the exam - mental preparation and physical health.
No, I'm not going to give you advice to go to the gym instead of spending hundreds or thousands of hours in front of CLI, but here is what I trust is important:

1. Align your preparation schedule with the lab time.

For the past 3 months, every single weekend at 7 am I have already been sitting and doing mock troubleshooting labs. And yes, weekdays also. Your body has to be ready to think and act fast early in the morning. Troubleshooting was by far the most difficult part of the lab for me as time was very limited, GUI was unknown, etc.

2. Sleep well. Don't be exhausted when the lab time comes.

3. Use secret weapon - ear plugs. I took mines to the lab and the proctor allowed me to use them no problems. I was so grateful I didn't forget them at home, they helped me to concentrate more easily (in fact, earplugs were the first thing I packed to my backpack before going to Toronto! :)).

4. And the last but not least - get support from your family. Talk to them, explain the importance. Intensive CCIE studies is a very hard time for everybody, including your loved ones. Especially it applies to people with kids like me. My wife and 2 daughters agree :)


Dream, study, win!


Igor

Monday, September 15, 2014

Note

1. EIGRP Add-path
By default, all EIGRP interfaces have next-hop-self configured. Even in a hub-and-spoke topologies, hub will advertise its own IP as a hext-hop for the routes that were received on the same interface from other spokes. This behavior interferes with add-path capability and must be turned off in order to use add-path.
Add-path is only supported in NAMED EIGRP mode.
Variance should not be configured on the hub when add-path is used.

Configuration:
router eigrp virtual-name
 address-family ipv4 autonomous-system as-number
  af-interface {default | interface-type interface-number}
   no next-hop-self [no-ecmp-mode]
   add-paths number

4. VRF route leaking
It's possible to leak routes between VRF's DEFAULT and NON-DEFAULT using static routes.
However, BGP must be used to leak routes between two non-default VRF's.

5. Loopguard should be on all root and alternate ports (non-designated)

6. Etherchannel misconfig guard - checks if the source mac from lacp and bpdu packet is the same on all physical links

7. EIGRP FRR
router eigrp virtual-name
 address-family ipv4 autonomous-system autonomous-system-number
  topology base
  fast-reroute per-prefix {all | route-map route-map-name}
show ip eigrp topology frr

8. Wide metric works only in NAMED EIGRP mode

9. Regexp
+ matches any preceding character ONE or more times
* matches any preceding character ZERO or more times
? matches zero or one occurrence of the pattern

10. NAT
When NAT'ted IP is on the external directly connected network (outside interface) but it's not the same IP as the one of the interface, router must send ARP replies for the NAT'ted IP in order for return packets to reach router. This feature is called alias IP.
No-alias keyword can be used along with NAT statement in order to disable ARP replies from the router for the NAT'ted IP. It is useful when there is a dedicate subnet for NAT pool and routing is used to send packets to the router by its neighbors.

11. Multicast PIM sparse-dense mode with auto-RP

- ip multicast-routing
- Then enable PIM on interfaces: ip pim sparse-dense-mode (to check "show ip pim neighbors")
- Create loopback and associate it with multicast group: ip igmp join-group x.x.x.x
- Enable PIM on the loopback: ip pim sparse-dense-mode
- Configure Auto-RP
ip pim send-rp-announce Loopback1 scope N
ip pim send-rp-discovery Loopback1 scope N

Note that if PIM sparse-mode is used then "ip pim autorp listener" global configuration command must be used

12. OSPF timers tunning: "timers ...." router configuration command

13. Tunnel interface can be in Global VRF but using source interface in different VRF. To achieve this command "tunnel vrf NAME" command must be used. In this case tunnel IP will be in a global routing table, but transport IP will be in separate VRF.

14. Tunnel traffic can be forced out of particular interface by specifying "tunnel route-via Interface mandatory" command.

15. OSPF Fast-Hellos. Interface configuration command:  ip ospf dead-interval minimal hello-multiplier 5

16. OSPF area transit capability is the ability of the area to carry data traffic that neither originates nor terminates in the area itself. This capability enables the OSPF ABR to discover shorter paths through the transit area and forward traffic along those paths rather than using the virtual link or path, which are not as optimal. Router configuration command "no capability transit".

17. OSPFv3 prefix suppression mechanism alloSource IP of the ACL must match next hop (not router-id!) of the route and destination part must match route.ws to suppress transit networks (directly connected from OSPF routers perspective) from OSPF advertisements.
Router ospf address-family configuration: prefix-suppression. Or interface configuration: ipv6 ospf prefix-suppression.
By default, secondary and loopback IPs are not suppressed. As well as passive interfaces (since they are connected to the edge networks that must be advertised!).

18. Dynamic BGP Neighbors:
 bgp listen limit 200
 bgp listen range 172.21.0.0/16 peer-group group172 
 bgp listen range 192.168.0.0/16 peer-group group192 

19. BGP Soft  reconfiguration and route refresh. Soft-reconfiguration must be enabled on per-neighbor basis and basically tells the router to store a copy of Adj-RIBs-In table in the memory. Route refresh is a capability of the router to request/re-send all the routes as needed. In other words, soft reconfiguration works locally, where route refresh is a capability of two neighbors to understand "route refresh" messages.

20. VRF routes leaking. In order to leak route to/from global routing table from/to VRF, export/import command must be used under vrf configuration. Export map can set extended community values to routes (RT values, for example). Also, "import map" can be used to import routes not only based on RT but also any specific parameter (community, for example)

21. Export maps. Route map specified in an export map matches routes that needs to be modified. Routes that are denied by the route-map are not denied from being exported, they are just not modified!
http://www.networking-forum.com/viewtopic.php?t=29464

22. Few words about IPSec.

Case 1: No GRE tunnel.
a. crypto map must be used to set peer address, TS, and ACL for interesting traffic.
b. ACL must match every source and destination that must be encrypted.
c. Tunnel mode must be used in TS.

Case 2: GRE tunnel.
a. ACL should match only endpoint IPs of the tunnel (external IPs, tunnel source and destination).
b. TS mode should be set to transport since GRE has it's own IP header.
c. There are two ways to enable IPSec for tunneled traffic:
    - "tunnel protection" method. In this case there is no need in crypto maps. Instead, "crypto ipsec profile" should be used along with "tunnel protection" tunnel interface command.
    -  crypto maps. In this case protection is applied to a physical interface with "crypto map NAME" command. Peer for crypto map ""set peer" must be set to an external IP of the peer (tunnel destination), not tunnel IP (very easy to make a mistake)!  ACL for interesting traffic should match only external IPs of the peers (tunnel source and destination).

23. Key facts about DMVPN:
a. Phase 1 - all spokes have p-t-p tunnels and communication is done only via hub.
Phase 2 - all tunnels are multipoint. Dynamic tunnels established as needed.
b. ip nhrp network-id MUST be configured in order for NHRP to work.
c. Split-horizon must be disabled for all distance-vector protocols (RIP, EIGRP).
d. Next-hop-self must be disabled for EIGRP in Phase 2.
e. OSPF point-to-multipoint network should be used in Phase 1.
f. OSPF broadcast network should be used in Phase 2.
g. In order for multicast to work properly, "ip nhrp map multicast OUTER_IP" is required. On hub it is specified as "ip nhrp map multicast dynamic"

24. In DVTI networks, all tunnel interfaces MUST be unnumbered to a loopback IP. When interfaces are unnumbered, ospf advertises host routes for each loopback IP. Without host routes, OSPF DB is populated but routes are not installed into the RIB.
25. Virtual link is an extension of Area 0, so if lab requires area 0 to be authenticated, it applies to virtual-links also.
26. Nested policy-maps.The requirement is to limit the bandwith for the packets having network X in source from consuming more than 5kb/s. At the same time packets having network X in source and having ip precendence from 0 to 2 must be given 3 kb/s. Packets having network X and precendence 1 (note, it falls into the range betweeen 0 and 2) must be policed to 1kb/s.
Configuration.
First, ACL must be created to match the network.
Then, 3 class-maps will be created:
- First will match only source network.
- Second matching network and range of precedences.
- Third, the most specific, matching network.
Last thing to do is to create nested policy-maps going from the most specific to the least specific. On each next level we will include previously created policy.
class-map 1 <- br="" least="" specific=""> match network X
class-map match-all 2
match access-group ACL
match ip precedence 0 1 2
class-map match-all 3 <- br="" most="" specific=""> match access-group ACL
match ip precedence 1
Policy-map 3 <- br="" most="" policy-map="" specific=""> match class-map 3
police 1000
Policy-map 2
match class-map 2
police 3000
service-polcy 3 <- nested="" p="" policy-map=""> Policy-map 3 <- br="" least="" policy-map="" specific=""> match class-map 3
police 5000
service-policy 2 <- nested="" p="" policy-map=""> Logic: Police the large chunk of packets to 5kb/s, then from this group take more specific part and police it to 3kb/s. Lastly, from the second group take another one, which is the most specific and police it down to 1kb/s.
27. Configuring burst if it is given in ms (time value).
Burst bytes = time in seconds * target rate (in bits) / 8
28. RPF for multicast. Outgoing interface to reach unicast source IP of multicast traffic must match the interface where multicast comes from.
29. If non-broadcast OSPF network type is used and only one router must be DR with no BDR, then neighbor statements must be used only DR. All spokes do NOT require neighbor statements. Priority should be set to 0 on spokes.
30. NAT port forwarding.
ip nat inside source static LOCAL GLOBAL
31. OSPF NSSA
      B
     /  \
A--     --D
     \  /
      C
Assume that B and C are ABR's, subnet ABC is in area 0 and subnet BDC is in NSSA 30. NSSA ABR with higher router-id translates all type 7 LSA's from NSSA area to type 5 LSA's and advertises them to a backbone area. Now, assume that D advertises external route X to NSSA area.
Problem. What should be the next hop for route X on A? B? or C? or both?
In fact, if we check OSPF DB on A, we will see that X is advertised only from B. Regardless of that fact, the next hop for X on A is both B and C!
32. Distribute list for OSPF intra-area routes using ACL.
Source IP of the ACL must match next hop (not router-id!) of the route and destination part must match route.
33. "show ip route X" is a very usefl command when checking route source (don't confuse it with NH!)
34. OSPF External Routes. E1 is always preffered over E2 even if latter has lower metric. Internal OSPF cost to ASBR is still considered even in case of E2 routes. This is only a case when both E2 routes get equal metric during redistribution.
35. DMVPN Phase 3 is used to create "data plane shortcuts" even though NH in a RIB points to a hub. OSPF can use point-to-multipoint in this scenario and there still will be a traffic between spokes because NHRP will override CEF entries.
36. RIP doesn't have "ip next-hop-self" feature of EIGRP. In hub and spoke topology, RIP will always send updates for spokes networks with spoke as a NH EXCEPT the case when auto-summary is enabled. If RIP is summarizing one of the spoke's networks on a classful boundary, it will put itself as a next-hop (even if the network was originally Class C with /24 mask, it will advertise it as the same class C network with /24 mask to the neighbor on class A network but it will put itself as a next hop! In this scenario summarization cannot be seen in the RIB of the spoke because the subnet still has /24 mask but next hop will be hub!) It essentially means that if spoke's network point to the hub in hub and spoke topology, it means that hub performed summarization on a classful boundary!
37. Route manipulation:
-Distance
"distance N SOURCE ST_ACL". Source is specified right in the command without the use of ACL, etc. Source must be advertising router, not NH. Only standard ACL can be used to filter prefixes.
-Distribute-list
Distribute list can use following options:
"distribute-list ST_ACL" - Deny statements match prefixes to be denied and permit any at the end to permit the rest.
"distribute-list EXT_ACL" - Source IP must be in form of host that matches NH of the route, destination is prefix. Deny to deny prefix with particular NH, and permit...to permit.
"distribute-list gateway PR_LIST" - Every route with NH specified in PR_LIST with deny statement are filtered.
"distribute-list prefix PR_LIST1 gateway PR_LIST2" - All updates with NH specified with DENY statement in PR_LIST2 are filtered, the rest can be filtered with deny statements from PR_LIST1.
"distribute-list route-map NAME in".
#From my tests with 12.4, filtering by both prefix and route-type doesn't work if combined in a single route-map (maybe it's not possible to filter by specifying different attributes in a single route-map).
For different types of filtering to work together in one route-map theu must be separated in different permit/deny clauses unless you want to match several parameters at the same time:
route-map RM deny 10
 match route-type external level-2
route-map RM deny 15
 match ip address prefix-list try
 match metric 11
route-map RM permit 20
ip prefix-list try seq 5 permit 192.168.1.1/32
Previous route-map filters all E2 routes, all routes that (a.) permitted by "try" prefix-list AND (b.) have OSPF metric of 11. All other routes are permitted by clause 20.
---
Filtering by NH doesn't work with prefix-list in route-maps in 12.4 (have to test on 15.3). ACL's work fine.
---
Filtering by network prefix works for both PL and ACL.
---
Filtering by route-source (advertising router) works the same way as by NH (e.g. prefix-lists do NOT work). Note: I could NOT filter external prefix with this command.
---
#applies to both NH, prefix and route-source filtering: What's interesting is that route-map is used differently here compared to usual use cases. First statement is PERMIT and what must be filtered is specified within the matching clause (for example, deny in ACL will deny the prefix. ACL is used to determine what is filtered and what is not instead of just selecting "interesting" matches that will be permitted or denied by route-map itself)
---
Filtering by route-type works either by : (a.) RM permit clause specifies what should be permitted and everything else is blocked (b.) RM deny clause specifies what must be filtered and then permit clause permits everything else (without a match statement)
---
Filtering by metric works smoothly
---
38. Inter-area route filtering on ABR:
Method 1: Filter the inter-area routes generated at ABR
router ospf 1
 area 10 filter-list prefix in NAME

Method 2: Filter out intra-area routes
router ospf 1
 area 10 range 1.1.1.0 255.255.255.0 no-advertise

Method 3: Filter inter-area routes learned by ABR from Area 0
router ospf 1
 distribute-list 1 in
39. External route filtering:
Method 1:
router ospf 1
 distribute-list 10 out rip
!
access-list 1 deny 1.1.1.0
access-list 1 permit any

Method 2:
router ospf
 redistribute rip route-map RIP_TO_OSPF
!
route-map RIP_TO_OSPF
 match ip address 1

Method 3:
router ospf
 summary-address 10.0.0.0 255.255.25.0 no advertise

40. OSPF area summarization (or just new Type-3 summary LSA creation) is done via checking RIB table, not LSDB and applies ONLY to routes that are internal to the area! And it's done BEFORE "distribute-list in" command is applied, so summary LSA will be generated even if there is no corresponding more specific route in the RIB (have to check if it applies to "area range" or to any type-3 LSA being created).
41. OSPF inter-area (IA) routes caNOT be summarized by "area range" command.
42. When ABR re-generates summary LSA received from area 0 (origin is any other area) for its directly connected area, it is doing so AFTER applying "distribute-list" filter. Same way it's done for intra-area summarization, it checks RIB instead of LSDB when it performs re-generations of summary LSA's. It means that if IA routes are filtered from getting into the RIB on ABR, they will not be propagated past that ABR!
43. [OSPF] If hub is not DR, it becomes adjacent with DR only and the state of the rest of the spokes is 2-WAY. However on spokes it looks like they are adjacent with hub and the state is FULL. Essentially, it means that hub will install the routes only advertised by the neighbor it thinks it is adjacent with. On all other spokes LSDB will be empty.
44. [RED] When redistributing external eigrp to ospf on two routers, AD for OSPF ext routes must be increased. Otherwise one the routers will prefer route via OSPF domain of EIGRP to EIGRP exit point.
45. [ROUTE_MANIPULATION, EIGRP, OSPF] Command "distance X ROUTE_SOURCE ACL" can change AD for any OSPF route but for EIGRP it changes AD of internal routes ONLY.
46. [OSPF, NSSA] NSSA area has two (2) ABRs. Command "area X nssa no-summary no-redistribution default-information-originate" is configured on one ABR and "area X nssa default-information-originate" is configured on the second ABR. Router in NSSA area (connected to NSSA area only) will see only one (1) default route instead of two from both ABR's as one might think! And the reason why is because both ABR's inject default route in form of Type-5 LSA because of "default-information-originate". However, only one (1) of them also inject default route in form of Type-3 LSA (no-summary) and it is always preferred! O-IA-E1-E2-N1-N2.
Summary Net Link States (Area 30)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 10.1.1.1 66 0x80000001 0x006409

Type-7 AS External Link States (Area 30)
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 10.1.1.1 155 0x80000001 0x0038B0 0
0.0.0.0 10.1.1.2 559 0x80000009 0x0022BD 0

47. [OSPF, NSSA] Same topology as was described above. After deletion of "no-summary" keyword on ABR, two (2) defaults are injected into NSSA area. On NSSA internal router I wanted to change distance for one of the defaults to make it less preferred. Oddly enough, when I matched the ABR that performs LSA7-to-5 translations in my "distance X ROUTE_SOURCE ACL" command, it didn't take effect at all! However, when I matched the other ABR (one that doesn't do translations), AD for both defaults was changed on the router. Looking at LSDB, I see that both defaults are advertised by different routers (see output above). The best solution was to change metric on ABR instead of changing AD on receiving router. "area X nssa def-inf-or metric X" command was used.
48. [L2, VTP] For VTP transparent mode switch to forward VTP updates received on trunk ports, it must be configured with the SAME domain name as all other switches in VTP domain.
49. [L2, VTP] When transparent switch is placed in the middle of VTP domain, it might create data-plane black-holes, since VLAN's will be created on the leaf nodes, but not on the transparent switch.
50. [L2, VTP] When pruning is enabled in VTP domain and than one of the switches is connected by a trunk port to a device that doesn't support VTP, it will request ALL VLAN's from VTP neighbors.
51. [L2, DTP] Port that is in trunk mode still runs DTP. It means that if on the other side port is in dynamic auto mode it will still negotiate trunking. Dynamic auto/auto doesn't actively negotiate trunking.
52. [L2, DHCP_SNOOPING] DHCP Snooping on IOL works only with "no ip dhcp snooping information option"
53. [OSPF] When there is a p-t-m nbma network configured between a bunch of routers, ALL of them must configure "area X range" command for host routes to be suppressed out of the area. It must be done on all routers, not only on ABR's.

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


Friday, August 29, 2014

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