notes: PPP Half-Bridging

- When a serial interface is configured as a PPP half-bridge, the link to the remote bridge functions as a virtual ethernet interface, with the serial interface functioning as a node on that remote network.
- When a packet is received by the PPP half-bridge, it is converted to a routed packet and forwarded normally.
- The reverse process happens for packets destined for the remote bridge.
- An interface cannot function as both a half-bridge and a bridge.
-----------
COMMANDS
-----------

Enables PPP half-bridging for IP (Must be done before configuring the IP.)

interface Ethernet0
ppp bridge ip
encapsulation ppp
ip address 10.1.1.2 255.0.0.0

- Provides a protocol address on the same subnetwork as the remote network.

example config guide:

http://www.cisco.com/en/US/tech/tk713/tk507/technologies_configuration_example09186a0080093c80.shtml

notes: PPP over Frame-Relay (PPPoFR)

- Frame-relay does not natively support features such as authentication, link quality monitoring, or reliable transmission.
- By implementing PPPoFR, authentication of frame-relay PVCs can be implement, or multiple PVCs could be binded together using MLP.
- PPPoFR is configured through the use of a virtual-template interfaces.
- A virtual-template is a PPP encapsulated interface that is designed to spawn a “template” of configuration down to multiple member interfaces.
- When using a virtual-template interface it’s important to understand that a virtual-access “member” interface is cloned from the virtual-template interface when the PPP connection comes up, therefore the virtual-template interface itself will always be in the down/down state. This can affect certain network designs such as using the backup interface command
on a virtual-template.


note: the oly way to do authentication over FR is through PPP.

CONFIG-SET: PPP over frame-relay (PPPoFR) example
+---------------------------------------------------

STEP1: Create the virtual-template interface
- Configures all the logical options like a IP address
- Authentication is optional
NOTE: "encapsulation ppp" not needed as virtual-templates always runs PPP

interface virtual-template1
ip address 192.1.7.6 255.255.255.0
ppp chap hostname ROUTER6
ppp chap password 0 CISCO


STEP2: Configure the physical frame-relay interface and bind the virtual-template to the frame-relay PVC
Note that the order that these steps are performed are important

interface Serial0/0
encapsulation frame-relay
frame interface-dlci 201 ppp virtual-template1


verification:

sh ip interface brief | include 192.1.7.6
virtual-access1 192.1.7.6 YES TFTP up up
virtual-template1 192.1.7.6 YES manual down down

notes: PPP Multilink PPP (MLP)

- MLP provides a method for spreading traffic across multiple physical WAN links while providing packet fragmentation and reassembly, proper sequencing, multivendor interoperability, and load balancing on inbound and outbound traffic.
- MLP fragmentation sends the fragments simultaneously over multiple point-to-point links to
the same remote address.
- MLP can measure the load on just inbound traffic, or on just outbound traffic, but not on the combined load of both inbound and outbound traffic.

CONFIG-SET: MLP - Configuring a Multilink PPP Bundle
+-----------------------------------------------------
interface s0/0
no ip add
encapsulation ppp
ppp multilink
multilink-group 2
!
interface s0/1
no ip add
encapsulation ppp
ppp multilink - Enables MLP on S0/1
multilink-group 2
!
interface multilink2
ip address 192.168.0.1 255.255.255.0
ppp multilink
multilink-group 2


LFI (Link Fragmentation and Interleaving)

- Interleaving on MLP allows large packets to be multilink encapsulated and fragmented into a small enough size to satisfy the delay requirements of real-time traffic; small real-time packets are not multilink encapsulated and are transmitted between fragments of the large packets.

- The interleaving feature also provides a special transmit queue for the smaller, delay-sensitive packets, enabling them to be transmitted earlier than other flows.

- Interleaving applies only to interfaces that can configure a multilink bundle interface.

- WFQ on MLP works at the packet level, not at the level of multilink fragments.
- Maximum fragment delay: If one specifies 20 ms delay, MLP will choose a fragment size based on the configured value.


MCMP (Multi-class Multilink PPP)

- This feature allows the delivery of delay-sensitive packets, such as the packets of a voice call, to be expedited by omitting the PPP multilink protocol header and sending the packets as raw
PPP packets in between the fragments of larger data packets.

MRRU Negotiation

- The PPP/MLP MRRU negotiation configuration feature allows a router to send and receive frames over MLP bundles that are larger than the default Maximum Receive Reconstructed Unit (MRRU) limit of 1524 bytes.
-----------
COMMANDS
-----------

interface s0/1
ppp multilink - Enables MLP
multilink-group {no} - Specifies interface multilink group membership
ppp multilink interleave - Enables LFI, real-time packet interleaving
ppp multilink fragment-delay {ms} - (o) Configure a maximum fragment delay
ppp multilink multiclass - Enables MCMP on an interface
ppp multilink mrru [local | remote] {mrru-value}

- Configures the MRRU value negotiated on a MLP bundle
- [local] Configures the local MRRU value
- [remote] The min value to be accepted from the peer

notes: PPP Link Quality Monitoring (LQM)

- The PPP suite includes a feature that allows devices to analyze the quality of the link.
- LCP provides an optional link quality determination phase. In this phase, LCP tests the link to determine whether the link quality is sufficient to use layer3 protocols.

- The command "ppp quality percentage" ensures that the link meets the quality requirement set; otherwise, the link is brought down.
- The percentages are calculated for both incoming and outgoing directions.
-----------
COMMANDS
-----------
debug ppp packet - Shows specific LCP operation

