Network 101: 2011

Monday, October 3, 2011

NAT Static

I wont talk about what NATing does in this article. However, I will show you some basic configuration of NAT to clarify everyone understanding.

Configuration example

Configuration

interface FastEthernet0/0

ip address 192.168.1.2 255.255.255.0

ip nat inside

ip virtual-reassembly

duplex auto

speed auto

interface FastEthernet0/1

ip address 192.168.2.1 255.255.255.0

ip nat outside

ip virtual-reassembly

duplex auto

speed auto

router ospf 1

log-adjacency-changes

network 192.168.1.2 0.0.0.0 area 0

network 192.168.2.1 0.0.0.0 area 0

ip http server

no ip http secure-server

ip route 2.2.2.0 255.255.255.0 192.168.2.2

// from inside to outside : route before translate

ip nat inside source static 1.1.1.1 172.16.1.1

ip nat outside source static 3.3.3.3 2.2.2.2

Providing route for R1 and R3 to pass the traffic through R2 to translate

ip route 2.2.2.2 255.255.255.255 192.168.1.2

ip route 172.16.1.0 255.255.255.0 192.168.2.1

Verify Configuration

R1#ping 2.2.2.2 source 1.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/66/176 ms

R1#

R3#ping 172.16.1.1 source 3.3.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:

Packet sent with a source address of 3.3.3.3

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 24/71/144 ms

R3#

R2#show ip nat translations

Pro Inside global Inside local Outside local Outside global

--- --- --- 2.2.2.2 3.3.3.3

icmp 172.16.1.1:2 1.1.1.1:2 2.2.2.2:2 3.3.3.3:2

icmp 172.16.1.1:8 1.1.1.1:8 2.2.2.2:8 3.3.3.3:8

--- 172.16.1.1 1.1.1.1 --- ---

R2#

R2 debug ip nat

Mar 1 00:32:18.007: NAT*: s=3.3.3.3->2.2.2.2, d=172.16.1.1 [41]

*Mar 1 00:32:18.007: NAT*: s=2.2.2.2, d=172.16.1.1->1.1.1.1 [41]

*Mar 1 00:32:18.035: NAT*: s=1.1.1.1->172.16.1.1, d=2.2.2.2 [42]

*Mar 1 00:32:18.035: NAT*: s=172.16.1.1, d=2.2.2.2->3.3.3.3 [42]

*Mar 1 00:32:18.051: NAT*: s=3.3.3.3->2.2.2.2, d=172.16.1.1 [42]

*Mar 1 00:32:18.051: NAT*: s=2.2.2.2, d=172.16.1.1->1.1.1.1 [42]

*Mar 1 00:32:18.063: NAT*: s=1.1.1.1->172.16.1.1, d=2.2.2.2 [43]

*Mar 1 00:32:18.063: NAT*: s=172.16.1.1, d=2.2.2.2->3.3.3.3 [43]

Not-so-stubby-area

OSPF nssa is the area that prohibits the LSA type 5 into the area but instead allow LSA type 7 to the area for the external routes.

There are options added on to the nssa area
- area x nssa no-summary
This area does not allow also the LSA type 3 or above into the area.
- area x nssa no-redistribute
This command is used in the the router that acts both ABR and ASBR. This command will not allow redistributed routes LSA type 7 into the nssa area but still allow the type 5 LSA in the OSPF process in area 0 ( backbone area )

Example for the NSSA no-redistribute

From the network diagram above, R2 is working as both ABR and ASBR. It redistributes the network 2.2.2.2/32 into the OSFP domian. However we do not want the router to advertise LSA type 7 in to the nssa area. but it is acceptable to have LSA type 5 in the OSPF domain. Here is the configuration on the R2.

interface Loopback0
ip address 2.2.2.2 255.255.255.255

router ospf 1
log-adjacency-changes
area 1 nssa no-redistribution
redistribute connected subnets
network 192.168.1.2 0.0.0.0 area 0
network 192.168.2.1 0.0.0.0 area 1

Looking at the R1 routing table, we can see the 2.2.2.2/32 network in it.

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 192.168.1.2, 00:21:56, FastEthernet0/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
O IA 192.168.2.0/24 [110/20] via 192.168.1.2, 00:34:03, FastEthernet0/0
O IA 192.168.3.0/24 [110/30] via 192.168.1.2, 00:27:32, FastEthernet0/0

However R4 doesn't see the 2.2.2.2/32 network in its database and its routing table.

R4#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

4.0.0.0/32 is subnetted, 1 subnets

C 4.4.4.4 is directly connected, Loopback0

O IA 192.168.1.0/24 [110/30] via 192.168.3.1, 00:29:46, FastEthernet0/0

O 192.168.2.0/24 [110/20] via 192.168.3.1, 00:29:46, FastEthernet0/0

C 192.168.3.0/24 is directly connected, FastEthernet0/0

So this illustrate how the nssa no-redistribute works.

Saturday, October 1, 2011

Auto QoS Discovery

Auto-Discovery

