RIP NAT

There are two important things to note in this example.
First, when the packet travels from outside to inside, translation occurs first, and then the routing table is checked for the destination. When the packet is travels from inside to outside, the routing table is checked for the destination first, and then translation occurs.
Second, it's important to note which part of the IP packet gets translated when using each of the commands above. The following table contains a guideline:
Command Action
ip nat outside source list
ip nat outisde source static ( converts Outside global to Outside Local)
translates the source of the IP packets that are traveling outside to inside
translates the destination of the IP packets that are traveling inside to outside
ip nat inside source list
ip nat outisde source static ( converts Inside local to Inside global)
translates the source of IP packets that are traveling inside to outside
translates the destination of the IP packets that are traveling outside to inside
What the above guidelines indicate is that there is more than one way to translate a packet. Depending on your specific needs, you should determine how to define the NAT interfaces (inside or outside) and what routes the routing table should contain before or after translation. Keep in mind that the portion of the packet that will be translated depends upon the direction the packet is traveling, and how you configured NAT.
R1 ========== R2
172.16.1.1 172.16.1.2
R1
ip nat outside source static udp 172.16.1.2 520 224.0.0.9 520 extendable

R2
ip nat outside source static udp 172.16.1.1 520 224.0.0.9 520 extendable
ip nat outisde source static ( converts Outside global to Outside Local)

R1#sh ip nat tran
Pro Inside global Inside local Outside local Outside global
udp --- --- 224.0.0.9:520 172.16.1.2:520
udp 172.16.1.1:520 172.16.1.1:520 224.0.0.9:520 172.16.1.2:520
R1#