interface s0
ppp quality {percentage} - Enables link quality monitoring

notes: PPP Reliable Link (RFC 1663)

- Defines a method of negotiating and using Numbered Mode LAPB to provide a reliable serial link.
- Numbered Mode LAPB provides retransmission of errored packets across the serial link.
- PPP reliable link can be used with PPP compression over the link, but it does not require PPP compression.
- PPP reliable link does not work with multilink PPP.

-----------
COMMANDS
-----------
show int - Will show whether LAPB has been established on the link.
debug lapb - Displays all traffic for interfaces using LAPB encapsulation.

interface s0
ppp reliable-link - Enables PPP reliable-link

notes: PPP Peer neighbhor route

A /32 is automatically created for neighbor routes by default.

- It automatically sets up a route to the peer address on a point-to-point interface when the PPP IPCP negotiation is completed.

- It is useful to provide reachability when both ends of the PPP link are not on the same logical subnet. ie IP-unnumbered.

- Can be safely disabled when both ends of the link are in the same logical subnet.
- If using IP-unnumbered or dissimilar IP subnets on a data-link, leave it enabled.

- Most commonly used when different IP subnets on the same physical segment.
> R1 S1/0 is directly connected to R2 S2/0.
> R1 S1/0: IP address is 4.4.4.4/24.
> R2 S2/0: IP address is 5.5.5.5/24.
> R2 will have 4.4.4.4 in the routing table as 4.0.0.0/8 and 4.4.4.4 will be pingable.
> R1 will have 5.5.5.5 in the routing table as 5.0.0.0/8.
> Problems is that only the IP address is advertised to a PPP neighbor, and not the SUBNET MASK, it will assume classful boundary.

-----------
COMMANDS
-----------

interface E0
no peer neighbor-route

- Disables peer neighbor route, then connected IP address won’t be advertised
- Disables /32 host routes for the interface

notes: PPP Peer Address allocation

During IPCP negotiation, if the peer presents a peer IP address during IPCP address negotiation and the peer router has no address is assigned, the presented address is acknowledged and used in the current session.

CONFIG-SET: PPP IPCP address allocation

R5:

interface Serial0/2/0
ip address 192.168.205.5 255.255.255.0
encapsulation ppp
peer default ip address 192.168.205.2
ppp lcp predictive
ppp ipcp predictive

R2:

interface Serial0/1/0
ip address negotiated
encapsulation ppp
clock rate 2000000
ppp lcp predictive
ppp ipcp predictive


verification:

R2#sh ip int brief | i Serial0/2/0
Serial0/2/0 192.168.205.2 YES IPCP up up - Notice the method is IPCP (IP Control Protocol)

LAB: PPPoE

LAB: PPPoE

requirements:

-configure R3 as PPPoE client and R5 as the PPPoE server.
-use r3 fa0/a and r5 sub-interface fa0/1.35
-r5 should block any host attempting to initiate more than 10 sessions in a minute for 5 minutes
-allowed to create additional vlan 35 for this task
- r5 should allocate ip address to r3 from the local dhcp pool for the subnet 155.1.35.0
-make sure R3 is assigned the ip address 155.1.35.3 from the pool.
-r5 should authenticate r3 using chap and the password value of CISCO


Configuring R5 as PPoE Server

step 1: configure authentication parameters

aaa authentication ppp PPPOE local
username R3PPP password CISCO

step2: configure dhcp pool for the PPPoE clients. ip dhcp exluded is configured to ensure .3 is assigned to R3

ip dhcp pool PPPoE
network 155.1.35.0 255.255.255.0
!
ip dhcp excluded-address 155.1.35.1 155.1.35.2
ip dhcp excluded-address 155.1.35.4 155.1.35.254

step3: define bba-group

bba-group pppoe PPPoE
virtual-template 1
sessions per-mac throttle 10 60 300


step4: configure virtual template / authentication ppp chap

interface virtual-template 1
ip mtu 1492
encapsulation ppp
ip address 155.1.35.1 255.255.255.0
ppp authentication chap PPPOE

step 5: enable pppoe on the physical interface:

int fa0/1.35
pppoe enable group PPPoE



configure R3 as PPPoE client

step1: configure interface dialer

interface Dialer1
ip mtu 1492
ip address dhcp
encapsulation ppp
dialer pool 1
ppp chap hostname R3PPP
ppp chap password 0 CISCO

step2: configure the physical interface

interface FastEthernet0/1
pppoe enable group global
pppoe-client dial-pool-number 1


note: if a router is used as PPPoE client ff issues may arise;

1. some igp protocols e.g. OSPF may fail to negotiate across the virtual link due to MTU mismatch. This could be fixed using the command " ip ospf mtu-ignore" with OSPF or by setting the mtu value manually at both ends. in this case we set it at 1492 mtu size.


2. PMTU discovery may fail due to firewall filtering and TCP sessions may not work properly. This could be fixed using the command "ip tcp adjust-mss 1452" (or lower) on virtual interface e.g. dialer on the clien router.


verification:

show ip int brief

show pppoe session

notes: PPPoE

- The PPPoE client feature provides PPPoE client support on ATM PVCs (permanent virtual circuits) and ethernet interfaces.
- A dialer interface must be used for cloning virtual access.
- A PPPoE session is initiated by the PPPoE client.
- PPPoE is a commonly used application in the deployment of digital subscriber lines (DSL).
- The PPP over ethernet client feature expands PPPoE functionality by providing support for PPPoE on the client as well as on the server.
- PPP is configured on the physical interface and IP on the logical interface.
- A virtual-template interface is a PPP interface, no need for 'encapsulation ppp'.
- This can be seen with "sh interface virtual-template1"
- It is recommended that you set the MTU to 1492 bytes. This value accommodates a PPPoE header encapsulation of 8 bytes in the ethernet frame payload.

