“Do you know…” Series – (General technologies issues)

I have come across some hard facts about why some of the protocols behave the way they do and I want to use this “Do you know ………..” to be tracking all these. This is more like a Question & Answer (Q & A).  As I come across them I will be adding them to this list. As time goes on, I expect this list to be long.

Please note that comments, corrections, further explanations are welcome on this thread……..

Here we go………..

Question:  Why is it a requirement in OSPF to have all other areas be either physically connected to area 0 or through virtual link or tunnells ?

What I found out about this is the fact that when you observe the behaviour of ospf ABR routers, you realised that what ABR does basically is to summarise reachbale networks within area and then generate LSA Type 3 (Summary LSA) and have this advertised to other areas.

If we reduce OSPF domain within an autonomous system to just the ABRs and their corresponding links, you will see that interchange of LSA Type 3 is done hop by hop (this is basically what happens between any area and area 0).

Hence, to ensure every ospf area has full reachability information from all othe areas, it is a requirement that every area be connected to area 0. With this area 0 has a full reachability detail and it exchanges them with all other areas within the domain.

This is kinda looks like holding daily management meetings everyday in an organisation and every department manager is required to attend and share whatever information they need to share so that every other manager in the meeting can hear it and subsequently share it with their respective teams.

Question: One-way PPP Link Aunthentication

I came across an interesting topic (that I never knew before) that ppp aunthentication does not really have to be configured on both ends of the link for it to work.

I know that for the CCIE lab, PPP encap will probably expect basically 2 types of aunthentication – CHAP & PAP. To enable this chap aunthetication type, we normally need a configuration similar to the one shown below;

•  hostname R1
  username R3 password 0 cisco
  interface Serial1/1
   ip address 10.10.10.1 255.255.255.0
   encapsulation ppp
   ppp authentication chap

 

•  hostname R3
  username R1 password 0 cisco
  interface Serial1/1
   ip address 10.10.10.2 255.255.255.0
   encapsulation ppp 
• ppp authentication chap

But the truth is that we really do not need to have ppp authentication chap enabled on both ends for this link to be authenticated prior to moving it to UP state. All that is required is to have it enabled on one end of the link as shown below.

•  hostname R1
  username R3 password 0 cisco
  interface Serial1/1
   ip address 10.10.10.1 255.255.255.0
   encapsulation ppp
   ppp authentication chap

 

•  hostname R3
  username R1 password 0 cisco
  interface Serial1/1
   ip address 10.10.10.2 255.255.255.0
   encapsulation ppp

Now the interesting part to this is that what if we get a question that says make R1 authenticate R3 with chap while on this same link, R3 authenticates R1 with pap ?

For this, all we need to do is to enable ppp authentication pap on R3 and ensure we configure ppp pap sent-usename <name> password <pass> on the R1 end under the interface config. This required because with pap, router do not sent it’s hostname with the shared password, hence this has to be configured on the remote end.

•  hostname R1
  username R3 password 0 cisco
  interface Serial1/1
   ip address 10.10.10.1 255.255.255.0
   encapsulation ppp
   ppp authentication chap
• ppp pap pap sent-username R1 password cisco

 

•  hostname R3
  username R1 password 0 cisco
  interface Serial1/1
   ip address 10.10.10.2 255.255.255.0
   encapsulation ppp
• ppp authentication pap

Question: Running multicast in hub/spoke network (Frame Relay).

One important thing not to forget is to enable ip pim nbma-mode on the hub router.

What is ODR – On Demand Routing

This is one of those vague topics in CCIE lab that I’ve never configured before and it’s quite simple. Hence I decide to talk about it here.

ODR allows routing information from hub/spoke topology to be exchanged with hub and entered into hub routing table without running any standard routing protocol.

ODR (On Demand Routing) is designed to be used in a partially meshed environment (e.g Frame Relay networks) where a hub router maintains one link each to multiple stub routers (spokes routers). Therefore, for any spoke to communicate with another spoke, such traffic must pass through the hub.

If each stub networks is simply made up of the stub router and multiple hosts (much like remote location of a corporate organisation). There is no need to run any routing protocols on the stub since all host are connected and the routes can be exchanged with hub router using odr. Hub will henceforth install the routes in routing/forwarding tables as connected routes with next-hop address of each stub respectively.

ODR uses CDP protocol that runs, by default on all cisco devices. CDP is used by cisco devices to learn & retrieve basic information about their connected neigbors. Therefore, disabling CDP on a router will also disable propagation of ODR traffic.

ODR ip prefixes information can be redistributed to other routing protocols on the hub router using redistribute command.

Operation of ODR:

1.  Enable ODR on the hub router by

Router (config)# router odr