Started with the command:
(config-if)# auto discovery qos [trust]

Trust mode

auto-discovery trusts the DSCP values in the IP header and uses it to classify packets, collect bandwidth statistics, calculate traffic average and traffic peak rate, then passes the data to the template module.

Untrust mode
auto-discovery uses NBAR to detect application on the network to collect data and perform statistical analysis.

To show the data that has been collected:
# show auto discovery qos [interface [interface type]]

DHCP manually binding

<copy from http://www.cisco.com/en/US/docs/ios/12_0t/12_0t1/feature/guide/Easyip2.html#wp23682>

The IP address of a client can be assigned manually by an administrator or assigned automatically from a pool by a DHCP server.

Manual bindings are IP addresses that have been manually mapped to the MAC addresses of hosts that are found in the DHCP database. Manual bindings are stored in NVRAM on the DHCP server. Manual bindings are just special address pools. There is no limit on the number of manual bindings but you can only configure one manual binding per host pool.

To configure a manual binding, first create a host pool, then specify the IP address and hardware address of the client or client identifier. The hardware address is the MAC address. The client identifier, which is required for Microsoft clients (instead of hardware addresses), is formed by concatenating the media type and the MAC address of the client. Refer to the "Address Resolution Protocol Parameters" section of RFC 1700, Assigned Numbers, for a list of media type

Example Configuration

ip dhcp pool DHCP-TEST
host 10.1.2.10 255.255.255.0
hardware-address c204.07d0.0001 ieee802
default-router 10.1.2.1
dns-server 10.1.2.1
!
ip dhcp pool DHCP-TEST1
host 10.1.2.11 255.255.255.0
hardware-address 1111.1111.1111 ieee802
!

Verify Configuration

R3#sh ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
10.1.2.10 c204.07d0.0001 Infinite Manual
10.1.2.11 1111.1111.1111 Infinite Manual

Tuesday, September 27, 2011

Spanning tree portfast

Spanning-tree portfast command makes interface on the switch jump up from spanning-tree disable mode to spanning-tree forwarding mode which is different from the normal spanning tree operation that the interface needs to go through listening status and learning state. Therefore, the interface will come up right away.

How to enable spanning-tree portfast

Spanning-tree portfast in interface level
In the interface level we use " spanning-tree portfast" command to enable it. This is for an access port only. If you want to enable portfast for trunk port "spanning-tree portfast trunk" is required.

Spanning-tree portfast option in the global configuration
In the global configuration, we can enable the portfast for all of the access ports on the switch by using "spanning-tree portfast default " command. However, this command will not affect the trunk port on the switch

Option for spanning-tree portfast
- spanning-tree portfast bpduguard default

- spanning-tree portfast bpdufilter default

-spanning-tree portfast bpduguard default : it will enable the bgpuguard on the all of the portfast interfaces on the switch. This is only valid for access port.

- spanning-tree portfast bpdufilter default : it will enable the bgpufilter on the all of the portfast interfaces on the switch. This is only valid for access port.

Sunday, September 25, 2011

GLBP Load Balancing options

There are 3 different options for the GLBP load balancing

Host-dependent : load balancing based on MAC address of a host where the same forwarder is used for a particular host while the number of GLBP group members remains unchanged.
Round-Robin : Each active forwarder will in turns forward the packets. This is a default setting of glbp
Weighted : load balancing based on the weighting value advertised by the gateway.

Configuration Command

glbp group load-balancing [host-dependent | round-robin | weighted]

Saturday, September 24, 2011

MPLS LDP advertise lable

mpls ldp advertise-label

This command is enable by default. The MPLS router will advertise every network it learnt or connected network to its neighbor. In order to stop this advertisement, we use "no mpls ldp advertise-label " However, this command will disable every advertisement in the network.

If we want to specifically advertise label for specific network to specific destination, we can use the command as followings.
mpls ldp advertise-lable for <dest prefix> to <ldp peer>

Example

As shown in the figure, R1, R2 and R3 are in the MPLS network. In this scenario, we specify what prefix and what destination we want to have label advertised for the MPLS network. R1 will advertise label for 1.1.1.1/32 only but not 10.10.10.10/32. Here is the configuration example on R1

( we omitted the IGP configuration )

Before configuration

R2#sh mpls forwarding-table

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

16 Pop tag 30.30.30.30/32 570 Fa0/1 192.168.2.2

17 Pop tag 3.3.3.3/32 0 Fa0/1 192.168.2.2

18 Pop tag 10.10.10.10/32 0 Fa0/0 192.168.1.1

19 Pop tag 1.1.1.1/32 0 Fa0/0 192.168.1.1

Configuration command

no mpls ldp advertise-labels

mpls ldp advertise-labels for 2 to 1

access-list 1 permit 192.168.1.2

access-list 2 permit 1.1.1.1

Result / Verification

R2#sh mpls forwarding-table

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

16 Pop tag 30.30.30.30/32 570 Fa0/1 192.168.2.2