Dialer persistent feature:

- Allows a dial-on-demand routing (DDR) dialer profile connection to be brought up without being triggered by interesting traffic.
- The connection is not brought down until the shutdown interface command is entered on the dialer interface.
- If the persistent connection is torn down for some other reason, the system immediately tries to bring the connection back up.
- The dialer persistent command starts a timer when the dialer interface starts up and starts the connection when the timer expires.


CONFIG-SET: PPP over Ethenet (PPPoE) configuration
+---------------------------------------------------------------
R2 > PPPoE SERVER CONFIG
!
username test password test
!
bba-group pppoe global
vitual-template 1
!
ip local pool PPPoE 172.16.0.20 172.16.0.29
!
interface e0/1
ip address 10.0.0.6 255.255.255.0
pppoe enable group global
!
interface virtual-template1
ip address 172.16.0.12 255.255.255.255
ip mtu 1492
peer default ip address pool PPPoE
ppp authentication chap callin



R1 > PPPoE CLIENT CONFIG
!
bba-group pppoe global
!
interface fa0/0
ip address 10.0.0.5 255.255.255.0
!
interface fa1/0 - Configures the outside interface
no ip address
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface dialer 0
ip address negotiated
ip mtu 1492
encapsulation ppp
dialer-pool 1
dialer-group 1
ppp authentication chap callout optional
ppp chap hostname test
ppp chap password 0 test
!
ip route 0.0.0.0 0.0.0.0 Dialer0
dialer-list 1 protocol ip permit

show commands and verification

show vpdn - Displays information about active Layer2 Forwarding (L2F) protocol
show vpdn session packet - Displays PPPoE session statistics
show vpdn session all - Displays PPPoE session information for each session ID
show vpdn tunnel - Displays PPPoE session count for the tunnel
clear vpdn tunnel pppoe - Terminates PPPoE session and immediately try to re-establish the session
clear interface dialer {number} - With dialer persistent, re-attempts to bring up the connection
debug vpdn pppoe-data - Displays PPPoE session data packets
debug vpdn pppoe-errors - Displays errors preventing a session establishment and terminating errors
debug vpdn pppoe-events - Displays PPPoE session establishment events messages
debug vpdn pppoe-packets - Displays each PPPoE protocol packet exchanged
debug dialer - Displays info about the packets received on a dialer interface

LAB: PPP AAA Authentication

requirements:

- r4 to authenticate R5 against the RADIUS server IP 155.1.146.100
-r5 to authenticate r4 against the tacacs+ server IP 155.1.146.200
- if both remote servers fail r4 and r5 should use local user db for authentication.
- use cisco to authenticate the remote servers.
- dont use global commands to define the radius server in r4.

fyi: r4 authenticates r5 using ppp and chap. r5 authenticates r4 using pap only.

R4:
aaa new-model
!
!
aaa group server radius MYRADIUS
server-private 155.1.146.100 auth-port 1645 acct-port 1646 key CISCO
!
aaa authentication login CONSOLE none
aaa authentication ppp PPPAUTH group MYRADIUS local
!
interface Serial0/1
ppp authentication pap chap PPPAUTH
!
line con 0
login authentication CONSOLE

R5

aaa new-model
!
!
aaa authentication login CONSOLE none
aaa authentication ppp default group tacacs+ local
!
tacacs-server host 155.1.146.200 key CISCO
!
line con 0
login authentication CONSOLE

notes: PPP Authentication

PPP

One of the most important networking protocols is the Point-to-Point Protocol (PPP). Not only can you use it to transport many network protocols over point-to-point links, but it also provides capabilities to add authentication and link quality testing, allocate IP addresses, and provide error detection. The four major parts to PPP are network datagram encapsulation (such as
HDLC), link setup, termination and maintenance, and network layer protocol establishment and configuration. When you establish a PPP link, the link setup and maintenance protocol, LCP, is used. LCP is responsible for PPP link establishment, termination, and maintenance. When the link is established, different parameters are exchanged and the link can optionally be quality tested. After the link establishment phase, the Network Control Protocols (NCP) takes over and facilitates the transfer of Layer 3 protocols, such as IP.

To configure a serial link to use PPP, simply set the encapsulation:

Router(config-if)# encapsulation ppp

One of the features of PPP encapsulation is the capability to authenticate the link. PPP can use either Password Authentication Protocol (PAP) or Challenge-Handshake Authentication Protocol (CHAP). CHAP authentication is considered more securethan PAP authentication because the username and password are not transferred in the clear as they are in PAP. Instead CHAP
uses more secure hashs and frequent challenges that add security to the authentication process.

To configure PAP on a serial interface, the authentication credentials must be created first. This is typically done by creating a username and password combination on each router. The interface then contains a command that specifies what will be sent to the peer router. If the two match, authentication will succeed:


CONFIG-SET: PPP one-way PAP authentication

Example: R2 connects to R1, where R1 authentication R2

R1#
username R2C password cisco
!
interface s1/0
encapsulation ppp
ppp pap authentication pap
ppp max-bad-auth 3


R2#
interface s2/1
ppp pap sent-username R2C password cisco
ppp max-bad-auth 3