2.  As the hub router learns the stub routes dynamically, it tries to enter them into RIB. With this, it can therefore be filtered with distribute-list command.

Router(config)# access-list 101 permit ip any 192.168.1.0 0.0.0.255
Router(config)# !
Router(config)# router odr
Router(config-router)# distribute-list 101 in
Router(config)# end

3.  Redistribute odr routes into other routing protocols.

Router(config)# router ospf 1

Router(config-router)#redistribute odr ?
  metric       Metric for redistributed routes
  metric-type  OSPF/IS-IS exterior metric type for redistributed routes
  route-map    Route map reference
  subnets      Consider subnets for redistribution into OSPF
  tag          Set tag for routes redistributed into OSPF
  <cr>

4.  Timers manipulation

ODR timers can be changed by manipulating cdp timer in global config mode or using timers basic command under router odr mode.

• Router(config)# cdp timer seconds
• Router(config)# router odr
• Router(config-router)# timers basic update invalid
  holddown flush [sleeptime]

Changing Blog site theme

Wondering if you were still in the same blog site or a different one !!

This is still the Sesano’s CCIE Blog site!

I have just changed the blog site theme as I wish to have 2 column rather than a single column that I had with previous theme.

 

L2 Security Features Part III – Dynamic ARP Inspection

Dynamic ARP Inspection

ARP inspection allows the switch to discard ARP packets with invalid IP to MAC address bindings, effectively stopping common man-in-the-middle attacks. ARP poisoning is a tactic where an attacker injects false ARP packets into the subnet, normally by broadcasting ARP responses where the attacker claims to be someone else.

 

To curtail poisoning, Dynamic ARP Inspection (DAI) uses our friend, the DHCP snooping table. There are many options, and you must be careful enabling DAI if all network devices don’t support it. The most basic configuration is:

 

    Switch(config)# ip arp inspection vlan 1

Trunk ports need to be trusted:

    Switch(config)# int range f1/1 – 4 , f2/24

    Switch(config-if)# ip arp inspection trust

You can view the status with:

    Switch# show ip arp inspection ?

 

Using the features that leverage knowledge gained from DHCP snooping can create a new level of local network security. Combine that with port-level MAC security, and network admins will no longer cringe at the thought of turning on a network connection in a public area. Testing these features in a production environment is, of course, not recommended: Many of them have wicked side effects if configured incorrectly or out of order.

L2 Security Features Part II – IP Source Guard

IP Source Guard and Port Security

Using just DHCP snooping, you have stopped untrusted devices from acting as a DHCP server; which is important in an environment where people think it’s a good idea to bring in their Linksys access point to better cover the office with wireless. Port Security can also help to stop more than one MAC from being seen on a port, making it impossible to connect hubs and other network-extending devices.

 

Now, to stop malicious people from using IP addresses that weren’t assigned to them, we use IP source guard. Even better, we can also stop clients from forging their MAC address. MAC address filtering makes flooding the switch impossible. Flooding is a technique by which an attacker sends so many MAC addresses from their port that the switch’s MAC table overflows. Then the switch has no choice but to flood all Ethernet frames out of every single port, since it doesn’t know what MAC is connected where, allowing an attacker to see all the traffic across the switch. Some viruses have been known to do this as well.

 

    Switch(config-if)# ip verify source vlan dhcp-snooping

 

But be careful! If the DHCP table doesn’t have an association for this port, you’ve just stopped all IP traffic from it. It is recommended that DHCP snooping be turned on a day before enabling IP source guard to allow it to gather information.

 

To apply MAC address security, you must turn it on, then configure appropriate options:

 

    !Set explicit access mode (dynamic or trunk ports can’t have security)

    Switch(config-if)# switchport mode access

 

    !Enable port-security

    Switch(config-if)# switchport port-security

 

    !Specify how many MAC addresses can be used:

    Switch(config-if)# switchport port-security maximum 1

 

    !Action to take when a violation happens:

    Switch(config-if)# switchport port-security violation {restrict | shutdown}

Violation Restrict will not disable the switch port, but instead cause the switch to increment a security violation counter, and send an SNMP trap. These options are quite configurable, you can even specify how long to shut down the port when a violation occurs. An alternative, less dynamic method, is to program the MAC address binding as static. This stops any other MAC from working on a port, ever.

L2 Security Features Part I – DHCP Snooping

Here is a 3-part series document written by Charlie Schluting, describing some of the L2 security features available in Cisco Switches with smart ports.

Enjoy reading this as it is covered in the CCIE exams.

 

DHCP Snooping

Using the features that leverage knowledge gained from DHCP snooping can create a new level of local network security. Combine that with port-level MAC security, and network admins will no longer cringe at the thought of turning on a network connection in a public area.