17 Pop tag 3.3.3.3/32 0 Fa0/1 192.168.2.2

18 Untagged 10.10.10.10/32 0 Fa0/0 192.168.1.1

19 Pop tag 1.1.1.1/32 0 Fa0/0 192.168.1.1

We can see now that the 10.10.10.10/32 label is not advertised to R2 from R1

Wednesday, September 21, 2011

Changing AD in OSPF

As we all know that, the default administrative distance of the OSPF is 110. However, in some cases, we will need to change this value to something else to manipulate the routing table to avoid routing loop or else. We use this following command to accomplish it.

distance <AD> <source address> <Mask> <ACL>

In OSPF, the source address is the router-id of the router advertising the network matched in ACL. Therefore, it is not necessarily the attached routers. See the configuration example below.

We have 4 routers R1,R2,R3,R4. R1 tries to change the administrative distance of the network advertised from R3 from 110 to 50. R3 has the router-id of 3.3.3.3. Therefore in R1, we can configure as followings.

Here is the routing table of R1

R1
Gateway of last resort is not set

20.0.0.0/24 is subnetted, 1 subnets
O E2 20.20.20.0 [110/20] via 192.168.1.2, 00:00:01, FastEthernet0/0
O IA 172.16.0.0/16 [110/21] via 192.168.4.1, 00:00:01, FastEthernet0/1
[110/21] via 192.168.1.2, 00:00:01, FastEthernet0/0
C 192.168.4.0/24 is directly connected, FastEthernet0/1
10.0.0.0/32 is subnetted, 1 subnets
C 10.10.10.10 is directly connected, Loopback0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
O 192.168.2.0/24 [110/20] via 192.168.1.2, 00:00:01, FastEthernet0/0
O 192.168.3.0/24 [110/20] via 192.168.4.1, 00:00:01, FastEthernet0/1
30.0.0.0/32 is subnetted, 1 subnets
O 30.30.30.30 [110/21] via 192.168.4.1, 00:00:01, FastEthernet0/1
[110/21] via 192.168.1.2, 00:00:01, FastEthernet0/0

Check the ospf database seen by R1

Routing Bit Set on this LSA
LS age: 137
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 3.3.3.3
Advertising Router: 3.3.3.3
LS Seq Number: 80000004
Checksum: 0x8D28
Length: 60
Area Border Router
Number of Links: 3

Link connected to: a Stub Network
(Link ID) Network/subnet number: 30.30.30.30
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1

Link connected to: a Transit Network
(Link ID) Designated Router address: 192.168.3.2
(Link Data) Router Interface address: 192.168.3.1
Number of TOS metrics: 0
TOS 0 Metrics: 10

Link connected to: a Transit Network
(Link ID) Designated Router address: 192.168.2.1
(Link Data) Router Interface address: 192.168.2.2
Number of TOS metrics: 0
TOS 0 Metrics: 10

We can see that R1 receive the LSA database from R3 ( area 0 - same area ). We apply the distance command to change the AD of ospf network from R3 as followings.

R1

router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
distance 50 3.3.3.3 0.0.0.0 1

access-list 1 permit any

This will change the AD for the network 30.30.30.30/32 to 50.

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

20.0.0.0/24 is subnetted, 1 subnets
O E2 20.20.20.0 [110/20] via 192.168.1.2, 00:05:10, FastEthernet0/0
O IA 172.16.0.0/16 [50/21] via 192.168.4.1, 00:05:10, FastEthernet0/1
[50/21] via 192.168.1.2, 00:05:10, FastEthernet0/0
C 192.168.4.0/24 is directly connected, FastEthernet0/1
10.0.0.0/32 is subnetted, 1 subnets
C 10.10.10.10 is directly connected, Loopback0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
O 192.168.2.0/24 [110/20] via 192.168.1.2, 00:05:10, FastEthernet0/0
O 192.168.3.0/24 [110/20] via 192.168.4.1, 00:05:10, FastEthernet0/1
30.0.0.0/32 is subnetted, 1 subnets
O 30.30.30.30 [50/21] via 192.168.4.1, 00:05:10, FastEthernet0/1
[50/21] via 192.168.1.2, 00:05:10, FastEthernet0/0

Monday, September 19, 2011

Interdomain Multicasting

Example configuration

We have 2 Autonomous System in this scenarios. AS 100 and AS 200 each running OSPF as the IGP routing protocol. The requirement in this example is to configure network to forward the multicast traffic from AS 100 to AS 200. The source of multicast traffic is R3 loopback interface and the receiver is sitting at R4 in the AS 200.

In this scenario, we need to configure Interdomain MSDP. We have selected R1 and R2 as a RPs for each AS. They form the MSDP neighbor together to accomplish this. Here is the configuration.

R1
router bgp 100

bgp log-neighbor-changes
neighbor 192.168.1.2 remote-as 200
!
address-family ipv4
redistribute ospf 1
neighbor 192.168.1.2 activate
no auto-summary
no synchronization
network 1.1.1.0 mask 255.255.255.0
exit-address-family
!
address-family ipv4 multicast
neighbor 192.168.1.2 activate
no auto-summary
no synchronization
exit-address-family
!
ip forward-protocol nd