CHAP authentication is configured slightly different because the hostname of the routers are involved. A username is created matching the hostname of the peer router, and the password supplied must match:

- By default, the router uses its hostname to identify itself to the peer, but can be changed with "ppp chap hostname".
- A interface level CHAP hostname overwrites the routers global hostname.
- If the same host name is specified on both sides, the session authentication will fail, as the router ignores a authentication-request from its own hostname. To get around that issue the hidden command "no ppp chap ignoreus".
- A global password is always tried first and then a interface-level password will be tried.
- CHAP is defined as a one-way authentication method, but if applied in both directions it create two-way authentication.


CONFIG-SET : PPP two-way CHAP authentication
note password must match between peers

R2#
username CCIE password 0 cisco
!
interface Serial0/2
ip address 10.0.24.2 255.255.255.0
encapsulation ppp
ppp authentication chap


R4#
username R2 password 0 cisco
!
interface Serial1/0
ip address 10.0.24.4 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap hostname CCIE

Unfortunately, configuring PAP and CHAP on a PPP over Frame Relay is not be as easy as enabling or disabling the authentication. When dealing with Frame Relay interfaces, a virtual-template must be configured and applied to the interface.

1. First, a virtual-template interface must be created, and it’s encapsulation must be PPP:

Router(config)# hostname R1
R1(config)# int virtual-template <#>
R1(config-if)# encapsulation ppp


The IP address from the serial interface is moved to the virtual-template:

R1(config)# int
R1(config-if)# no ip address
R1(config-if)# int virtual-template <#>
R1(config-if)# ip address

The frame-relay interface-dlci is programmed to reference the virtual-template:

R1(config-if)# frame-relay interface-dlci ppp virtual-template <#>

Now authentication can be configured on the virtual-template as before:

R1(config-if)# ppp authentication chap
or
R1(config-if)# ppp authentication pap

notes: RIP Authentication

*===================================*
Authentication
*===================================*
- Only supported on RIPv2.
- Supports clear text and MD5.
- Configured using key-chains.
- RIP, unlike EIGRP does not require the same key-number on both sides.
- When configuring, order of operation is important.
- When making changes to the key-chain, first remove the config of the interface.

Steps involved
1. Define a key chain with a name.
2. Define the key or keys on the key chain.
3. Enable authentication on an interfaces and specify the key chain to be used.
4. Specify whether the interfaces will use clear text or MD5. If not specified, clear is used.
5. Optionally configure key management.

-----------
COMMANDS
-----------

Step 1: Defines a key-chain

key chain NAME

Step 2: Defines the key/s on the chain/Specifies the key-string

key 1
key-string STRING

Step 3: Enable authentication on an interfaces by using the key-chain

interface ethernet 0
ip rip authentication key-chain NAME

Step 4: Specifies whether the interfaces will use clear text or MD5

ip rip authentication mode md5

note: some version of ios you need to define accept lifetime and send lifetime. this happens when you noticed that peering is down after some time between 2 routers.

---------------------------
verification
---------------------------

show ip protocols | begin rip - Shows the key-chain in use

notes: RIP Default Routing, Route tagging

Default Routing

1. Generates and advertises an unconditional default route to neighbors

default-information originate

2. Using distribute-list with prefix list sending default routes

ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0
!
router rip
distribute-list prefix DEFAULT out

3. using route-map advertising default route conditionally


ip sla monitor 1
type echo protocol ipIcmpEcho 204.12.1.254 source-interface
FastEthernet0/0
timeout 50
frequency 1
ip sla monitor schedule 1 start-time now
!
track 1 rtr 1
!
router rip
default-information originate route-map RELIABLY_TRACK_LINK_TO_BB3
!
ip route 169.254.0.1 255.255.255.255 Null0 track 1
!
ip prefix-list DUMMY_ROUTE_TRACKED_VIA_SLA seq 5 permit 169.254.0.1/32
!
route-map RELIABLY_TRACK_LINK_TO_BB3 permit 10
match ip address prefix-list DUMMY_ROUTE_TRACKED_VIA_SLA

note:

With this example an IP SLA instance is introduced into conditional default origination. The SLA instance checks reachability to BB3 via ICMP every five seconds, with a timeout of two seconds. The SLA instance is then called from an enhanced object, which is called from a static route. This link local route of 169.254.0.1/32 could be any arbitrary dummy prefix. The dummy prefix is then called from a route-map which is tied to the default route origination. Therefore if R4 loses ICMP reachability to BB3 the default route is withdrawn. With the network properly functioning R4 advertises its default route to R5.


Route Tagging

-used in redistribution, then in a route-map

verification:

show ip rip database

notes: RIP Filtering

*===================================*
Filtering
*===================================*

- RIP can use distribute-lists, offset-lists and the distance command to filter traffic.
- Inbound filtering can be source based, like the distribute-list/ACL example below.
- If required to match the subnet mask, rather use prefix lists.
- Access-list "0" matches all routes.
- If no interface is identified, the list will modify all incoming or outgoing updates specified by the access list on any interface.
- If no access-list is called (by using a zero as the access list number), the offset list will modify all incoming or outgoing updates.


1. Distribute-lists
- can use either prefix-list or ACL

a. using prefix-list to filter routes coming in or out

config set1:

router rip
distribute-list prefix RIP_FILTER_TO_SW2 out FastEthernet0/0
distribute-list prefix PERMIT_ALL gateway NOT_FROM_R4 in
!
ip prefix-list NOT_FROM_R4 seq 5 deny 155.1.0.4/32
ip prefix-list NOT_FROM_R4 seq 10 permit 0.0.0.0/0 le 32
!
ip prefix-list PERMIT_ALL seq 5 permit 0.0.0.0/0 le 32
!
ip prefix-list RIP_FILTER_TO_SW2 seq 5 deny 30.0.0.0/14
ip prefix-list RIP_FILTER_TO_SW2 seq 10 deny 31.0.0.0/14
ip prefix-list RIP_FILTER_TO_SW2 seq 15 permit 0.0.0.0/0 le 32


config set2:

this allow 10.0.0.0/8 network from 1.2.3.4
router rip
distribute-list prefix ROUTE gateway SOURCE in
!
ip prefix-list ROUTE permit 10.0.0.0/8
ip prefix-list SOURCE permit 1.2.3.4/32



- Filters all routers to/from a neighbor using gateway

distribute-list gateway {prefix-list} {in|out} {interface}

- Filters prefixes from a specific source from entering the routing table

distribute-list prefix {prefix-routes} gateway {prefix-source} {in|out}

- filter routes coming form particular neighbor or gateways.

i.e.

ip prefix-list only24 seq 5 permit 0.0.0.0/0 ge 24 le 24 --allow only /24
!
ip prefix-list badgateway seq 5 permit 208.102.37.113/32
!
router rip
distribute-list prefix-list only24 gateway badgateway in


b. using Access-list to filter routes coming in or out

standard ACL

router rip
distribute-list 1 in Serial0/0
!
access-list 1 permit 0.0.1.0 255.255.254.255

extended ACL

router rip
distribute-list 100 in
!
access-list 100 permit ip host 1.2.3.4 host 10.0.0.0

Note: this accepts route only from 1.2.3.4 for network 10.0.0.0


2. Offset-list

- A "offset-list" can be used to modify the metric, but only to increase the metric.The metric cannot be decreased.
- A "offset-list" can also be used to filter traffic, by setting the metric to unreachable.

configset1:

access-list 1 permit 10.33.0.0 0.0.0.0
!
router rip
network 10.0.0.0
offset-list 1 in 2 Serial0

configset2:

router rip
offset-list 0 out 5 FastEthernet0/0.146

note: all routes going to fa0/0.146 will have an additional metric of 5.


3. Distance AD

Even though administrative distance is locally significant to the router, the RIP
process, like the EIGRP process, cannot advertise a route that is not actually
installed in the routing table.

distance AD {source address} {wildcard mask} {acl no}

configset1:

router rip
distance 255 0.0.0.0 255.255.255.255 1
!
access-list 1 permit 150.1.4.0

note: 0.0.0.0 255.255.255.255 - is from any source.

By setting the distance of the route 150.1.4.0 to
255, it is invalidated from being installed in the routing table, and hence
invalidated from being advertised to any neighbors.

configset2:

router rip
distance 55 150.0.1.1 0.0.0.0

all routes advertise by 150.0.1.1 neighbor will be having an admin distance of 55.

notes: RIP Summarization, Maximum Paths

*===================================*
Summarization
*===================================*

- By default auto-summarization is enabled for RIP.

Limitation of RIP summarization:

- More than one major network summary per interface is not allowed.
- Cannot summarize past the major network. For example the summary 10/7 is not allowed.

- When doing manual summarization, make sure auto-summary is off.
- The defining characteristic of a classful routing protocol is that it does not advertise an address mask along with the advertised destination address.

- For every packet passing through the router:
1- If the destination address is a member of a directly connected major network, the subnet mask configured on the interface attached to that network will be used to determine the subnet of the destination address. Therefore, the same subnet mask must be used consistently throughout that major network.
2- If the destination address is not a member of a directly connected major network, the router will try to match only the major class A, B, or C portion of the destination address.

-----------
COMMANDS
-----------

1. Limits the advertisements out of that interface to ONLY the summary

interface fa0/0
ip summary-address rip {ip} {mask}

- It's subject to a subnet of this aggregate being in the RIP database


Maximum Paths

-default max value of 4


command:

router rip:
maximum paths #

verification:

show ip protocols

notes: RIP Split-horizon, RIP triggered

*=====================================*
Split-Horizon, RIP Triggered
*=====================================*
- RIP employs split-horizon with poison reverse and triggered updates.

Split-Horizon

- Updates received in an interface will not be sent out of the same interface.
- Might be undesirable on partial mesh NBMA networks like multipoint interfaces.
- Is enabled for all interfaces by default, except main physical interfaces in frame-relay which has it disabled by default.

RIP triggered

- A triggered update occurs whenever the metric for a route is changed and, unlike regularly scheduled updates, includes only the entries that have changed.
- The receiving router does not reset its update timer when a triggered update is received.
- The command "ip rip triggered" enables the triggered extensions of RIP. It is needed on both sides of a link.
- Route table updates are minimized to include only the initial exchange of route tables and updates when changes to the route tables occur.
- The triggered state goes from DOWN, through INIT and LOADING, to FULL.
- Should only be configured on a point-to-point serial link.

-----------
COMMANDS
-----------
1. Enabled triggered updates on interface level.

ip rip triggered

- Only available on serial link, if both sides are enabled

2. Disables split-horizon

no ip split-horizon

---------------
verification
---------------

1. show ip protocols

notes: RIP Network statement, Passive-interface

Network statement on RIP has no mask option, and assumes classful boundaries, even with RIPv2.
- The updates sent to neighbors uses the assigned subnet masks from the interface on which the "network" address is configured.

command under router rip process

network {ip}

