Posts from ‘IP Services’

Nov
06

One of the major new topics tested in the CCIE R&S Written Exam is Cisco’s IP SLA feature. In response, I have updated your Written course with an IP SLA lesson. As you know, another reason you should master this technology is that it is a key ingredient in OER/PfR. This new lesson includes the following:

  • All of the Tier 1 foundational knowledge required for success in the written and lab exams
  • Several new Core Knowledge questions
  • Multiple choice practice exam questions
  • An interactive, hands-on exercise in which you configure an IP SLA operation, including an IP SLA Responder

Enjoy the new material, and subscribe to the blog to ensure you are aware of the many future updates as they happen.

Tags: , , , ,

Jul
22

The DHCP Information option (Option 82) is commonly used in metro or large enterprise deployments to provide additional information on “physical attachment” of the client. Option 82 is supposed to be used in distributed DHCP server/relay environment, where relays insert additional information to identify the client’s point of attachment.

Continue Reading

Tags: , , ,

May
03

A question on GroupStudy gave me an idea for the short post dedicated to explaining the use of DHCP “import all” command. The command first appeared in IOS 12.2T. It allows importing certain DHCP information learned from some external source, such as another DHCP server. This is helpful in reducing the amount of configuration needed in large hub-and-spoke networks, where spokes use centralized servers (e.g. WINS, DNS, TFTP). Instead of configuring the repetitive settings in every spoke router, you may import them by requesting an IP address for the router via DHCP. More than that, any change in central configuration could be easily imported in the remote routers, using DHCP address refresh. Here is how it works:

1) The router requests an IP address on its WAN interface via DHCP. In addition to the IP/subnet information, the router also learns other DHCP information, such as various DHCP options (DNS, WIN, TFTP IP addresses). This is store with the local DHCP client configuration.
2) The is a local pool configured in the router, with the subnet corresponding to the local Ethernet interface (say office network). This pool is configured with the statement “import all”.
3) By the virtue of “import all” statement and the default “origin dhcp” setting, the local pool imports the information learned by the router’s DHCP client. The imported information does not preempt the local subnet and mask, but instead add missing information.
4) Every time the DHCP lease expires, the router will re-request it, thus re-learning all other information as well.

As an alternative to using the DHCP it is possible to use IPCP for information import, if the WAN link uses PPP protocol (e.g. PPPoE). You simply need the statement “ip address negotiated” on the PPP link plus configured “origin ipcp” under the DHCP pool. Notice that the amount of IPCP options is much smaller than that of DHCP. However, you may still send WINS and DNS servers IP addresses, and even the netmask, using the command “ppp ipcp mask”. See the post The myster of “PPP IPCP mask request command” for more information on this command.

Here is a sample configuration.
Continue Reading

Tags: , ,

Nov
26

Here is a small task that illustrates how combining a few technologies may result in interesting solution.

Task:

Configure R1 to send all logging messages to the remote server at the IP address “10.0.0.100″. Ensure secure (non-cleartext) and reliable (acknowledged) information delivery.

DO NOT USE:

1) TCP as the transport protocol.
2) IPsec for encryption.
3) Any tunneling technology.

Recent update: do not use BEEP. This seems to be ruled out by “don’t use TCP”, but worths being mentioned separately. The solutions is supposed to be a “bit” more complicated :)

For simplicity, assume the server to be directly connected to the router via Ethernet. Also, assume the server could be configured in any way to match the router’s configuration.

The first person to find the correct solution would win a 100$ Amazon.com gift card. Since tomorrow is a big holiday in the US, we will post the solution and announce the winner somewhere around the coming weekend.

Have a nice Thanksgiving!

—-

OK, it looks like I’m getting old after all :) The solution has been found a few hours after I actually made the post! The Winner is: Carl Burkland. Congratulaitons! He was the first to post a working solution. I’m disclosing the comments right now, so you can see other people who came with correct solutions or bright ideas after Carl. Also, see some explanations and comments below.

Continue Reading

Tags: , , , , ,

Nov
05