Mar 1 00:50:54.147: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (172.16.1.1)
*Mar 1 00:50:54.147: RIP: build update entries
*Mar 1 00:50:54.147: 1.1.1.1/32 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:50:54.151: NAT: i: udp (172.16.1.1, 520) -> (224.0.0.9, 520) [0]
*Mar 1 00:50:54.151: NAT: s=172.16.1.1, d=224.0.0.9->172.16.1.2 [0]
R1#
*Mar 1 00:50:58.503: NAT*: o: udp (172.16.1.2, 520) -> (172.16.1.1, 520) [0]
*Mar 1 00:50:58.503: NAT*: s=172.16.1.2->224.0.0.9, d=172.16.1.1 [0

EIGRP UNEQUAL LOAD BALANCING :

EIGRP formula :
Topology : All protocol running EIGRP &
 Connected with defualt Fast Ether BW & DLY
##############################################
 Topology
 R2 <====R4<===>R1<===> R3<====>R4
#################################################
256{ 10^7/Min BW in Kbps + combined delay in 10th of Microsecond }
256 { 10^7/100000 + (5250/10) }256 { 100+525}
= 160000
In another word issue :

 sh ip eigrp topology x.x.x.x mask command &
 divide total delay by 10 ( which will give us 10th of micro second )

sh ip eigrp topology 4.4.4.4 255.255.255.255
1#sh ip eigrp top 4.4.4.4 255.255.255.25
IP-EIGRP (AS 1): Topology entry for 4.4.4 State is Passive,
 Query origin flag is Routing Descriptor Blocks: 172.16.12.2 (FastEthernet1/0),
 from 172 Composite metric is (158720/156160) Vector metric: Minimum bandwidth is 100000 Kbit Total delay is 5200 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 2
172.16.13.3 (FastEthernet0/0), from 172 Composite metric is (160000/144640) (FD/AD) Vector metric: Minimum bandwidth is 100000 Kbit Total delay is 5250 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 2
=====================================================
For unequal cost load balancing First Feasible condition needs to meet :
FD ( aka current best route metric ) needs to be greater than Candidate's AD ( even equal do not work) Or AD needs to lower than AD In another word ( I will say on command line ):
Topology : All protocol running EIGRP & Connected with defualt Fast Ether BW & DLY R2 ----------------------R4 (4.4.4.4)R1======== R3-----------------------R4
Feasibility condtion : FD 158720 > AD 144640 or AD 144640 < 2 ="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="="Once" r2 =" FD="158720" 2 ="317440" r1="="="="="="="="" r1="="="="="="">R2======>R4 ===Lo4 10 10 500
R1=======>R3======>R4===Lo4 x 10 500
In Order to find X to get the Metric 317440
Desired Metric 317440 = 256{ 10^7/100000 + Total Delay }
=256{ 100 + ( X + 10 + 500 ) } =256 { X + 610 } X = 625

Router-ID

Router-id is important :

BGP & OSPF router-id & Synchonization Rule :

ALL router running OSPF
R3(300)=====R4(100)=======R5(100)
dis syn dis syn

R5
router bgp 100
synchronization ( only apply to IBGP)
bgp log-neighbor-changes
neighbor 4.4.4.4 remote-as 100
neighbor 4.4.4.4 update-source Loopback5
no auto-summary

R4
router bgp 100
synchronization
bgp log-neighbor-changes
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 update-source Loopback4
neighbor 172.16.34.3 remote-as 300
no auto-summary

R3 (ASBR)
router ospf 1
log-adjacency-changes
redistribute connected subnets

int lo3
ip add 3.3.3.3 255.255.255.0

router bgp 300
no synchronization
bgp log-neighbor-changes
network 3.3.3.0 mask 255.255.255.0
neighbor 172.16.34.4 remote-as 100
no auto-summary
==================================================
Now Check the routing table : 3.3.3.0 is advertised as expected :
R4#sh ip bgp
BGP table version is 2, local router ID is 4.4.4.4
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
*> 3.3.3.0/24 172.16.34.3 0 0 300 i
R4#
==========================================================
Received by R5 as expected :
R5#sh ip bgp
BGP table version is 1, local router ID is 5.5.5.5
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.0/24 172.16.34.3 0 100 0 300 i

R5#sh ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 0
Paths: (1 available, no best path)
Not advertised to any peer
300
172.16.34.3 (metric 65) from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, internal, not synchronized ( hum....)

Per Synchonization rule router should have learn the route through IGP( in our Case OSPF)

Let's check :

R5#sh ip route 3.3.3.0
Routing entry for 3.3.3.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 65
Last update from 172.17.45.4 on FastEthernet0/0, 00:11:46 ago
Routing Descriptor Blocks:
* 172.17.45.4, from 3.3.3.3, 00:11:46 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1

Hum.. Route is indeed learn by IGP( OSPF)


Well, Not only route need to learn through IGP , but Router-id needs to match as well:
In our Case ASBR Router ID(3.3.3.3) & IBGP peer Router-id (4.4.4.4) not matching.
Please not that this is trying to match router-id on the route(3.3.3.0) learn & with different routing protocol :
R4

router ospf 1
router-id 44.44.44.44 ( I have to change router-id otherwise it will give issue with OSPF neighbor between R3 & R4)
log-adjacency-changes

router bgp 100
synchronization
bgp router-id 4.4.4.4 ( IBGP router-id)
bgp log-neighbor-changes
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 update-source Loopback4
neighbor 172.16.34.3 remote-as 300
no auto-summary

R3
router ospf 1
router-id 4.4.4.4 ( this is not typo I am setting ASBR router id to match IBGP router-id)
log-adjacency-changes
redistribute connected subnets
router bgp 300
no synchronization
bgp log-neighbor-changes
network 3.3.3.0 mask 255.255.255.0
neighbor 172.16.34.4 remote-as 100
no auto-summary
==========================================================================
After chaning the this router-id
R5#sh ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Flag: 0x820
Not advertised to any peer
300
172.16.34.3 (metric 65) from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, internal, synchronized, best

R5#sh ip route 3.3.3.0
Routing entry for 3.3.3.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 65
Last update from 172.17.45.4 on FastEthernet0/0, 00:00:07 ago
Routing Descriptor Blocks:
* 172.17.45.4, from 4.4.4.4, 00:00:07 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1

Bgp Peering

how bgp peering works :

Server Client Relashionship :

If Router A & Router B have Bgp relashionship than who will initiate connection :

By default,Highes BGP Router-id will initiate connection :

For example :

Rourter A(lo4:4.4.4.4/24)<===>Router B(lo5 5.5.5.5/24)
Server Client

To verify which side is Server or Client Currenlty :

sh tcp brief :
65B92ED8 5.5.5.5.21337 4.4.4.4.179 ESTAB
=============================================================
if you issue clear ip bgp * one of the side ( for example Router A) ,it will Initiate Connection :
if you issue clear ip bgp * at both side than you will see above output ( Higher router-id will become client ).

If you want to prevent one side to initiate the connection than there is couple of option :
Assumption : using loopback on both side :

R4 <=======>R5

R4 :
config t
router bgp 100
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 ebgp-multihope
neighbor 5.5.5.5 transport connection-mode passive( will not initiate connection)

Obviosuly on R5 you can use neighbor 4.4.4.4 tranport connection-mode active ( to actively initiate connection)


R5

config t
router bgp 100
neighbor 4.4.4.4 remote-as 100
neighbor 4.4.4.4 ebgp-multihope
neighbor 4.4.4.4 transport connection-mode active