From: Hunt Lee (huntl@webcentral.com.au)
Date: Thu Nov 07 2002 - 22:38:55 GMT-3
Carlos,
Thanks for your help ;) So does this means I have to choose between
either:-
i) The link only existed between RTR1 & ISP1, and RTR2 & ISP2, so that
packets can only go into & out of the NAT pools in one path only
or
ii) keep the two links, but the pools on RTR1 & RTR2 are distinct.
Thanks so much for your help again.
Best Regards,
Hunt Lee
-----Original Message-----
From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
Sent: Friday, 8 November 2002 10:48 AM
To: Hunt Lee
Cc: Brian McGahan; ccielab@groupstudy.com
Subject: Re: NAT /w EBGP - half the packets got loss
Hunt,
one thing I was tempted to cite before is that NAT needs
to behave as a botleneck, and your solution tends to break this.
It was not broken before, but it sure is now if you do have
THE SAME pools at RTR1 and RTR2. If that's the case, and back traffic
comes through the wrong RTRx (i.e. not the one originating the NATted
session) then it will drop the packet.
Also, using the same pool will open the door for clashes (RTR1 and RTR2
using the same global IP at once).
You should be fine if the pools are distinct, i.e., one (or two) for
RTR1 and another (or other two) for the other.
HTH.
Hunt Lee wrote:
> Brian, Carlos,
>
> Thanks so much for you guys help ;) I bummed into another problem
though. After
> putting Loopback interfaces on both RTR1 & RTR2 for the External NAT Pools
+ BGP
> network command, since now ISP1 has links to both RTR1 & RTR2, & likewise
ISP2 now
> has a link both RTR1 & RTR2), I thought I will activate "bgp maximum-path
<2>" on
> ISP1 & ISP2.
>
> However, since the change, both RTR1 & RTR2 can see & ping fine to ISP1 &
ISP2. But
> for the servers & internal (OSPF) routers hanging off RTR1 & RTR2, only
half of
> their packets managed to get thru.
>
>
> PC (or Cisco router)--- RTR1----ISP1
> | \ /
> HostA \/
> | /\
> | / \
> RTR2---ISP2
>
> PC's IP - 172.16.2.2/24
> RTR1 Eth0 - 172.16.2.1/24
>
> The PC's Internal Local IP is supposed to be NAT to a Global IP based on
the
> criteria of the route-maps on RTR1:- (these two NAT pools also existed on
RTR2,
> apart from the difference in the Route-map)
>
> At RTR1:-
>
> ip nat pool PoolOne prefix-length 24
> address 201.50.13.2 201.50.13.2
> address 201.50.13.4 201.50.13.254
>
> ip nat pool PoolTwo prefix-length 24
> address 200.100.30.1 200.100.30.49
> address 200.100.30.51 200.100.30.253
>
> ip nat inside source route-map Pool1 pool PoolOne
> ip nat inside source route-map Pool2 pool PoolTwo
>
> access-list 1 deny 172.16.100.0 0.0.0.255
> access-list 1 permit 172.16.0.0 0.0.255.255
>
> access-list 4 permit 201.50.26.14
> access-list 5 permit 200.100.29.138
>
> route-map Pool1 permit 10
> match ip address 1
> match ip next-hop 4
> !
> route-map Pool2 permit 10
> match ip address 1
> match ip next-hop 5
>
>
> ********* Pings works for RTR1 to ISP1 & ISP2 ********************
>
> RTR1#ping 201.50.26.14 <---- Interface IPs of ISP1 to RTR1
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 201.50.26.14, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 28/30/32 ms
> RTR1#
>
> RTR1#ping 200.100.29.138 <----- Interface IPs of ISP2 to RTR1
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 200.100.29.138, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 28/30/32 ms
> RTR1#
>
> *******But if I try to ping ISP1 & ISP2 from PC, only half the packets
would get
> thru *********
>
>
> C:\>ping 201.50.26.14
>
> Pinging 201.50.26.14 with 32 bytes of data:
>
> Request timed out.
> Reply from 201.50.26.14: bytes=32 time=23ms TTL=254
> Request timed out.
> Reply from 201.50.26.14: bytes=32 time=22ms TTL=254
>
> Ping statistics for 201.50.26.14:
> Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
> Approximate round trip times in milli-seconds:
> Minimum = 22ms, Maximum = 23ms, Average = 22ms
>
> C:\>
>
> RTR1#
> *Mar 1 00:39:37.803 UTC: NAT: s=172.16.2.2->201.50.13.4, d=201.50.26.14
[2128]
> *Mar 1 00:39:43.247 UTC: NAT: s=172.16.2.2->201.50.13.4, d=201.50.26.14
[2129]
> *Mar 1 00:39:43.267 UTC: NAT*: s=201.50.26.14,
d=201.50.13.4->172.16.2.2[2129]
> *Mar 1 00:39:44.247 UTC: NAT: s=172.16.2.2->201.50.13.4, d=201.50.26.14
[2130]
> *Mar 1 00:39:49.255 UTC: NAT: s=172.16.2.2->201.50.13.4, d=201.50.26.14
[2131]
> *Mar 1 00:39:49.275 UTC: NAT*: s=201.50.26.14,
d=201.50.13.4->172.16.2.2[2131]
> *Mar 1 00:40:49.275 UTC: NAT: expiring 201.50.13.4 (172.16.2.2) icmp 512
(512)
>
>
> C:\>ping 200.100.29.138
>
> Pinging 200.100.29.138 with 32 bytes of data:
>
> Request timed out.
> Reply from 200.100.29.138: bytes=32 time=22ms TTL=254
> Request timed out.
> Reply from 200.100.29.138: bytes=32 time=22ms TTL=254
>
> Ping statistics for 200.100.29.138:
> Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
> Approximate round trip times in milli-seconds:
> Minimum = 22ms, Maximum = 22ms, Average = 22ms
>
> C:\>
>
>
> *Mar 1 00:42:53.987 UTC: NAT: s=172.16.2.2->200.100.30.51,
d=200.100.29.138[2147]
> *Mar 1 00:42:59.023 UTC: NAT: s=172.16.2.2->200.100.30.51,
d=200.100.29.138 [2148]
> *Mar 1 00:42:59.043 UTC: NAT*: s=200.100.29.138,
d=200.100.30.51->172.16.2.2 [2148]
> *Mar 1 00:43:00.023 UTC: NAT: s=172.16.2.2->200.100.30.51,
d=200.100.29.138 [2149]
> *Mar 1 00:43:05.031 UTC: NAT: s=172.16.2.2->200.100.30.51,
d=200.100.29.138 [2150]
> *Mar 1 00:43:05.051 UTC: NAT*: s=200.100.29.138,
d=200.100.30.51->172.16.2.2 [2150]
>
> And if I moved the PC behind RTR2, I get the same result when I tried to
ping ISP1 &
> ISP2.
>
> Any help will be greatly appreciated.
>
> Regards,
> H.
>
>
>
>
> --- Carlos G Mendioroz <tron@huapi.ba.ar> wrote: > Frank,
>
>>AFAIK, there are 2 ways of injecting a route into BGP:
>>-using network command
>>-redistributing
>>
>>Both need a pre-existing route in the router, and in the case of
>>network command, the mask has to match exactly.
>>
>>Now, if your are natting over a pool of addresses, that does not create
>>a route to that pool per se, so you need some way to have that route.
>>It can be a static (default to null as Brian suggests, which I think
>>is the preferred way anywhere but the lab) or it can be a connected
>>virtual (aka loopback).
>>Then you can use network.
>>
>>frank.yu@japan.bnpparibas.com wrote:
>>
>>>Hunt,
>>>
>>> I have the similar infrastructure on my network. Just use "network
>>>201.50.13.0 mask 255.255.255.0" under router bgp xxx on rtr1 and "network
>>>200.100.30.0 mask 255.255.255.0" under router bgp xxx on rtr2. It will do
>>>the job.
>>>
>>>Frank
>>>
>>>
>>>
>>>Internet
>>>huntl@webcentral.com.au@groupstudy.com - 11/05/2002 10:59 AM
>>>
>>>
>>>Please respond to huntl@webcentral.com.au
>>>
>>>Sent by: nobody@groupstudy.com
>>>
>>>To: ccielab
>>>
>>>cc:
>>>
>>>
>>>Subject: NAT /w EBGP
>>>
>>>
>>>Team:
>>>
>>>
>>>Inside Outside
>>>
>>> RTR1----ISP1
>>> | \ /
>>>HostA \/
>>> | /\
>>> | / \
>>> RTR2---ISP2
>>>
>>>RTR1 & RTR2 are connected by IBGP & OSPF. In addition, RTR1 & RTR2 each
>>>have 2
>>>EBGP links connecting to ISP1 & ISP2 respectively.
>>>
>>>RTR1 & RTR2 - AS3
>>>ISP1 - AS1
>>>ISP2 - AS2
>>>
>>>RTR1, Eth0:- 172.16.3.1/24
>>>RTR2, Eth0:- 172.16.3.2/24
>>>Host A - 172.16.3.3/24
>>>
>>>ISP1 has been assigned the address block 201.50.13.0/24, ISP2 has been
>>>assigned
>>>the address block 200.100.30.0/24.
>>>
>>>What I want to achieve is that the NAT will translate inside addresses
>>>appropriately for each ISP's assigned address block.
>>>
>>>The problem I am having is that since hostA's IP is being NAT, neither
RTR1
>>>nor
>>>RTR2 have the NAT range in their Routing Tables, which means I can't
>>>advertise the NAT range to ISP1 & ISP2 in BGP by "network x.x.x.x mask
>>>y.y.y.y". So what can I do to advertise these NAT ranges to ISP1 &
ISP2??
>>>
>>>Any help will be greatly appreciated.
>>>
>>>Regards,
>>>H.
>>>
>>>
>>>
>>>
>>>
>>>This message and any attachments (the "message") is
>>>intended solely for the addressees and is confidential.
>>>If you receive this message in error, please delete it and
>>>immediately notify the sender. Any use not in accord with
>>>its purpose, any dissemination or disclosure, either whole
>>>or partial, is prohibited except formal approval. The internet
>>>can not guarantee the integrity of this message.
>>>BNP PARIBAS (and its subsidiaries) shall (will) not
>>>therefore be liable for the message if modified.
>>>
>>> ---------------------------------------------
>>>
>>>Ce message et toutes les pieces jointes (ci-apres le
>>>"message") sont etablis a l'intention exclusive de ses
>>>destinataires et sont confidentiels. Si vous recevez ce
>>>message par erreur, merci de le detruire et d'en avertir
>>>immediatement l'expediteur. Toute utilisation de ce
>>>message non conforme a sa destination, toute diffusion
>>>ou toute publication, totale ou partielle, est interdite, sauf
>>>autorisation expresse. L'internet ne permettant pas
>>>d'assurer l'integrite de ce message, BNP PARIBAS (et ses
>>>filiales) decline(nt) toute responsabilite au titre de ce
>>>message, dans l'hypothese ou il aurait ete modifie.
>>>
>>
>>
>>--
>>Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
>
>
> http://careers.yahoo.com.au - Yahoo! Careers
> - 1,000's of jobs waiting online for you!
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Tue Dec 03 2002 - 07:23:09 GMT-3