Fragmented IPv4 traffic may cause you a lot of problems in real life. Not only it increases the load on router CPUs, but also impacts applications performance (e.g. TCP needs to re-send the whole packet on a single fragment loss). In addition to that, traffic fragmentation is used in numerous network attacks, allowing an attacker to bypass firewalls or IDSes in some situations. Due to all these reasons, you may want to avoid fragmentation at all and/or ensure your network is insulated from fragmented packets. Unfortunately, there are cases when using IPv4 fragmentation is unavoidable.

Continue Reading

Tags: , , , , , , ,

Oct
19

More updates have been posted to the IP Services section of the CCIE Routing & Switching Lab Workbook Volume 1 Version 5.0.  The following topics are now available:

Proxy ARP
DHCP Server
DHCP Client
DHCP Relay
DHCP Host Pools
DHCP on-Demand Pool
DHCP Proxy
DHCP Information Option
DHCP Authorized ARP
IP SLA
Object Tracking
HSRP
VRRP
GLBP
Router Redundancy and Object Tracking
IRDP
Router ICMP Settings
Basic NAT
NAT Overload
NAT with Route Maps
Static NAT
Static PAT
Static NAT and IP Aliasing
Static Policy NAT
NAT with Overlapping Subnets
TCP Load Distribution with NAT
Stateful NAT with HSRP
Stateful NAT with Primary/Backup
NAT Virtual Interface
NAT Default Interface
Reversible NAT
Static Extendable NAT
IP Precedence Accounting
IP Output Packet Accounting
IP Access Violation Accounting
MAC Address Accounting
TCP Optimization
IOS Small Services & Finger
Directed Broadcasts & UDP Forwarding
DRP Server Agent
WCCPv1 Web-Cache
WCCPv2 Services
SLB Directed Mode
SLB Dispatched Mode
NBAR Protocol Discovery
Netflow Ingress & Egress
Netflow Top Talkers
Netflow Aggregation Cache
Netflow Random Sampling
Netflow Input Filters
IOS Authoritative DNS Server
IOS Caching DNS Server
IOS DNS Spoofing
IP Event Dampening

Visit the members site for product access.  All technical questions should be posted to IEOC.  System Management is next, and will be posted in partial updates starting tommorrow.

Happy Labbing!

Tags: , , ,

Oct
04

For those of you eagerly awaiting updates to the new IEWB-RS Volume 1 Version 5.0 labs you’ll be happy to know that a partial release of the IP Services section is now posted. The following topics in IP Services are now available for download on the members site:

13.1 Proxy ARP

13.2 DHCP Server

13.3 DHCP Client

13.4 DHCP Relay

13.5 DHCP Host Pool

13.6 DHCP On-Demand Pool

13.7 DHCP Proxy

13.8 DHCP Information Option

13.9 DHCP Authorized ARP

13.10 IP SLA

13.11 Object Tracking

13.12 HSRP

13.13 VRRP

13.14 GLBP

13.15 Router Redundancy and Objects Tracking

13.16 IRDP

13.17 Router ICMP Settings

13.18 Basic NAT

13.19 NAT Overload

13.20 NAT with Route Maps

13.21 Static NAT

13.22 Static PAT

13.23 NAT and IP Aliasing

13.24 Static Policy NAT

13.25 NAT with Overlapping Subnets

13.26 TCP Load Distribution with NAT

13.27 Stateful NAT with HSRP

13.28 Stateful NAT Primary/Backup

13.29 NAT Virtual Interface

13.30 NAT Default Interface

13.31 Reversible NAT

13.32 Static Extendable NAT

Please direct all questions related to this series to http://www.IEOC.com. More sections will become available this week as well, and an announcement will be posted on the blog and the IEOC site.

Happy Labbing!

Brian

Tags: , , , , ,

Jul
15

Look at the following NAT scenario (thanks to Huan Pham on Groupstudy for the example). R2 is configured to translate R1 Loopback0 IP address to one of it’s own Loopback0 IP addresses:

R2:
ip nat inside source static 150.1.1.1 150.1.2.100
!
interface Serial 0/1
 ip nat inside
!
inerface FastEthernet 0/0
 ip nat outside

All hosts behind Ethernet segment can reach R1 using the IP address “150.1.2.100”. Now the question is to make a user logged in R2 to telnet to “150.1.2.100” and reach R1 Loopback0. Lets start straight with the final working configuration:

R2:
interface Loopback0
 ip nat outside
!
ip nat inside source static 150.1.1.1 150.1.2.100
ip nat outside source static 150.1.2.2 155.1.23.22

!
! Route returning packets from R1 over Loopback0
!
ip route 155.1.23.22 255.255.255.255 150.1.2.254

To verify it, enable the following debugging and telnet to 150.1.2.100 from R2:

Rack1R2#debug ip nat detailed
IP NAT detailed debugging is on

Rack1R2#telnet 150.1.2.100
Trying 150.1.2.100 ... Open

User Access Verification

Password: 

!
! NAT on the outside direction
!
NAT: o: tcp (150.1.2.2, 39064) -> (150.1.2.100, 23) [22225]
NAT: s=150.1.2.2->155.1.23.22, d=150.1.2.100 [22225]
NAT: s=155.1.23.22, d=150.1.2.100->150.1.1.1 [22225]

!
! NAT on the inside direction
!

NAT: i: tcp (150.1.1.1, 23) -> (155.1.23.22, 39064) [0]
NAT: s=150.1.1.1->150.1.2.100, d=155.1.23.22 [0]
NAT: s=150.1.2.100, d=155.1.23.22->150.1.2.2 [0]

As we can see from this output, the packet leaving Loopback0 is looped back and uses the both static NAT translation: first, to translate it’s source from “150.1.2.2” to “155.1.23.22” and the second to translate it’s destination from “150.1.2.100” to “150.1.1.1”. The resulting packet has src=”155.1.23.22” and dst=”150.1.1.1”.

Then a packet from R1 (src=”150.1.1.1”, dst=”155.1.23.22”) comes back. Since this packet enters NAT inside interface, a routing lookup is performed first, and the static route configured is used to route incoming packet to Loopback0 interface. Without the static route, R2 will attempt to route the packet either to itself (by default) or back to R3 (with no-alias keyword configured for NAT entry). So the static route saves the day, and packet source is translated using NAT inside rule (from “150.1.1.1” to “150.1.2.100”). After that, packet loops back to R2 and has it’s destination translated using NAT outside rule (from “155.1.23.22” to “150.1.2.2”). Looks fine.

Now what would happen if we remove the static route?

R2:
access-list 100 permit tcp any any eq telnet
access-list 100 permit tcp any eq telnet any

Rack1R2#debug ip packet detail 100
IP packet debugging is on (detailed) for access list 100
Rack1R2#debug ip nat detailed
IP NAT detailed debugging is on
Rack1R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1R2(config)#no ip route 155.1.23.22 255.255.255.255 150.1.2.254
Rack1R2(config)#^Z

Rack1R2#telnet 150.1.2.100
Trying 150.1.2.100 ...
!
! TCP SYN packet leaves R2, destination/source translated
!
NAT: o: tcp (150.1.2.2, 45879) -> (150.1.2.100, 23) [14437]
NAT: s=150.1.2.2->155.1.23.22, d=150.1.2.100 [14437]
NAT: s=155.1.23.22, d=150.1.2.100->150.1.1.1 [14437]

IP: tableid=0, s=155.1.23.22 (local), d=150.1.1.1 (Serial0/1), routed via FIB
IP: s=155.1.23.22 (local), d=150.1.1.1 (Serial0/1), len 44, sending
    TCP src=45879, dst=23, seq=1022925953, ack=0, win=4128 SYN
IP: tableid=0, s=150.1.1.1 (Serial0/1), d=155.1.23.22 (Serial0/1), routed via RIB

!
! Reply packet comes back from R1, destined to 155.1.23.22. Since we don’t have
! a static route to send this packet for NAT translation, but we have a local alias
! the router accepts the packet. But the destination address if 155.1.23.22, while
! the TCP session was sourced from 150.1.2.2. Therefore, the router sends an RST.
!
IP: s=150.1.1.1 (Serial0/1), d=155.1.23.22 (Serial0/1), len 44, rcvd 3
    TCP src=23, dst=45879, seq=3088708722, ack=1022925954, win=4128 ACK SYN
IP: tableid=0, s=155.1.23.22 (local), d=150.1.1.1 (Serial0/1), routed via FIB