ip pim rp-address 1.1.1.1

ip msdp peer 2.2.2.2 connect-source Loopback0 remote-as 200

router bgp 200

bgp log-neighbor-changes

neighbor 192.168.1.1 remote-as 100

address-family ipv4

redistribute ospf 1

neighbor 192.168.1.1 activate

no auto-summary

no synchronization

network 2.2.2.0 mask 255.255.255.0

exit-address-family

address-family ipv4 multicast

neighbor 192.168.1.1 activate

no auto-summary

no synchronization

exit-address-family

ip forward-protocol nd

no ip http server

no ip http secure-server

ip pim rp-address 2.2.2.2

ip msdp peer 1.1.1.1 connect-source Loopback0 remote-as 100

ip pim rp-address 1.1.1.1

ip pim rp-address 2.2.2.2

Verify configuration

R1#sh ip msdp summary

MSDP Peer Status Summary

Peer Address AS State Uptime/ Reset SA Peer Name

Downtime Count Count

2.2.2.2 200 Up 00:06:54 0 0 ?

R1#

R3#ping 239.1.1.1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.1.1.2, 388 ms

R3#

R2#sh ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 01:02:18/00:03:19, RP 2.2.2.2, flags: SJC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet0/1, Forward/Sparse, 01:02:18/00:03:19

(172.16.1.2, 239.1.1.1), 00:00:26/00:02:33, flags: M

Incoming interface: FastEthernet0/0, RPF nbr 192.168.1.1

Outgoing interface list:

FastEthernet0/1, Forward/Sparse, 00:00:26/00:03:19

(*, 224.0.1.40), 01:08:40/00:03:21, RP 2.2.2.2, flags: SJCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet0/0, Forward/Sparse, 01:05:16/00:02:25

FastEthernet0/1, Forward/Sparse, 01:08:40/00:03:21

Configuring Netflow for multicast traffic

This section was copied from cisco.com

Configuring NetFlow for Multicast IP Traffic

To configure NetFlow for multicast IP traffic, perform this task:


	Command	Purpose
Step 1	Router(config)# ip multicast netflow output-counters	(Optional) Enables the calculation of output bytes/packets for an ingress flow.
Step 2	Router(config)# ip multicast netflow rpf-failure	(Optional) Enables NetFlow for multicast data that fails the RPF check.
Step 3	Router(config)# interface{vlan vlan_ID} \| {type slot/port} \| {port-channel port_channel_number}	Selects a Layer 3 interface to configure.
Step 4	Router(config-if)# ip flow{ingress \| egress}	Enables NetFlow multicast traffic on the specified interface (for RP and PFC). •Specify ingress to enable NetFlow multicast ingress accounting. •Specify egress to enable NetFlow multicast egress accounting.

Tuesday, September 6, 2011

How to Decrypt Key 7 using IOS

Everyone may experience when we don't remember the password that we put into the configuration. This is a way to decry pt it using the cisco IOS.

Example

You forgot the password for the ntp authentication part
show run | in ntp

ntp authentication-key 1 md5 120D000406060851212E3D 7

Solution
- Create key chain.

R1(config)#key chain decryptkey
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string 7 120D000406060851212E3D
R1(config-keychain-key)#

R1#sh key chain

Key-chain decryptkey:

key 1 -- text "testmd5key"

accept lifetime (always valid) - (always valid) [valid now]

send lifetime (always valid) - (always valid) [valid now]

Wednesday, August 17, 2011

Zone-based policy Firewall

Zone based policy firewall is one of the feature of the Cisco router to act as if it is a firewall. The way zone based policy firewall works is that it creates zones for the interfaces. When there is a traffic go across zones, the zone-based policy firewall comes to play.

Here is the guideline how to configure the zone-based policy firewall in the Cisco router.
1. Create Zone security
2. Create Zone pair to pair two zone together. The zone pair will be unidirectional. Therefore, if you need to have bi-directional traffic you can do both ways back and forth or do a traffic inspection in the policy
3 Create Policy map to allow / deny the traffic matching the criteria specified in the class-map

Example

We have R1 - R2 -R3. We will setup a zone-based firewall allowing only host 1.1.1.1 from R1 to ping host 3.3.3.3 on R3. Other traffic is not allowed.

Configuration Example
R2

class-map type inspect match-all ICMP
match access-group 100
!
!
policy-map type inspect R1_R3_RULE
class type inspect ICMP
inspect
// inspect the out going traffic and permit the return of this traffic back to R1
class class-default
drop
// drop all other traffic.
!
zone security INSIDE
description R1_SIDE
zone security OUTSIDE
description R3_SIDE
zone-pair security R1-R3 source INSIDE destination OUTSIDE
service-policy type inspect R1_R3_RULE
// Create zone pair which has f0/0 (to R1) as an inside interface and f0/1 (to R3) as an outside interface.
!