DHCP snooping is a security feature that filters untrusted DHCP messages, and can protect clients on the network from peering up with an unauthorized DHCP server. When enabled, it builds a table of MAC address, IP address, lease time, binding type, and interface information (the switch’s interface).

There is also an important difference between trusted and untrusted interfaces when talking about DHCP snooping. Switch ports connected to the end-user should be configured as untrusted. Trusted interfaces are those connected to your DHCP server or another switch. When DHCP snooping on the entire switch is enabled, the switch acts like a firewall for your VLAN (define) . You’ll also want to enable DHCP snooping on the VLAN, to allow the switch to act as a firewall for the entire VLAN domain.

Here’s how it’s done:

    !Turn on snooping for the entire switch:

    Switch(config)# ip dhcp snooping

    Switch(config)# ip dhcp snooping vlan [number or range]

 

    !Our DCHP server:

    Switch(config)# interface GigabitEthernet 5/1

    Switch(config-if)# ip dhcp snooping trust

 

    !An untrusted client (not a required step):

    Switch(config-if)# interface FastEthernet 2/1

    Switch(config-if)# ip dhcp snooping limit rate 10

A few notes on this:

First, and most importantly, you must realize that this will cause all DHCP requests to be dropped until a port is configured as trusted. Hence, this should be turned on with great care. Second, this isn’t as cumbersome as it may seem. You can use the Interface Range command to specify all trusted ports at once. Here’s how to enable trust on all trunk ports and ports that a dhcp server is connected to:

    Switch(config)#interface range FastEthernet 2/0/1 – 8 , GigabitEthernet 1/0/1 – 3

    Switch(config-if-range)# ip dhcp snooping trust

Interface range is a little-known command, introduced in IOS 12.1 that saves a tremendous amount of time.

The last caveat with DHCP snooping is that you must establish a trust relationship with downstream DHCP snoopers on a trunk port:

    Switch(config-if)# ip dhcp relay information trusted

Now, you may be thinking “DHCP snooping sounds nice, but what happens when I reboot the switch and the snooper doesn’t have a database of leases anymore? Won’t it require clients to re-obtain their DHCP leases?”

Yes. Cisco thought of this, and created a mechanism by which the database can be saved. It is possible to configure the database to live on flash memory, but because of space limitations it’s best to use a tftp server with the command:

    Switch(config)# ip dhcp snooping database tftp://10.1.1.1/file

The database is updated constantly, and should survive a quick reboot. If some DHCP leases have expired by the time the switch comes alive again, those entries will be invalid, and the client won’t have connectivity until it tries to peer up with DHCP again.

 

 

 

 

 

OSPFv2 Basics

This post will try to catch some of the important issues I ran into while labbing up the section 5 from IPExpert workbootk which is solely on OSPFv2

There was a requirement to enable authentication on a serial interface connecting R7 back-to-back with R8. Router R7 must use ipexpert as password while R8 must use IsTheBest as it’s password.

What quickly jumped at me was PPP CHAP (remember PPP is the only serial intf protocol that support authentication). But with the ppp encap enabled and ppp chap configured, interfaces failed to come up!

The catch, as I found out later, was that PPP CHAP uses a “shared” password. Hence for chap to work, the password used by both routers must be same. Hence, to solve this authentication issue, we must use PPP PAP. Here is a sample of this config;

• R7:
• username R8 password IsTheBest
• int e0/0
• ppp authentication pap
• ppp pap sent-username R7 password ipexpert  <— username/password sent to remote end.

• R8:
• username R7 password ipexpert
• int e0/0
• ppp authentication pap
• ppp pap sent-username R8 password IsTheBest  <— username/password sent to remote end.

So the point here is to know that when password used by both routers differ, then this is a candidate for ppp pap  (not ppp chap).

Now to real OSPF stuff.

-  Do you know that it is a requirement that all areas must be linked to area 0 (backbone area). Therefore, if you have areas configuration like Area0 –> Area 7 –> Area5 –> Area 100.

Area7, 5 & 100 must be linked to area 0 somehow. To achieve this, use virtual-link and configure the virtual-link hop by hop. First from area 0 to area 7, then area 7 to area 5 and lastly area 100.  Please note that there must be atleast one physical link in area 0 for a virtual link adj. to be established.  Virtual-link is configured between ABRs.

Here is an example

• R3:
• router ospf 1
• router-id 3.3.3.3
• area 5 virtual link 4.4.4.4

R4:

router ospf 1

router-id 4.4.4.4

area 5 virtual link 3.3.3.3

-  Please note that multiple areas in ospf domain can share same id and there is no requirement to link all areas with same name together with virtual link (except area 0). Virtual-links are used to connect dis-contiguous area 0 into a single area and also to link all areas to backbone area.  Another alternative for linking other areas to backbone/making backbone area contiguous is to use GRE tunnels.