IP: s=155.1.23.22 (local), d=150.1.1.1 (Serial0/1), len 40, sending
    TCP src=45879, dst=23, seq=1022925954, ack=0, win=0 RST

% Connection timed out; remote host not responding

!
! ICMP pings still work! This is because router will accept reply to any of it’s IP addresses
!

Rack1R2#ping 150.1.2.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.2.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/85/173 ms

With the two translations but no static route, the “inside” translation never kicks in (no “NAT: i” message) since the packet is routed to router itself. This is the way inside NAT works, and this breaks TCP connections, but ICMP is still working.

Okay but maybe that special outside translation that changes the IP address of R2 from “150.1.2.2” to “155.1.23.22” is not needed at all? Let’s remove it too, leaving ourselves with just one translation, and test connectivity again:

Rack1R2(config)#no ip nat outside source static 150.1.2.2 155.1.23.22
Rack1R2(config)#^Z
Rack1R2#
NAT: deleting alias for 155.1.23.22
NAT: deleting alias from redundancy list for 155.1.23.22
ipnat_remove_static_cfg: id 35, flag A

Rack1R2#telnet 150.1.2.100
Trying 150.1.2.100 ...
!
! Packet is translated using outside direction.. TCP session to 150.1.2.100
! is redirected to 150.1.1.1
!
NAT: o: tcp (150.1.2.2, 42616) -> (150.1.2.100, 23) [62052]
NAT: s=150.1.2.2, d=150.1.2.100->150.1.1.1 [62052]

IP: tableid=0, s=150.1.2.2 (local), d=150.1.1.1 (Serial0/1), routed via FIB
IP: s=150.1.2.2 (local), d=150.1.1.1 (Serial0/1), len 44, sending
    TCP src=42616, dst=23, seq=874820746, ack=0, win=4128 SYN
IP: tableid=0, s=150.1.1.1 (Serial0/1), d=150.1.2.2 (Loopback0), routed via RIB

!
! A reply arrives.. but it’s sourced from 150.1.1.1 and destined to 150.1.2.2.
! What that means is that R2 attempts to accept packet to it’s own IP address,
! but since it never initiated a connection to 150.1.1.1 (only to 150.1.2.100)
! the response is dropped and RST is sent!
!
IP: s=150.1.1.1 (Serial0/1), d=150.1.2.2, len 44, rcvd 4
    TCP src=23, dst=42616, seq=2431427125, ack=874820747, win=4128 ACK SYN

IP: tableid=0, s=150.1.2.2 (local), d=150.1.1.1 (Serial0/1), routed via FIB
IP: s=150.1.2.2 (local), d=150.1.1.1 (Serial0/1), len 40, sending
    TCP src=42616, dst=23, seq=874820747, ack=0, win=0 RST

% Connection timed out; remote host not responding

!
! Pings still work, since router accepts responses from any IP
!
Rack1R2#ping 150.1.2.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.2.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/64/65 ms
Rack1R2#

Now you see, that in order to make router perform “loopback NAT” you need two NAT rules and a static route. All this is pretty explainable if you look at the way inside and outside NAT work. And if you want more NAT scenarios, watch out for our soon-to-be released “IP Services” section of IEWB-RS VOL1 v5 Beta.

Tags: , , ,

Apr
24

GLBP, an acronym for Gateway Load Balancing Protocol, is a virtual gateway protocol similar to HSRP and VRRP. However, unlike its little brothers, GLBP is capable of using multiple physical gateways at the same time. As we know, a single HSRP or VRRP group represents one virtual gateway, with single virtual IP and MAC addresses. Only one physical gateway in a standby/redundancy group is responsible for packet forwarding, others remain inactive in standby/backup state. If you have R1, R2, R3 sharing the segment 174.X.123.0/24 with the physical IP addresses 174.X.123.1, 174.X.123.2 and 174.X.123.3 you may configure them to represent one single virtual gateway with an IP address 174.X.123.254. The physical gateway priority settings will determine which physical gateway takes the role of the active packet forwarder. The hosts on the segment will set their default gateway to 174.X.123.254, staying isolated of the physical gateway failures.

