Notes on VRP Config Guides

It's funny to see how Huawei VRP CLI tries to convince us that it's really-really not IOS CLI. And, sadly, it does that in a pretty inconvenient way.

F.ex. "display" instead of "show" and "undo" instead of "no". If shortcuts "di" and "un" won't work, I'll be mad... Hopefully they have command aliases so that I'd be able to customize the CLI in a more familiar way.

Though they have a feature of assigning commands to keyboard shortcuts. Smth like Ctrl-G for "display running-configuration" or Ctrl-T for "display route-table" (I don't remeber exactly, but you've caught the idea, eh?). Seems rather convenient. I don't remember such a thing in IOS. There are only a few shortcuts available (kind of 5 or 7), but nevertheless... Something like that could be of great help in CCIE lab, for example. I only hope that it's accessible in any context (or view, as VRP calls them).

Our pack of Huawei devices hopefully will be deployed in August. Let's wait... Currently reading lots of Config guides, product descriptions etc. Let's hope that they'll provide some gear for testing. I need some hands-on experience before diving into full-featured maintenance of a live network.

MCSE - Minesweeper Consultant Solitare Expert

Studying HOWTO

Config guides quick link

http://www.cisco.com/en/US/products/ps6350/products_installation_and_configuration_guides_list.html

Notes on OSPF

Hmm, despite all the guidelines from Cisco's curriculums about OSPF obligatorily having area 0, it isn't the whole truth.
Today I wondered - can OSPF actually live without backbone aka area 0. In a design sense the answer is "yes", one can dump all his routers into 1 area. But I've thought about a possibility of, maybe, ABR going down or something equally awful :)
And some research on that matter proved that in fact it can be so. Area 0 is mandatory for multiarea deployments, though, because all the inter-area routes need to go through backbone. To be a bit more technical - LSA types 1 and 2 are exchanged, but types 3 to 7 need a functional link to area 0.

Some proof to back up my words - a case study from Cisco

BTW, in order not to fire up composing window once more, a list of common OSPF LSA types:

1 - Router LSA (O). Intra-area routes, generated by all OSPF routers. Flooded only within an area.
2 - Network LSA (O). Generated by DR for a multi-access segment. Intra-area type.
3 - Summary LSA (O IA). Generated by ABR, flooded to it's connected areas.
4 - Summary LSA (O IA). These are special summary LSAs generated by ASBR's area ABR's to tell everyone about his whereabouts.
5 - External LSA (O E1/E2). Generated by ASBR, contains routes external to OSPF domain. Type 1 metric is increased with on every hop, Type 2 remains the same as originally advertised.
6 - Multicast LSA. Used to indicate multicast group membership in MOSPF.
7 - NSSA LSA (O N1/N2) - Same as type 5, but, due to NSSA area preventing circulation of type 5 LSAs, it is in fact type 5 one, but differently named. ABR converts these into proper type 5 on area boundary and injects them into backbone.

And now a little bit about OSPF areas.

1. Common area - permits all LSA types, except 7. Areas with virtual links in them should be common areas. It requires no special configuration.
2. Stub area - doesn't permit type 5 LSAs. Neither in, nor out. Instead of it the default route is injected by ABR. All the internal routers and ABR must be configured for stub area. In fact, stub area flag set/unset in hellos for both peers is one of the criterias for OSPF adjacency establishment.
3. Not-so-stubby area - for all counts a stub area, but with one little addition. It permits type 7 LSAs to be passed from an ASBR. All routers in an area should be configured for an NSSA.
And now - Cisco's proprietary extensions:
4. Totally stub area - same as stub area, but taken further. It even doesn't permit type 3 and 4 LSAs, so an ABR only passes a default route to backbone via himself. Routers in an area have regular stub flags, but additional no-summary command is passed to an ABR area statement. So, it can be configured in vendor-heterogenous environment, with only ABRs needing to be Cisco.
5. Totally NSSA - see NSSA+totally stub. LSA types 1,2 and 7.

That's it for today. There are also types 8 through 11, but so far I haven't encountered any mention of their functions and specifics in my study materials. Type 8 has smth to do with BGP and 9 through 11, opaque LSA are used for MPLS/OSPF interaction.

Единственной кодировкой должна быть UTF-8, а использование других следует приравнять к разжиганию межнациональной розни и карать соответствующей статьёй УК.
http://ibash.org.ru/quote.php?id=9354

Целиком и полностью, яро и пламенно +1.

BGP Path Selection

0. Synchronized - TRUE>FALSE - there must be confirmation from someone other than BGP for internal routes.

1. Weight(O,N) - Highest - admin override, proprietary
2. Local preference(W,D) - Highest - almost same as weight, but standard and for AS
3. Self-origin - TRUE>FALSE - own paths are better
4. AS-Path(W,M) - shorter routes with less hops are generally better
5. Origin(W.M) - i < ? - Stable routes are better
6. MED (Multi-exit Discriminator)(O,N) - Lowest - for external peers, to prefer some path into AS
7. External - EBGP
8. IGP cost - Lower -
   
9. EBGP Peering - Oldest - more stable and time-proven routes
10. RID - Lowest - Last resort :)