*===================================*
Passive interfaces
*===================================*

- no neigbhor relationship will be formed.
- "Passive-interface" is not a RIP-specific command.
- "Passive-interface" stops the sending of updates (Response.Msg) out of the interface specified.
- The router will still listen to RIP updates and update its routing table accordingly upon receipt of a response update message on the passive interface.
- The router will still advertises that interface address in normal updates to other peers.
- To stop the transmission of broad/multicast updates and send only unicast updates to a neighbor, include the passive-interface command along with the neighbor command under the RIP process.

-----------
COMMANDS
-----------
1. Disables sending of RIP updates on all interfaces

passive-interface default

2. then individually Stops the sending of updates out of the interface specified

[no] passive-interface {interface}

- Still receives updates and populates the routing table
- Still advertises that interface in normal updates to other peers

notes: RIP version, Update Types

- By default, a RIP process configured on a Cisco router sends only RIPv1 messages but listens to both RIPv1 and RIPv2.

V1

- classfull ( class A, B, C)
- default RIP configuration
- send updated as broadcast

v2
- supports VLSM/subnet mask/classless
- route summarization
-external route tags
- authentication
- uses multicast address for updates (224.0.0.9)
- "version 2" to enable v2 under RIP routing process
- The version 2 command causes RIP to send and listen to RIPv2 messages only.

note: v1 and v2 can received v1 & v2 updates by default.

to change the sending and receiving behavior using global under process

router rip
ip rip send v1
ip rip receive v1 v2


under interface:

ip rip receive version 1 2


*===================================*
Updates Types
*===================================*

1. Broadcast

- Default for RIPv1
- RIPv2 optional

to Enable broadcasts at a interface level for RIPv2.

ip rip v2-broadcast

note:it doesn't reflect in the "show ip protocols"

verification

debug ip rip

2. Multicast

- RIPv2 default to 224.0.0.9


3. Unicast

- RIPv1/RIPv2 optional

Under the process, send unicast updates to neighbor
- Useful on NBMA networks like frame-relay
- This does not stop the sending of broad/multicasts, use "passive-interfaces" for that

neighbor {IP}

Note: network statement should be there in which the neighbor belongs.

verification:

1. debug ip packets

2. show ip protocols

notes: RIP Metrics & Timers

- RIP uses hop-count as a metric.
- 1 hop per interface.
- 16 hops = unreachable

Timers:

1. Update timer (30sec) - A router sends a response message out every RIP-enabled interfaces every 30 seconds on average.

2. Invalid timer (180sec)- Amount of time a route can stay in the routing table without being updated.

3. Holddown (180sec) - An update with a hop count higher that the metric recorded in the table will place a route in holddown.
- cisco proprietary. if you you are connecting a non cisco devices set holdtime to 0.

4. Flush timer (240sec) - The time when a invalid route get removed from the routing table.

- Before the flush timer expires, the invalid route will be advertised with the unreachable metric.
- Shows in the routing table as "x.x.x.x is possibly down"
- Timers must be changed in all RIP domain

-----------
COMMANDS
-----------
1. to change the timers under rip routing process.

timers basic {update} {invalid} {holddown} {flush}

notes: RIP Operation

RIP Operation:

All RIP messages are encapsulated in UDP with source/destination ports being 520.

2 Message types:

1. Request: Used to ask neighboring routers to send an updates.
2. Response: Carries the update/routing entries.

- If a router must send an update with more than 25 route entries, multiple RIP messages will be produced.

- If more than one route exists to the same destination with equal hop counts, equal-cost load balancing will be performed.

- RIP sees a secondary IP addresses on a interfaces as separate data links, and can exchange routes with a secondary IP. But take note tha tall traffic generated by a router will always have the primary address as a source.
- RIP performs a soure-validation check, where the source IP address of incoming routing updates must be on the same IP network as one of the addresses defined for the receiving interface.

- Another instance where it might be needed to disable the source-validation, is when the source address is on a different subnet that, the locally configured address, ie local has a /32 and remote side a /24. This can be seen with "debug ip rip events".

- Output-delay

Can be used to sets a inter-packet gap between 8 and 50ms (default=0).
Can be used when a high-speed router is sending updates to a low-speed router.


-----------
COMMANDS
-----------

1. enable the RIP process:

router rip

2. Disables the validation of the source address in updates

no validate-update source

3. Sets an inter-packet gap (value 8-50), (Default=0)

output-delay {ms}


------------------
verification
------------------

1. All RIPv2 enabled routers will answer the ping and respond

ping 224.0.0.9

2. Displays RIP protocol events

debug ip rip events

3. to show which interface is participating

show ip protocols

LAB: Reliable backup interface with GRE

requirements:
- The static routes on R4 and R5 via the Frame Relay circuit should have a
higher administrative distance than those out the point-to-point link.
- Create a GRE tunnel between R4 and R5 using the addresses
10.0.0.Y/24 that is sourced from and destined to the Frame Relay
connection between them, and enable GRE keepalives.
- Configure the backup interface feature on R5 such that if the tunnel
between R4 and R5 goes down the point-to-point Serial link between them
is activated.
- To verify this configuration ensure that traffic between the Loopback0
interfaces of R4 and R5 is routed out the Frame Relay link between them,
but if R4’s Frame Relay interface is shut down this traffic is rerouted out
the point-to-point link.