GLBP brings this idea to new level, by allowing multiple physical gateways to participate in packet forwarding simultaneously. Considering the example above, imagine you need the hosts on the segments to fully utilize all existing physical gateways, yet provide recovery from a gateway failure. For instance, you may want 50% of outgoing packets to be sent up to R1, 30% to R2 and 20% to R3. At the same time, you want to ensure, that hosts using either of the gateways will automatically switch to another if their gateway fails. On top of that, all hosts in the segment should reference to the virtual gateway using the same IP address 174.X.123.254. This is a complicated task, which has being addressed by GLBP protocol design.

To begin with, we should recall that every host on the segment needs to resolve the virtual gateway IP address 174.X.123.254 to the MAC address using ARP protocol. When we use HSRP or VRRP, the ARP response will be the virtual MAC addresses, which is assigned to the active physical gateway. At this point, GLBP responds with different virtual MAC addresses of the physical gateways in the GLBP group. So the key idea with GLBP is accomplishing load-balancing by responding to ARP requests with different virtual MAC addresses.

Here are the implementation details. One of the routers in a GLBP group is elected as an AVG – Active Virtual Gateway. There is only one active AVG in a group, and its task is to respond to ARP requests sent to the virtual gateway IP address (e.g. 174.X.123.254) replying different virtual MAC addresses in response packets. The AVG will also implement load-sharing algorithm, e.g. by sending the replies in proportion to weights configured for physical gateways. Aside from AVG, the other logical component of GLBP implementation is AVF – Active Virtual Forwarder. Any physical gateway in a GLBP group may act as AVF – in fact all physical gateways are usually AVFs. Every AVF has a virtual MAC address assigned by an AVG and a weight value configured by an operator.

Now let’s discuss redundancy – the primary goal of any virtual router protocol. There are two logical entities used to build a GLBP group: AVGs and AVFs, and each of them needs a backup scheme. Since there is just one AVG per a GLBP group, the procedure is pretty simple: each candidate AVG has a priority value assigned; the highest priority router becomes an active AVG, the next by priority becomes a standby AVG. You may configure AVG preemption, so that a newly configured router with highest priority value becomes AVG, preemption the old one.

What about AVF redundancy? First, we need to understand that AVFs are always “active” in the sense that they are always used by a load-balancing algorithm. (However, by setting an AVG weight value below threshold, we may effectively take the AVF out of service. The weight value could be combined with object tracking to bring powerful traffic manipulation options). Next, with respect to redundancy, all AVFs backup each other. For instance, take any AVF: with respect to the other AVFs it is “Active”, and the remaining AVFs are in “Listen” state. If the AVF would fail, other gatewyas will detect the event using Hold timer expiration, and immediately try to take over the failed AVF virtual MAC address. Among the competitors, the AVF with highest weight value would win, and the remaining AVFs will switch back to “Listen” state. At this point, the “winner” will start accepting packets for two virtual MAC addresses: it’s own, and the one it has obtained from the failed AVF. At the same moment, two timers would start: Redirect and Secondary Hold. The Redirect timer determines how long will AVG continue to respond to ARP requests with the virtual MAC of the failed AVF. The Secondary Hold timer sets the amount of time the backup AVF will continue to accept packet for the virtual MAC address taken from the failed AVF.

This is basically how GLBP works. Different load-balancing algorithms are supported – the default one is round robin, with options for weighted load balancing and source-MAC based. The last one will always respond with the same vMAC to the same source MAC address, thereby defining sort of host-gateway “stickiness”. Now for a sample GLBP configuration, for the above mentioned R1, R2 and R3:

!
!  We set load-balancing to weighted only on R1
!  So if R2 will become the AVG, it will use round-robin
!  load-balancing technique
!
R1:
interface FastEthernet0/0
 ip address 174.1.123.1 255.255.255.0
 glbp 123 ip 174.1.123.254
 glbp 123 preempt
 glbp 123 weighting 50
 glbp 123 load-balancing weighted
!
!
!
R2:
interface FastEthernet0/0
 ip address 174.1.123.2 255.255.255.0
 glbp 123 ip 174.1.123.254
 glbp 123 priority 50
 glbp 123 preempt
 glbp 123 weighting 30
!
!
!
R3:
interface Ethernet0/0
 ip address 174.1.123.3 255.255.255.0
 glbp 123 ip 174.1.123.254
 glbp 123 priority 25
 glbp 123 preempt
 glbp 123 weighting 20