interface FastEthernet0/0
ip address 192.168.1.2 255.255.255.0
zone-member security INSIDE
// assign the interface to the zone.
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.2.1 255.255.255.0
zone-member security OUTSIDE
duplex auto
speed auto

access-list 100 permit icmp host 1.1.1.1 host 3.3.3.3

access-list 100 permit ospf any any

Verification

Ping with the f0/0 source address ( 192.168.1.1)

R1#ping 3.3.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

R1#

Ping with the lo0 source address (1.1.1.1)

R1#

R1#ping 3.3.3.3 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 16/40/76 ms

R1#

Tuesday, August 16, 2011

multicast helper-map

Multicast Helper-map
Broadcast : 255.255.255.255
Multicast : 224.0.0.0 - 239.255.255.255
Broadcast address / subnet.

http://blog.ine.com/2008/05/06/understanding-the-ip-multicast-helper-map-command/

Thursday, August 11, 2011

EIGRP PE-CE

Sample Configuration of the EIGRP VRF
R1 - R2

PE (R1)
int f0/0
ip vrf forwarding VPNA
ip address 192.168.1.1 255.255.255.0

router eigrp 1
address-family ipv6 unicast vrf VPNA
network 192.168.1.0 0.0.0.255
autonomous-system 1
no auto-summary

CE (R2)
int f0/0
ip address 192.168.1.2 255.255.255.0

router eigrp 1
network 192.168.1.0 0.0.0.255
no auto-summary

Tuesday, August 9, 2011

Unicast reverse Path

Unicast reverse path check is used as an ingress filter to protect the network from the untrusted networks. When uRPF is enabled, the router checks the source ip address of the packet is reachable via the incoming interface. If it is not, the router will drop the packet.

Note:
uRPF should not be configured if you have the asymmetric network.

To see how this feature works, I have one simple examples to illustrate this. I have R1 - R2 - R3 connected according to the figure below. They are in the same OSPF area. However, R2 has a static route going to 1.1.1.1 pointing to the 192.168.3.2 (R3 interface ) as opposed to going out via 192.168.1.0 network.

R2: ip route 1.1.1.1 255.255.255.255 192.168.3.2

// we force the traffic back to 1.1.1.1/32 by going through R3 instead of R1 ( static route higher AD than OSPF)

We will test the connectivity by PING from R1 to R2 using source IP address of 1.1.1.1. If we do not enable the uRPF check on the R2 interface, the PING is successful.

R1#ping 2.2.2.2 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/35/56 ms

R1#

When we enable the uRPF check on the interface R2, the PING will be failed because the traffic R2 going back to R1 will use another route (via R3) instead of going to R1 directly. This violates the RPF check rule.

R2(config-if)#ip verify unicast source reachable-via rx

the ping is failed.

R1#ping 2.2.2.2 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

.....

Success rate is 0 percent (0/5)

R1#

Netflow Configuration

Netflow allow us to export traffic statistics to the remote workstation. We use this data to gain traffic performance, control, or accounting in the specific network locations.

Configure netflow

Enable Netflow

Interface Level : ip route-cache flow

Export Netflow information.

global level
ip flow-export destination x.x.x.x <port>
ip flow-export source x.x.x.x

Example configuration

interface Serial0/3/0

description T1 to remote-sites

bandwidth 1536

ip address 10.12.255.138 255.255.255.248

no ip redirects

no ip unreachables

no ip proxy-arp

rate-limit output access-group 191 256000 32000 48000 conform-action transmit exceed-action drop

ip route-cache flow

service-policy output VOIP-LLQ

ip flow-export source Loopback0

ip flow-export destination 10.12.66.82 16384

ip flow-export destination 10.12.64.36 3000

BSR Border

ip pim bsr-border

Prevent send / receive BSR message on the interface. When this command is used, the BSR domain will stop at the interface configured this command.

R1 ---- R2 -----R3

Before
R3

R3#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2
Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:00:04, expires: 00:02:21
R3#

After
R2
int f0/1
description To R3
ip pim bsr-border

R3

R3#sh ip pim rp mapping
PIM Group-to-RP Mappings

R3#

From the example above, after we put in the command ip pim bsr-border on the interface of R2 connecting to the R3, we no longer see the RP on the R3.

Monday, July 25, 2011

Command Scheduler (KRON)

Command Scheduler allows cutomers to schedule fully-qualified EXEC mode CLI command. It consists of 2 processes. A policy list is configured containing lines of EXEC CLI commands to be run.

KRON configuration example.

kron policy-list TEST_KRON
cli enable
cli conf terminal
cli int f0/1
cli bandwidth 10000

kron occurrence TEST_KRON in 1 // occurrence in 1 minute

policy-list TEST_KRON

Verify configuration

show kron schedule

Router#sh kron schedule

Kron Occurrence Schedule

TEST_KRON inactive, will run again in 0 days 00:00:13

Sunday, June 5, 2011

