Entries Tagged as 'IP Service'

Extended ACLs Different Application

Extended ACLs allow the router to analyse source/destination IP addresses and source/destination ports and Protocol type (such as ip, tcp and icmp). We can defined the traffic flow by this five factors. This poster focus on different application of extended ACLs.

1. Commonly Used

The following is commonly used statement for TCP access-list

ip access-list {extended|standard} name
permit|deny tcp source source-wildcard [operator [port]]
destination destination-wildcard [operator [port]] [established]
[precedence precedence] [tos tos] [log] [time-range time-range-name]

2. For Distribute-List

When extended access-lists called as a distribute-list in IGP, the “source” field in the ACL matches the update source of the route, and the “destination field represents the network address. For example,

access-list 101 deny ip host 192.168.50.4 host 10.2.106.0

The configuration is basically meaning that, deny 10.2.106.0 network which is advertised from 192.168.50.4 route.

3. For Redistribution

When extended access-lists called as a redistribution or as in BGP, the “source” field in the ACL represents the network address, and the “destination” field represents the subnet mask. For example,

ip access-list extended RIP-IN
permit ip 192.168.0.0 0.0.255.255 host 255.255.255.0
!
route-map RIP->OSPF
match ip address RIP-IN
!
router ospf 1
redistribute rip subnets route-map RIP->OSPF

The configuration is meaning that, when redistribute RIP into OSPF, only allow “192.168.0.0 network which has 255.255.255.0 subnet mask” in.

Another simple case is like this: Allow only 10.0.0.0 from host 1.2.3.4

- prefix gateway

ip prefix ROUTE permit 10.0.0.0/8
ip prefix SOURCE permit 1.2.3.4/32
distribute-list prefix ROUTE gateway SOURCE in

- Exteded access-list

access-list 101 permit ip host 1.2.3.4 host 10.0.0.0
distribute-list 101 in

Tags: IP Service, Networks by hengdu
No Comments »

UDP Broadcast Traffic Forwarding

Layer 3 device will terminate Broadcast traffic. However, sometimes we need to forward those broadcast traffic to somewhere bypass several layer 3 devices. The first example is one host send DHCPDISCOVERY broadcast traffic to DHCP server on the other broadcast domain. The other example is some UDP broadcast application talk to server or client on remote site. Both cases should use some ways to carry those broadcast traffic. Cisco provides two ways to carry those traffic.

  • By Unicast: ip helper-address <unicast-addr>
  • By Multicast: ingress: ip helper-map <mcast-addr> <ACL>; egress: ip helper-map <mcast-addr> <destination-unicast-addr> <ACL>

The diagram demonstrate two ways network and the configuration should follow steps below:

picture-22

Step 1: enable forward protocol globally.

ip forward-protocol udp <port # | protocol name>

Step 2: On the ingress interface, enable helper address or helper map. Note, it doesn’t need to enable ip directed-broadcast under ingress interface.

ip helper-addr <destination-unicast-addr>
ip helper-map <multicast-addr-group> <ACL>

Step 3: On the egress interface, we only care about multicast carrier since unicast carry broadcast directly to the destination.

ip helper-map <multicast-addr-group> <destination-unicast-addr> <ACL>
ip directed-broadcast

Note: Enable directed broadcasts on the interface connected to the receiving segment using the command ip directed-broadcast. This is needed to successfully send broadcasts out of this segment.

Tags: IP Service, Networks by hengdu
No Comments »

HSRP and VRRP Hello Package

I am always interesting in how protocol communicated. That’s why I will leave a note in here for HSRP and VRRP.

HSRP is Cisco propertary. The Hello Package between active router and standby router is sent to 224.0.0.2 UDP port 1985. (Do you remember the movie Back to the Future?)

VRRP is open standard. They use their own protocol to transport Hello package to 224.0.0.18. The protocol number is 112.

GLBP members communicate each other every 3 seconds by sending hello message to 224.0.0.102 UDP port 3222 (both source and destination).

Tags: IP Service, Networks by hengdu
No Comments »

NTP Authentication Configuration

NTP Authentication is server client mode authentication. However, instead of normal authentication, which is always server authenticate client, NTP authentication is NTP client to authenticate NTP server.

Therefore, for NTP server, the configuration is simple

ntp authentication-key 1 md5 14141B180F0B 7
ntp source Loopback0

For NTP client, we need configure to enable authentication, assign trust key, assign NTP server.

ntp authentication-key 1 md5 110A1016141D 7
ntp authenticate
ntp trusted-key 1
ntp server 192.168.3.3 source Loopback0

The server doesn’t need “ntp authenticate” command since NTP server does not need to authenticate NTP client.

The verify command is “show ntp associate detail“

Tags: IP Service, Networks by hengdu
2 Comments »

NAT Pool IP Address Need Participate IGP

In the NAT world, there are two terminologies that we used often, one is Inside Local, and the other is Inside Global. Inside Local is those IP address hidden behind NAT. Inside Global is virtual IP address pool that can be accessed from outside world. Before configuring NAT, we need to define an access-list for INSIDE_LOCAL to define which IP address participate NAT process. We also need to define an IP pool for INSIDE_GLOBAL. Then, we can enable NAT

ip nat inside source list INSIDE_LOCAL pool INSIDE_GLOBAL overload

However, we still can’t ping outside from inside. Why? because INSIDE_GLOBAL are virtual IP addresses that outside routers don’t have route to it. To solve this problem, we have two options.

  1. Create a loopback interface, assign IP address to the interface and let it running IGP in outside network.
  2. Create a static route on NAT router and point it to Null0 interface. Redistribute the static route to IGP in outside network.

Tags: IP Service, Networks by hengdu
No Comments »