Some show output:

Rack1R1#show glbp
FastEthernet0/0 - Group 123
  State is Active
    2 state changes, last state change 03:12:05
  Virtual IP address is 174.1.123.254
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.916 secs
  Redirect time 600 sec, forwarder time-out 14400 sec
  Preemption enabled, min delay 0 sec
  Active is local
  Standby is 174.1.123.2, priority 50 (expires in 8.936 sec) <-- Standby AVG
  Priority 100 (default)
  Weighting 50 (configured 50), thresholds: lower 1, upper 50 <--
<-- Should the weight go below thresh, AVF is taken offline
  Load balancing: weighted
  Group members:
    ca00.0156.0000 (174.1.123.1) local <--   Hardware MACs
    ca01.0156.0000 (174.1.123.2)
    cc02.0156.0000 (174.1.123.3)
  There are 3 forwarders (1 active)
  Forwarder 1
    State is Listen <--  All other AVFs Listen to us
    MAC address is 0007.b400.7b01 (learnt) <--  Virtual MAC 
    Owner ID is ca01.0156.0000 <--  This is R2
    Redirection enabled, 598.928 sec remaining (maximum 600 sec) <--
<-- ARP replies with this vMAC are being sent by AVG
    Time to live: 14398.376 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 174.1.123.2 (primary), weighting 30 (expires in 8.368 sec) <--
   <--  The AVF reports it’s own IP as active
    Arp replies sent: 1
  Forwarder 2
    State is Active <--  Active mean it’s us
      1 state change, last state change 03:12:45
    MAC address is 0007.b400.7b02 (default)
    Owner ID is ca00.0156.0000 <--  R1 MAC address
    Redirection enabled
    Preemption enabled, min delay 30 sec
    Active is local, weighting 50
    Arp replies sent: 1
  Forwarder 3
    State is Listen <--  All other AVFs Listen to us
    MAC address is 0007.b400.7b03 (learnt)
    Owner ID is cc02.0156.0000 <--  This is R3
    Redirection enabled, 597.916 sec remaining (maximum 600 sec)
    Time to live: 14397.916 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 174.1.123.3 (primary), weighting 20 (expires in 7.916 sec)

Rack1R2#show glbp
FastEthernet0/0 - Group 123
  State is Standby
    4 state changes, last state change 03:16:56
  Virtual IP address is 174.1.123.254
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.236 secs
  Redirect time 600 sec, forwarder time-out 14400 sec
  Preemption enabled, min delay 0 sec
  Active is 174.1.123.1, priority 100 (expires in 9.148 sec)
  Standby is local <-- We are the standby AVG
  Priority 50 (configured)
  Weighting 30 (configured 30), thresholds: lower 1, upper 30
  Load balancing: round-robin
  Group members:
    ca00.0156.0000 (174.1.123.1)
    ca01.0156.0000 (174.1.123.2) local
    cc02.0156.0000 (174.1.123.3)
  There are 3 forwarders (1 active)
  Forwarder 1
    State is Active
      1 state change, last state change 03:18:06
    MAC address is 0007.b400.7b01 (default)
    Owner ID is ca01.0156.0000 <-- This is R2
    Preemption enabled, min delay 30 sec
    Active is local, weighting 30
  Forwarder 2
    State is Listen
    MAC address is 0007.b400.7b02 (learnt)
    Owner ID is ca00.0156.0000
    Time to live: 14398.644 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 174.1.123.1 (primary), weighting 50 (expires in 8.636 sec)
  Forwarder 3
    State is Listen
    MAC address is 0007.b400.7b03 (learnt)
    Owner ID is cc02.0156.0000
    Time to live: 14399.260 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 174.1.123.3 (primary), weighting 20 (expires in 9.260 sec)

Now let’s check how ARP redirection works:

Rack1SW1#ping 174.1.123.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 174.1.123.254, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 8/12/16 ms

Rack1SW1#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  174.1.123.254           0   0007.b400.7b01  ARPA   Vlan1
Internet  174.1.123.7             -   cc06.0156.0000  ARPA   Vlan1
Internet  174.1.123.2             0   ca01.0156.0000  ARPA   Vlan1
Rack1SW1#clear arp-cache 