IP next-hop peer address (BGP)

In BGP routing protocol, the update from the external AS will contains the next hop address of the external hop itself. Therefore, when the router receives the update from the external AS and advertises the update to the other routers via iBGP, the other routers will see the next hop of the advertised networks via the external router IP address. However, we can use the next-hop-self command in the BGP process at the Border router to fix the problem. But what if we cannot use the next-hop-self command? Do we have any other option?

Yes. We can use the route-map and set ip next-hop peer-address command to tell the iBGP learn router to forward the packet to its peer address instead of the external router IP address. Check the example below for more detailed explanation.

In this example, R1 advertise 10.10.10.0/24 network to R2. R2 advertises this network to R3 via BGP. However, R2 does not have the next-hop-self command configured which makes the R3 consider the R1 as the next hop address. The problem is R3 does not know how to get to R1. Therefore, R3 does not have reachability through the 10.10.10.0/24 network.

R2
router bgp 200
no synchronization
bgp log-neighbor-changes
neighbor 192.168.1.1 remote-as 100
neighbor 192.168.2.2 remote-as 200

R3

R3#sh ip bgp
BGP table version is 2, local router ID is 192.168.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*>i10.10.10.0/24 192.168.1.1 0 100 0 100 i
R3#

We use the next-hop peer address command in the R2 which makes R3 forward the packet destined to 10.10.10.0/24 network via its peer address which in this case is R2 address.

R2

router bgp 200
no synchronization
bgp log-neighbor-changes
neighbor 192.168.1.1 remote-as 100
neighbor 192.168.2.2 remote-as 200
neighbor 192.168.2.2 route-map PEER-ADDRESS out

route-map PEER-ADDRESS permit 10
set ip next-hop peer-address
!

R3#sh ip bgp

BGP table version is 2, local router ID is 192.168.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i10.10.10.0/24 192.168.2.1 0 100 0 100 i

R3#

Now R3 see the next hop address via R2. We can test the connectivity through this network now.

R3#ping 10.10.10.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/34/108 ms

R3#

Friday, June 3, 2011

BGP Cluster ID Loop Prevention

A router reflector cluster normally has a single route reflector. To avoid a single point of failure, you can configure a cluster with more than one route reflector. In case we have more than one RR in the group, we will establish the cluster of RRs. All RRs in the cluster are in the same cluster -ID.

Route-Reflector (RR) has an algorithm to prevent the update from the other RRs. It will not accept the update that has the same Cluster-ID as itself in order to prevent the loop in BGP. Below is the example of how the loop prevention works.

Example

We have 2 scenarios as followings

R1 and R2 are in the same cluster and have the same Cluster ID which is 111.111.111.111
R1 and R2 are in the different cluster. R1 has cluster ID of 111.111.111.111 and R2 has a cluster ID of 222.222.222.222

Here is the example of the 1st scenario. ( same cluster ID)

R1
router bgp 100
no synchronization
bgp cluster-id 111.111.111.111
bgp log-neighbor-changes
neighbor 192.168.1.2 remote-as 100
neighbor 192.168.1.2 next-hop-self
neighbor 192.168.2.2 remote-as 100
neighbor 192.168.2.2 route-reflector-client
neighbor 192.168.2.2 next-hop-self
neighbor 192.168.4.2 remote-as 100
neighbor 192.168.4.2 route-reflector-client
neighbor 192.168.4.2 next-hop-self
no auto-summary
R1#

R2#sh run | sec bgp

router bgp 100

no synchronization

bgp cluster-id 111.111.111.111

bgp log-neighbor-changes

network 20.20.20.20 mask 255.255.255.255

neighbor 192.168.1.1 remote-as 100

neighbor 192.168.1.1 next-hop-self

neighbor 192.168.3.2 remote-as 100

neighbor 192.168.3.2 route-reflector-client

neighbor 192.168.3.2 next-hop-self

no auto-summary

R2(config-router)#do sh ip bgp

BGP table version is 11, local router ID is 20.20.20.20

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i3.3.3.3/32 192.168.3.2 0 100 0 i

*> 20.20.20.20/32 0.0.0.0 0 32768 i

R2(config-router)#

From the bgp table shown, R2 do not have the 50.50.50.50/32 and 40.40.40.40/32 in its BGP table, the reason is these networks have the same cluster-id with the R2. Due to the loop prevention mechanism, R2 will not accept these networks.

********************

router bgp 100

no synchronization

bgp cluster-id 222.222.222.222

bgp log-neighbor-changes

network 20.20.20.20 mask 255.255.255.255

neighbor 192.168.1.1 remote-as 100

neighbor 192.168.1.1 next-hop-self

neighbor 192.168.3.2 remote-as 100

neighbor 192.168.3.2 route-reflector-client

neighbor 192.168.3.2 next-hop-self

no auto-summary

R2(config-router)#do sh ip bgp

BGP table version is 13, local router ID is 20.20.20.20

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* i3.3.3.3/32 192.168.2.2 0 100 0 i