-  If enabling ospf on an nbma network ( e.g Frame Relay), do not forget to change the ospf network for the serial links to match the ospf configuration. And if you do not have a full mesh VCs, remember to always configure the hub router as a DR (if the network requires DR/BDR election).

-  As we know default ospf hello timer on a broadcast network is 10secs.  A question may be written requesting ospf to send 3 hello packets within 1 secs (fast convergence).  Since the minimum configurable timer value with “ospf hello-interval” is 1, there must be another way to accomplish this…….. the way is to change the dead-timer to 1 and specify the # of hello packets to be sent in that minimal time.  This can be accomplished with command -  “ip ospf dead-interval minimal hello-multiplier 3” on interface config mode.

-  Use “summary-address” command under router ospf process to summarize external routes injected into ospf domain.  But for internal routes, use “area x range x.y.z.w/mask” address, also under router ospf process.

IP RIPv2 Basics

While labbing section 4 in IPExpert books which is devoted to testing RIP protocol.

I came accross some of these basic features that worth mentioning……

1.  It is always a good idea to disable auto-summary since rip summarizes across classful network by default.

2.  Summary address is created per outgoing interface using “ip summary-address rip” command

3.  Since RIPv2 send updates to multicast address 224.0.0.9, if a task requires rip updates not to use unicast or multicast, then the rip process will have to use broadcast (just like RIPv1). This can be accomplished with “ip rip v2-broadcast” on rip interface mode.

4.  On the other hand, if a task requires RIPv2 updates to be sent as unicast packets ONLY to rip neigbors, then you need to use neigbor command under rip process to specify the neighbor. But HERE is a catch, with neighbor command, RIPv2 still sends multcast packets ANYWAY, hence the neighbor command must be combined with “passive-interface <intf_name>” Passive-interface command disables all RIP updates being sent on that interface but neighbor still send unicast to rip neighbor.

• router rip
• neighbor 150.50.24.68
• passive-interface fa0/0

5.  RIPv2 supports both md5 & clear text authentication. This is configured by first creating key chain and then applying the key chain to a rip interface.

• key chain r2r4
• key 1
• key-string sesano
• int fa0/0
• ip rip authentication mode md5
• ip rip authentication key-chain r2r4

6.  Routes metrics (hop counts) can be modified with off-set list with acl matching the selected routes.

7.  Route filtering in RIP is commonly done with distribute-list and this can be combined with acl or prefix-list .

8.  If a secondary ip address is configured on interface, please note that RIP only advertises updates sourced from primary address.  To allow updates from secondary interface to be sent out on primary interface, disable split horizon on that interface or use “no validate update-source” on neighbor interface.

9.  RIPv2 supports 4 timers (update, holddown, invalid, flush) and out of these timers, holddown timer is not specified in the RFC (It is cisco specific).

Preparing for the Lab Exam Resource

For the CCIE lab exam, I have decided to use the following workbooks

1. IPExpert Workbook
2. InternetworkExpert Dynamips Workbook
3. Narbik’s Workbook

I believe the combination of these resources will give me enough coverage for the exams and I  intend to supplement this with Mock labs at the appropiate times.

For those who may not be familiar with Narbik’s workbook, it is a workbook that focus more on the technologies rather than throwing a full 8-hour labs at you from beginning of the book to the end. In my own opinion, it is better to build a strong knowledge in basics before attempting full 8-hours labs as you will be better prepared and also move faster.

To learn more about Internetworkexpert workbook, follow their logo on the right hand side on this page. I will share links about Narbik later.

Update on CCIE R & S Written Test

As I said in an earlier post, I passed the written last week of January.

All I can say at this point is that for whoever still working towards the written exams, the best and the most comprehensive resource for the exam is the 

CCIE Routing and Switching Exam Certification Guide by Wendell Odom, Rus Healy, and Naren Mehta

This book is quite compressed and straight to the point in explaining what is covered in the exam.

Please ensure you cover not too common features like WCCP,  VRRP, DMVPN as you may get atleast 1-2 questions from each of these areas.

Also generally, a thourough knowledge of how routing protocols (especially EIGRP, OSPF) works is important as there are many tricky question to test these things. Need to know things like when EIGRP uses multicast/unicast to communicate with neigbors and EIGRP Feasible Distance (FD) calculations or that OSPF will always prefer internal routes in an area to external routes.

Talking about books, I also found the Doyles (Routing TCP/IP vol I & II) to be a good companion to the Odom’s book mentioned above.

Lastly, there are some good test engines out there that really gives you pass rate guarantee, if you really need some of these test engines that will get you the marks, please send me an email and I will be delighted to provide you their information.