Rack1SW1#ping 174.1.123.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 174.1.123.254, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/13/32 ms

Rack1SW1#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  174.1.123.254           0   0007.b400.7b02  ARPA   Vlan1
Internet  174.1.123.7             -   cc06.0156.0000  ARPA   Vlan1
Internet  174.1.123.2             0   ca01.0156.0000  ARPA   Vlan1

Repeat the above actions a few more times

Rack1SW1#sh ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  174.1.123.254           0   0007.b400.7b03  ARPA   Vlan1
Internet  174.1.123.7             -   cc06.0156.0000  ARPA   Vlan1
Internet  174.1.123.2             0   ca01.0156.0000  ARPA   Vlan1
Internet  174.1.123.3             0   cc02.0156.0000  ARPA   Vlan1

To summarize, GLBP is a virtual gateway protocol, with built-in load-balancing capabilities. Load balancing is based on manipulating ARP responses to the requests sent to the virtual gateway IP address. AVG role is used to load-balance and respond to ARP requests. AVF role manages one or more virtual MACs and is responsible for packet forwarding. AVG redundancy is controlled by GLBP priority and AVF redundancy is implemented using AVF weight value and two additional timers.

Further reading:

GLBP Overview

Tags: , , , , ,

Feb
15

Quite many people don’t pay attention to the difference in handling packets on interfaces configured for NAT inside and outside. Here is an example to demonstrate how NAT “domains” interact with routing. Consider three routers connected in the following manner:

nat-inside-outside

For this scenario we have no routing configured. Let’s use static NAT to provide connectivity between R1 and R2. R2 would see R1 as a host on local connected segment with the IP address 155.1.23.1 and R1 would see R2 as a host on it’s local segment with the IP address 155.1.13.2. This goal could be achieved with the following configuration:


R3:
!
interface Serial 1/0.301 point-to-point
 ip address 155.1.13.3 255.255.255.0
 ip nat inside
 no ip route-cache
!
interface Serial 1/0.302 multipoint
 ip address 155.1.23.3 255.255.255.0
 frame-relay map ip 155.1.23.2 302
 ip nat outside
 no ip route-cache

!
! Static NAT: translations are effectively bi-directional
!
ip nat inside source static 155.1.13.1 155.1.23.1
ip nat outside source static 155.1.23.2 155.1.13.2

R2:
!
! Add a Frame-Relay mapping for the new IP (representing R1)
! so that R2 would know how to reach the address over multipoint FR interface
!
interface Serial 1/0.203 multipoint
 ip address 155.1.23.2 255.255.255.0
 frame-relay map ip 155.1.23.3 203
 frame-relay map ip 155.1.23.2 203

Let’s see how it’s working. Note that we disabled route-cache on both interfaces to intercept packets via CPU.


Rack1R3#debug ip nat detailed
IP NAT detailed debugging is on

Rack1R3#debug ip packet detail
IP packet debugging is on (detailed)

Rack1R2#ping 155.1.23.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Hmm…it fails. Look at the debugging output on R3:


Rack1R3#
!
! Packet on NAT outside (o - for outside) hits the interface
!
NAT*: o: icmp (155.1.23.2, 16) -> (155.1.23.1, 16) [84]

!
! Source and destination for the packet rewritten according to NAT rules
!
NAT*: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [84]
NAT*: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [84]

!
! The packet is routed after translation (with new source and destination IPs). Note that routing decision
! and the actual forwarding take place only after translation rules were triggered by NAT tables
!
P: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
    ICMP type=8, code=0
!
! The response packet from R1 comes in - to destination 155.1.13.2 -  routed via RIB (to the same interface)
! But no NAT rules were triggered since the destination interface is the same as input interface!
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), routed via RIB
IP: s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), len 100, rcvd 3
    ICMP type=0, code=0

OK hold here for a second.. Now we recall that for inside NAT routing is tried first, and only then the packet is translated according to the NAT rules. This is how the NAT order of operations works on the inside. So now it’s clear: IOS first tries to route packet to 155.1.13.2 – which is the same interface as it came in.. therefore the inside->outside translation never occurs! To fix this, let’s add a static route on R3:


R3:
ip route 155.1.13.2 255.255.255.255 155.1.23.2

Verification:


Rack1R2#ping 155.1.23.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/33/52 ms

Rack1R3#
!
! Outside: translate & route
!
NAT*: o: icmp (155.1.23.2, 17) -> (155.1.23.1, 17) [89]
NAT*: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [89]
NAT*: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [89]

!
! Routing decision and forwarding
!
IP: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
    ICMP type=8, code=0
!
! Inside: Routing decision - the packet is routed using our fixup static route
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.302), routed via RIB

!
! NAT rule (i - for inside) is triggered by the packet
!
NAT: i: icmp (155.1.13.1, 17) -> (155.1.13.2, 17) [89]     

!
! Source and destination addresses rewritten in the "opposite" direction
!
NAT: s=155.1.13.1->155.1.23.1, d=155.1.13.2 [89]
NAT: s=155.1.23.1, d=155.1.13.2->155.1.23.2 [89]

!
! Packet is sent to R2 (with the new source and destination) - forwarding takes place
!
IP: s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), g=155.1.23.2, len 100, forward
    ICMP type=0, code=0

Nice. So now we know the difference for sure: packets on the NAT outside are first translated and then routed. On the inside interface routing decision kicks in first and only then translation rules get applied followed by forwarding. Before we finish with that, recall new 12.3T feature called NAT Virtual Interface. With this feature we can now configure any interface as “NAT enabled” an get rid of those “inside” and “outside” domains . All NAT traffic passed through new virtual interface called NVI, in symmetric manner. Let’s reconfigure out task using this new concepts.


R3:
interface Serial 1/0.301 point-to-point
 no ip nat inside
 ip nat enable
!
interface Serial 1/0.302 multipoint
 no ip nat outside
 ip nat enable

!
!  Remove old rules
!
no ip nat inside source static 155.1.13.1 155.1.23.1
no ip nat outside source static 155.1.23.2 155.1.13.2

!
! Add "domainless" rules
!
ip nat source static 155.1.13.1 155.1.23.1
ip nat source static 155.1.23.2 155.1.13.2

no ip route 155.1.13.2 255.255.255.255 155.1.23.2

Verification:


Rack1R2#ping 155.1.23.1                 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/40/60 ms

Rack1R3#
!
! Routing decision it taken: packet classified for NAT, since destination is in NAT table
! Note that no actual forwarding occurs, just routing decision to send packet
!
IP: tableid=0, s=155.1.23.2 (Serial1/0.302), d=155.1.23.1 (Serial1/0.302), routed via RIB

!
! Packet translated according to NAT rules (note "i" for inside NAT)
!
NAT: i: icmp (155.1.23.2, 19) -> (155.1.23.1, 19) [95]
NAT: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [95]
NAT: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [95]

!
! Another routing decision, for translated packet - now actual forwarding occurs
!
IP: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
    ICMP type=8, code=0

!
! Response comes in, first routing decision - NAT table entry matched
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), routed via RIB

!
! Packet translated ("i" - inside NAT)
!
NAT: i: icmp (155.1.13.1, 19) -> (155.1.13.2, 19) [95]
NAT: s=155.1.13.1->155.1.23.1, d=155.1.13.2 [95]
NAT: s=155.1.23.1, d=155.1.13.2->155.1.23.2 [95]

!
! Another routing decision, for post-translated packet, followed by forwarding
!
IP: tableid=0, s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), routed via RIB
IP: s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), g=155.1.23.2, len 100, forward
    ICMP type=0, code=0

So what’s the difference with NVI? First, we see that now NAT behaves symmetrically. Next, we see that NAT translation tables are used to take a “routing decision” to send packet to virtual interface. Packet is translated there and then another routing decision takes place, followed by packet forwarding. So the difference from the old model is that now routing decision is taken twice: before and after translation. This allows to get rid of any static routes needed by “legacy” NAT, since lookup is performed after translation.

To summarize: Domain-based NAT uses different orders of operations for inside and outside domain. NVI based NAT is symmetrical and performs routing lookup twice: first to send packet to NVI, second to route packet using the post-translated addresses.

Links:

NAT Order of Operation

Tags: , , , ,

Categories

CCIE Bloggers