*>i 192.168.3.2 0 100 0 i

*> 20.20.20.20/32 0.0.0.0 0 32768 i

*>i40.40.40.40/32 192.168.4.2 0 100 0 i

*>i50.50.50.50/32 192.168.4.2 0 100 0 i

R2(config-router)#

Now, we have changed the cluster ID of R2 to 222.222.222.222. At this time R1 and R2 have a different Cluster-ID. Therefore, R2 will accept the bgp update from R1 and it has the 40.40.40.40/32 and 50.50.50.50/32 networks in its bgp table.

Verification

R3#sh ip bgp 40.40.40.40

BGP routing table entry for 40.40.40.40/32, version 11

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Not advertised to any peer

Local

192.168.4.2 (metric 74) from 192.168.3.1 (20.20.20.20)

Origin IGP, metric 0, localpref 100, valid, internal

Originator: 4.4.4.4, Cluster list: 222.222.222.222, 111.111.111.111

Local

192.168.4.2 (metric 74) from 192.168.2.1 (1.1.1.1)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 4.4.4.4, Cluster list: 111.111.111.111

R3#

R2#

R2#sh ip bgp 40.40.40.40

BGP routing table entry for 40.40.40.40/32, version 13

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Advertised to update-groups:

Local

192.168.4.2 (metric 74) from 192.168.1.1 (1.1.1.1)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 4.4.4.4, Cluster list: 111.111.111.111

R2#

Thursday, June 2, 2011

Remote SPAN

Remote SPAN (RSPAN) allows you to monitor source ports spread all over a switched network, not only locally on a switch with SPAN. The traffic monitored by SPAN, instead of being

directly copied to the destination port, is flooded into a special RSPAN VLAN. The destination port can then be located anywhere in this RSPAN VLAN (there can even be several destination ports).

In this example, we are trying to monitor port f0/7 of SW1 and want to send all SPAN traffic to SW3 port f0/9 which has network analyzer connected to it. Due to the fact that we do not have capture traffic locally, we need to use RSPAN. Therefore we created VLAN 99 to serve as a remote SPAN VLAN.

Below is the sample configuration

SW1

monitor session 10 source interface Fa0/7

monitor session 10 destination remote vlan 99

SW3

monitor session 10 destination interface Fa0/10

monitor session 10 source remote vlan 99

Wednesday, June 1, 2011

TCP and UDP Small Servers

TCP and UDP small server are services which runs on the router itself for some useful diagnostics.

TCP Small Servers

The TCP small servers are:

Echo: Echoes back whatever you type through the telnet x.x.x.x echo command.
Chargen: Generates a stream of ASCII data. Use the telnet x.x.x.x chargen command.
Discard: Throws away whatever you type. Use the telnet x.x.x.x discard command.
Daytime: Returns system date and time, if it is correct. It is correct if you run Network Time Protocol (NTP), or have set the date and time manually from the exec level. Use the telnet x.x.x.x daytime command.

Replace x.x.x.x with the IP address of your router. Most routers inside Cisco run the small servers.

UDP Small Servers

The UDP small servers are:

Echo: Echoes the payload of the datagram you send.
Discard: Silently pitches the datagram you send.
Chargen: Pitches the datagram you send, and responds with a 72-character string of ASCII characters terminated with a CR+LF.

igmp helper address

igmp helper address is used when we want to forward igmp join/leave message to another interface by specifying the ip address of the destination where we want to forward this igmp packet to.

In this example, R4 is trying to get the multicast traffic from R1. However, R3 is not a neighbor of R2. Therefore R4 cannot join the group. We need to add the igmp helper to forward this igmp join request to R2.

R2

interface FastEthernet0/1
ip address 192.168.2.1 255.255.255.0
ip pim sparse-dense-mode
ip pim neighbor-filter 1
duplex auto
speed auto

interface FastEthernet0/0

ip address 192.168.2.2 255.255.255.0

ip pim sparse-dense-mode

ip igmp helper-address 192.168.2.1

duplex auto

speed auto

end

interface FastEthernet0/0

ip address 192.168.3.2 255.255.255.0

ip igmp join-group 239.0.0.1

duplex auto

speed auto

Verify configuration

R1#ping 239.0.0.1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.3.2, 132 ms

Tuesday, May 31, 2011

BPDU filter

BPDUs are the messages exchanged between switches to calculate the spanning tree topology. BPDU filter is a feature used to filter sending or receiving BPDUs on a switchport.

It is extremely useful on those ports which are configured as portfast ports as there is no need to send or receive any BPDU messages on of these ports.

BPDU filter can be configured globally or under the interface level. When configured globally all portfast enabled ports stop sending and receiving BPDUs, but if a BPDU is received on the port it gets out of the portfast state and normally participate in the spanning tree calculations.

Monday, May 30, 2011

OSPF(ASBR) Summary address

There are 2 summarizations in OSPF routing protocols: Area summarization and External summarization. The area summarization is the summarization between the area. We can use "area x range x.x.x.x x.x.x.x" format to do so. However, in this post, we will talk about external summarization. We use "summary-address x.x.x.x x.x.x.x" format to achieve this.