Note: Creating the backup interface command at Physical int serial 0/0 connected via frame relay will not work. Since the line protocol status of this interface is based on the LMI keepalive status from the local Frame Relay switch, not the end-to-end PVC status, R5 cannot trigger the backup link when there is a failure of the circuit to R4. While the Frame Relay circuit is up we can see that R5 routes across this link to reach R4’s Loopback0 network. This is due to the fact that the route with the lower administrative distance via Serial0/1 cannot be installed because this
link is in standby state.

Solution:

the backup interface feature can become reliable by using a GRE tunnel and tunnel keepalives. By configuring a tunnel with keepalives between R4 and R5 sourced from the Frame Relay interface, these routers will be able to detect if end-to-end IP transport is lost between these interfaces. Furthermore if the backup interface command is configured on the tunnel interface, instead of the main Serial0/0 interface, R5 will be able to switch to the backup link if there is a failure anywhere in the end-to-end transit of the Frame Relay PVC.

R4:

ip route 150.1.5.0 255.255.255.0 155.1.0.5 20
ip route 150.1.5.0 255.255.255.0 155.1.45.5 10
!
interface Tunnel0
ip address 10.0.0.4 255.255.255.0
tunnel source 155.1.0.4
tunnel destination 155.1.0.5
keepalive 1 3

R5:

ip route 150.1.4.0 255.255.255.0 155.1.0.4 20
ip route 150.1.4.0 255.255.255.0 155.1.45.4 10
!
interface Tunnel0
ip address 10.0.0.5 255.255.255.0
tunnel source 155.1.0.5
tunnel destination 155.1.0.4
keepalive 1 3
backup interface Serial0/1

LAB: GRE Tunneling and Recursive Routing

A recursive routing error is when a lookup for prefix X points at prefix Y, and a
lookup for prefix Y points at prefix X. For tunnel interfaces this occurs when the
tunnel destination is dynamically learned in the tunnel interface itself. This
problem can be easily identified by the IOS log message %TUN-5-
RECURDOWN: Tunnel0 temporarily disabled due to recursive routing.

problem:

With the reception of a new RIP route for 150.1.9.0/24 with a metric of 1, the old route with a metric of 5 is flushed out. The recursive error now occurs because 150.1.9.0/24 is reachable via 10.34.0.9, but 10.34.0.9 is the tunnel reachable via 150.1.9.9. The router detects this error, disables the tunnel, and all routes learned via the tunnel are flushed.

%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state
to up

RT: del 150.1.9.0/24 via 155.1.108.8, rip metric [120/5]
RT: SET_LAST_RDB for 150.1.9.0/24
OLD rdb: via 13.11.13.11
RT: SET_LAST_RDB for 150.1.9.0/24
NEW rdb: via 10.34.0.9
RT: add 150.1.9.0/24 via 10.34.0.9, rip metric [120/1]

Solution:


SW3:

ip routing
!
interface Tunnel0
ip address 10.34.0.9 255.255.255.0
tunnel source Loopback0
tunnel destination 150.1.10.10
!
interface Loopback1
ip address 172.16.0.9 255.255.255.255
!
ip route 172.16.0.10 255.255.255.255 Tunnel0
!
router rip
version 2
no auto-summary
network 10.0.0.0
network 150.1.0.0
network 155.1.0.0
distribute-list prefix STOP_RECURSIVE_ERROR out Tunnel0
!
ip prefix-list STOP_RECURSIVE_ERROR seq 5 deny 150.1.9.0/24
ip prefix-list STOP_RECURSIVE_ERROR seq 10 permit 0.0.0.0/0 le 32


SW4:

ip routing
!
interface Tunnel0
ip address 10.34.0.10 255.255.255.0
tunnel source Loopback0
tunnel destination 150.1.9.9
!
interface Loopback1
ip address 172.16.0.10 255.255.255.255
!
ip route 172.16.0.9 255.255.255.255 Tunnel0
!
router rip
version 2
no auto-summary
network 10.0.0.0
network 150.1.0.0
network 155.1.0.0
distribute-list prefix STOP_RECURSIVE_ERROR out Tunnel0
!
ip prefix-list STOP_RECURSIVE_ERROR seq 5 deny 150.1.10.0/24
ip prefix-list STOP_RECURSIVE_ERROR seq 10 permit 0.0.0.0/0 le 32

LAB: Reliable PBR

Requirements:

- Configure R1 and R5 to run CDP over the Frame Relay network with each
other.
- Configure an IP SLA instance on R1 that pings R4’s connection to VLAN
146 every five seconds.
- Configure policy routing on R1 so that traffic from R3 going to R4’s
Loopback0 network is sent to R5 over the Frame Relay link, while traffic to
R5’s Loopback0 network is sent to R4 over VLAN 146.
- Use traceroute to verify that this configuration is functional.
- Modify the R1’s policy routing so that if R1 loses R5 as a CDP neighbor
traffic from R3 to R4’s Loopback0 network is rerouted directly to R4.
- Modify the R1’s policy routing so that if R1 loses ICMP reachability to R4
traffic from R3 to R5’s Loopback0 network is rerouted directly to R5.
- Use traceroute to verify that this configuration is functional.



R1:

ip sla monitor 1
type echo protocol ipIcmpEcho 155.1.146.4 source-interface
FastEthernet0/0
timeout 2000
frequency 5
!
ip sla monitor schedule 1 life forever start-time now
!
track 1 rtr 1
!
interface Serial0/0
ip address 155.1.0.1 255.255.255.0
encapsulation frame-relay
cdp enable
frame-relay map ip 155.1.0.5 105 broadcast
no frame-relay inverse-arp
!
interface Serial0/1
ip policy route-map RELIABLE_POLICY_ROUTING
!
ip access-list extended FROM_R3_TO_R4_LOOPBACK
permit ip host 155.1.13.3 host 150.1.4.4
!
ip access-list extended FROM_R3_TO_R5_LOOPBACK
permit ip host 155.1.13.3 host 150.1.5.5
!
route-map RELIABLE_POLICY_ROUTING permit 10
match ip address FROM_R3_TO_R4_LOOPBACK
set ip next-hop 155.1.0.5
set ip next-hop verify-availability --------------using CDP
set ip default next-hop 155.1.146.4
!
route-map RELIABLE_POLICY_ROUTING permit 20
match ip address FROM_R3_TO_R5_LOOPBACK
set ip next-hop verify-availability 155.1.146.4 1 track 1 ---using ICMP SLA Monitor
set ip default next-hop 155.1.0.5

LAB: Policy Based Routing

R1:

interface FastEthernet0/0
ip policy route-map POLICY_ROUTING
!
ip access-list extended FROM_R4
permit ip host 155.1.146.4 any
ip access-list extended FROM_R6
permit ip host 155.1.146.6 any
!
route-map POLICY_ROUTING permit 10
match ip address FROM_R4
set ip next-hop 155.1.13.3
!
route-map POLICY_ROUTING permit 20
match ip address FROM_R6
set ip next-hop 155.1.0.5

notes: Policy Base Routing (PBR)

enables you to implement policies that selectively cause packets to take different paths; this enables you to vary from the typical destination-based approach of IP. For example, you can easily configure routes to flow based on source address information. You can also mark traffic with different type of service (ToS) configurations. You implement PBR through the use of route maps to implement policy.


PBR (Policy-Based Routing) is a more flexible mechanism for routing packets than destination-based routing is.

- PBR allows control of traffic flow based on:
Source/Destination
Protocol type
Incoming interface

- Traffic that is denied by the policy-map will get routed normally.

PBR must be configured before PBR fast switching can be enabled. Fast switching of PBR is disabled by default. To configure fast-switched PBR, use the ip route-cache policy command in interface configuration mode.

- MATCH options:

as-path
community
extcommunity
interface
ip
length
local-preference
metric
route-type
source-protocol
tag


SET options:
as-path
community
dampening
extcommunity
interface
default interface
ip next-hop
ip default next-hop
ip next-hop verify-availability
local-preference
metric
metric-type
tag
weight

command:

incoming traffic:

interface:

ip policy route-map [route-map]


local Policy Routing

same as normal policy routing, excep it affects locally generated traffic from the router instead of traffic received inbound on an interface.

eventhough there is no route to the destination Local Policy routing can set it to using next-hop.

Pitfall:

normally the router uses the ip address of the outgoing interface in the routing table as the source IP address in its own packets. since routing table is not consulted for the lookup you may see inconsistencies in what the source address of the local traffic is.

config-set

ip local policy route-map LOCAL_POLICY
!
ip access-list extended TO_R4
permit ip any host 150.1.4.4
!
ip access-list extended TO_R5
permit ip any host 150.1.5.5
!
route-map LOCAL_POLICY permit 10
match ip address TO_R4
set ip next-hop 155.1.0.5
!
route-map LOCAL_POLICY permit 20
match ip address TO_R5
set ip next-hop 155.1.146.4

LAB: Reliable Static Routing with Enhanced Object Tracking

In this scenario R4 is using the layer 2 connectivity to switch 1 as the primary route, although R4 and R1 is on the same layer 2 segment, their physical ethernet interfaces are not on the same layer 1 network. It means R4 will not be able to track R1's connectivity to the switch if it is actually UP.

the solution is to create an IP SLA MONITOR instance, this will monitor R1 and then attaching creating an Enhanced Object tracking that watches the IP SLA monitor instance. This tracking will be attached on the static route.


R1:

ip route 150.1.4.0 255.255.255.0 155.1.0.4

R4:

ip sla monitor 1
type echo protocol ipIcmpEcho 155.1.146.1 source-interface
FastEthernet0/1
timeout 2000
frequency 5
ip sla monitor schedule 1 start-time now
!
track 1 rtr 1
!
ip route 150.1.1.0 255.255.255.0 155.1.146.1 track 1
ip route 150.1.1.0 255.255.255.0 155.1.0.5 2

R5:

ip route 150.1.1.0 255.255.255.0 155.1.0.1
ip route 150.1.4.0 255.255.255.0 155.1.0.4

notes: Backup Interface

Tracks the local line protocol of "primary" interface.

- If the line is up, the "backup" interface is in standby.
- If the line is down, the "backup" interface is out of standby and UP.
- The command "backup interface {int}" is placed on the primary interface, specifying the backup interface.
- Delay-Timers can be used with the backup command.
- Fallover, specifies the delay before the standby link gets brought up after the primary link failed.
- Failback, specifies the delay after the primary link came back up before bringing down the secondary interface.

Note: This solution could have the same black-hole pitfall that floating statics have.
- One solution is to use a tunnel interface and configure the backup command on the tunnel
- The backup command cannot be used on frame-relay physical interfaces. (no way to detect when back up)

optional commands:

backup delay

backup load

- allows backup based on a load value

config-set:


R4:

ip route 150.1.5.0 255.255.255.0 Serial0/1
ip route 150.1.5.0 255.255.255.0 155.1.0.5
!
interface Serial0/0.1 point-to-point
backup delay 3 60
backup interface Serial0/1


verification:

show backup

debug backup