Basic OSPF packets

Lets consider this

R1(fa0/0)------R2(fa0/0)

when OSPF protocol is configured only on R1 via "router ospf"  it joins multicast groups 224.0.0.5 and 224.0.0.6 check via

R1#sh ip int f0/0 | in Multicast

  Multicast reserved groups joined: 224.0.0.5 224.0.0.6

Now if other router R2 on this link is not running OSPF it will not join these multicast groups check on R2

R2#sh ip int f0/0 | in Multicast

R2#

So when R1 sends OSPF packets to R2 at multicast destination address of 224.0.0.5 with ip protocol ip 89 check on R2 via

R1#debug ip packets details

*Mar  1 00:17:45.907: IP: s=10.0.0.1 (local), d=224.0.0.5 (FastEthernet0/0), len 76, sending broad/multicast, proto=89

Since R2 does not have layer 2 multicast address corresponding to Layer 3 multicast address 224.0.0.5 because R2 has not joined this group (OSPF is not enabled ). Therefore when these packets arrived on R2's layer 2. It will discard all these packets at this layer. Hence no packets will be shown at layer 3 via

R2#debug ip packets details

R2#

Conclusion: OSPF packets will not be received at R2's network layer 3 because they were already being discarded at R2's layer 2. 

802.1q trunk native vlan concept

IEEE 802.1q trunk has the concept of native vlans. The standard also provides less overhead to the ethernet frames (just 4 bytes) by shim vlan tag compare to Cisco's ISL (26 bytes) which encapsulates the entire frame and adds new CRC trailer.

So what is native vlan, and when do i use it ?

Native VLAN is relevant only when there is 802.1q trunking between switches or a switch and a router ( in case of router on stick). Native VLAN has no significance when ISL trunking is used OR all vlans are tagged.

In 802.1q trunking each frame is being tagged by 4 bytes field in the ethernet header and before IP header (assume IP traffic). The 4 bytes tag field contains vlan number (12 bit), 3 bit field for layer 2 QoS, TPID (16 bits) field in order to identified the tagged frame(this is set to 0x8100 for 802.1q) etc.

The native VLAN does not have the 4 bytes tag in the frame. When one switch sends native vlan traffic to the other switch over the 802.1q trunk, the receving switch must also have same native vlan configure in order to accept the native vlan from other switch. If the receiving switch has different native vlan than what it is receiving in that case this switch may leak the received native vlan traffic in to its own native valn traffic. Switches have protection mechanisms in order to prevent this to happen by throughing error messages saying "native vlan mismatch" these error came out because negotiation of native vlan between the switches is a part of DTP and CDP. If these two protocols are disabled this error message will not appear but traffic can still leak. However there is a special mechanism in STP which brings ports in blocking state (*PVID_Inc) if native vlans are mismatched. It show this errors
%SPANTREE-2-BLOCK_PVID_LOCAL
%SPANTREE-2-RECV_PVID_ERR
STP moves these ports out of blocking states as soon as vlans are tagged on both sides using vlan dot1q tag native global command. However CDP will still shows native vlan mismatch but traffic will flow as normal because now all vlans are tagged and native vlan has no significance in that case.

By default VLAN 1 is the native VLAN in CISCO switches and can be configured to any vlan as native. It is normally used for management traffic.

if a device on the path does not understand untagged frames, Native VLAN should be disabled. To do so, use the VLAN dot1q tag native global command which will affect all trunk ports and cause Native VLAN frames to be tagged. 

Now enough theory lets try this

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiov9b41D7P8B1OiS_9g9TPUtpRzaxD850ZEgUtTy7IchaX-PQFt0wS7EhWLVIGV96dsDT9jX78yfv9QhI_cm7cNiEUzkKNtJnQ_ypBaqoMlW1IsewIK8Wm6USRmwIT_na9-fDEN6smYAM/s1600/Native+VLAN.PNG

!

!

!

!

Answer goes something like this

RIPv2 Authentication

Needs to remember couple of points in RIPv2 Authentication and RIPv1 does not have any authentication.

Question: Does key number has to match in key chain for RIPv2 authentication?

Answer: No, if its a clear text authentication. But YES if its MD5 authentication in this case 

router applies a hash functions on Key number + key-string and matches this hash output from the other side hash output value.

When configuring key-string make sure that there is no space present after key-string. Check this by "show key chain" command.

Maximum DLCIs on an interface

Lets directly take this old question but old is gold

Question: What is the limit of Maximum DLCIs configured on a Frame Relay Interface ?

It depends on the LMI type you are using so the formula comes out to be 

The maximum number of DLCIs assigned on an interface by LMI are = (MTU - 13)/8 when LMI is CISCO  OR = (MTU - 13)/5 when LMI is ANSI or Q933a

This is because Cisco LMI provides more overhead(8 Bytes) in the packet as compare to LMI type ANSI or Q933a overhead (5 Bytes) in the packet to accommodate DLCIs information.

For reference:
http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a0080094183.shtml
http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a008014f8a7.shtml#dlcilimit

RIPv1 and RIPv2 Explained

RIPv1 is completely out of the exam. However to understand other protocols in better way its a good idea to built a base.

Question: How does RIPv1 transmit updates?

RIPv1 sends its update at every 30 seconds as UDP broadcast (255.255.255.255) on port 520 to all of its connected links where RIP is enable.

The following are the important fields at each layer in the RIPv1 updates.

Ethernet Layer (If updates are exchanges on multiaccess media like ethernet)

Source mac address: mac address of the interface sending the updates

Destination mac address: FFFF.FFFF.FFFF

Type: 0x800 (as next header is IP)

IP Layer

IP Protocol No. 17 (for UDP at the Tansport Layer, next header)

Destination IP Address: 255.255.255.255 (for Broadcast address)

Source IP Address: address of the interface from where router is origination updates

Transport Layer

Source UDP Port: 520

Destination UDP Port: 520

Application Layer

RIP version

Metric (1-16)

Routes max of 25 per update: To keep size of UDP packet less than 512 bytes( this is due to the fact that UDP doesnot have MTP path discovery like TCP so as per the TCP/IP protocol suit recommendation we keep UDP packet less than 512 bytes)

Question: Is it same for RIPV2 right ?

RIPv2 sends its updates as multicast (ip address 224.0.0.9) instead of broadcast in RIPv1. Now in this case the RIPv2 updates are only processed by RIP enable interfaces as oppose to RIPv1 where these packets are processed by all the routers on the link.

In RIPv2 Just replace Multicast address with broadcast address in IP layer as well as Ethernet layer for RIPv2. And everything is remained same for RIPv2

A side note: RIP v1 only supports classful address and does not support varable length subnet masking which RIPv2 does

A basic point in Redistribution

When a multiple protocols are running on a single router and there is a need to mutually redistribution, one important point needs to remember.

When Protocol A is redistribute into Protocol B and Protocol B redistribute into Protocol C on a single router that does not mean that Protocol A is also redistribute into Protocol C therefore to achieve this we need to manually redistribute Protocol A into Protocol C.