In the example below, we consider R1 and the ASBR of the OSPF because it is a gateway between routing protocols (RIP and OSPF). We will show the effect of the "summary-address x.x.x.x x.x.x.x" command here.

We have network 20.1.1.0/24 being redistributed from RIP to OSPF. The 20.1.1.0/24 network will be an external route and shown in the R3 routing table as E2 type. Below shown the result without using the summary address command and with the command enable.

Without "summary-address" command.

Lets view routing table of R3

R3
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

20.0.0.0/24 is subnetted, 1 subnets
O E2 20.1.1.0 [110/20] via 192.168.2.1, 00:00:01, FastEthernet0/0
172.16.0.0/24 is subnetted, 3 subnets
C 172.16.1.0 is directly connected, Loopback0
C 172.16.2.0 is directly connected, Loopback1
C 172.16.3.0 is directly connected, Loopback2
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Loopback4
O E2 192.168.1.0/24 [110/20] via 192.168.2.1, 00:08:12, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/0

When enable the ASBR summarization at router R1

Let's see the configuration of R1 first regarding the external summarization.

router ospf 1

router-id 1.1.1.1

log-adjacency-changes

redistribute rip subnets

network 172.16.0.0 0.0.255.255 area 0

network 192.168.2.0 0.0.0.255 area 0

summary-address 20.0.0.0 255.0.0.0

redistribute ospf 1 metric 3

Let's now check the routing table of R3

R3#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

O E2 20.0.0.0/8 [110/20] via 192.168.2.1, 00:07:18, FastEthernet0/0

172.16.0.0/24 is subnetted, 3 subnets

C 172.16.1.0 is directly connected, Loopback0

C 172.16.2.0 is directly connected, Loopback1

C 172.16.3.0 is directly connected, Loopback2

10.0.0.0/24 is subnetted, 1 subnets

C 10.1.1.0 is directly connected, Loopback4

O E2 192.168.1.0/24 [110/20] via 192.168.2.1, 00:08:03, FastEthernet0/0

C 192.168.2.0/24 is directly connected, FastEthernet0/0

Monday, May 9, 2011

EIGRP Authentication PPPoFR Virtual-template

Example of EIGRP authentication by using different passwords for each neighbor in frame relay network.

R1 - R2
using md5 and CISCO12 as a password.
R1 - R3
using md5 and CISCO13 as a password.
Note
We are not allowed to use sub-interface at R1

Configuration

R1

key chain MY_KEY13
key 1
key-string CISCO13
!
key chain MY_KEY12
key 1
key-string CISCO12

interface Serial0/0
ip address 192.168.1.1 255.255.255.0
encapsulation frame-relay
clock rate 2000000
frame-relay interface-dlci 102 ppp Virtual-Template1
frame-relay interface-dlci 103 ppp Virtual-Template2
frame-relay lmi-type ansi
!

interface Virtual-Template1
ip address 192.168.1.1 255.255.255.0
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 MY_KEY12
!
interface Virtual-Template2
ip address 192.168.1.1 255.255.255.0
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 MY_KEY13
!
router eigrp 1
network 0.0.0.0
auto-summary

key chain MY_KEY

key 1

key-string CISCO12

interface Serial0/0

ip address 192.168.1.2 255.255.255.0

encapsulation frame-relay

clock rate 2000000

frame-relay interface-dlci 201 ppp Virtual-Template1

interface Virtual-Template1

ip address 192.168.1.2 255.255.255.0

ip authentication mode eigrp 1 md5

ip authentication key-chain eigrp 1 MY_KEY

router eigrp 1

network 0.0.0.0

auto-summary

key chain MY_KEY

key 1

key-string CISCO13

interface Serial0/0

ip address 192.168.1.3 255.255.255.0

encapsulation frame-relay

clock rate 2000000

frame-relay interface-dlci 301 ppp Virtual-Template1

interface Virtual-Template1

ip address 192.168.1.3 255.255.255.0

ip authentication mode eigrp 1 md5

ip authentication key-chain eigrp 1 MY_KEY

router eigrp 1

network 0.0.0.0

auto-summary

Pages

Monday, October 3, 2011

Saturday, October 1, 2011

Tuesday, September 27, 2011

Sunday, September 25, 2011

Saturday, September 24, 2011

Wednesday, September 21, 2011

Monday, September 19, 2011

This section was copied from cisco.com

Configuring NetFlow for Multicast IP Traffic

Tuesday, September 6, 2011

Wednesday, August 17, 2011

Tuesday, August 16, 2011

Thursday, August 11, 2011

Tuesday, August 9, 2011

Monday, July 25, 2011

Sunday, June 5, 2011

Friday, June 3, 2011

Thursday, June 2, 2011

Wednesday, June 1, 2011

Tuesday, May 31, 2011

Monday, May 30, 2011

Monday, May 9, 2011