Access-List Vs Prefix-List...Which One Is Better

I often See People New to Prefix-list trying to compare it with our old well know Access-Lists. Though Prefix-Lists makes life easier when it comes to Route Filtering but there are few things which you can't do with Prefix-Lists. Here are few details which you would definitely wanna go through if you are going for CCIE R&S soon.

http://ieoc.com/forums/p/21419/169502.aspx

HTH...
Deepak Arora
Evil CCIE

Best CCNA Training In Market For Free - Till 31st December 2011

Yet again INE surprises their customer with Free Access to best CCNA Training in Industry till 31st December, 2011. Since the product is executed and compiled by Brian McGahan so you guys just don't worry at all about quality of material you gonna get. IMHO there will be no match. Here are the URLs :

http://www.ine.com/all-access-pass/training/playlist/ccna-routing-switching-exam-course/introduction-10021222.html

http://www.ine.com/flashcards/

More Details : http://blog.ine.com/2011/11/17/ccna-rs-exam-course-and-ccna-rs-video-flashcards-free-streaming-video-access/

HTH...

Deepak Arora

Evil CCIE

BGP Client-Server Communication - How Does It Work ?

I am sure these days most of CCNP or CCNP+ people knows that BGP is technically an APPLICATION not a routing protocol which runs on top of TCP. As an application it can carry many sorts of information inside with IPv4 prefixes being one among them.


Also in past we discussed here about another important fact that BGP is a CLIENT-SERVER designed based application. Now important question comes in mind is - How do we determine which side is SERVER and which side is CLIENT.


Lets try to figure it out and see how things work:


Here is the quick topology we are going to use:

So lets do the basic configuration before we dig deeper. In first case we will establish EBGP Peering Between R1 & R2 over Serial0/0 interface on both sides.


===========================================


^^^ R1 ^^^
#########



R1(config)#int lo0
R1(config-if)#ip add 11.11.11.11 255.255.255.255
R1(config-if)#exit
R1(config)#int s0/0
R1(config-if)#ip add 12.12.12.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#exit
R1(config)#int s0/1
R1(config-if)#ip add 112.112.112.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#exit
R1(config)#router bgp 1
R1(config-router)#no au
R1(config-router)#no sync
R1(config-router)#nei 12.12.12.2 remote-as 2
R1(config-router)#net 11.11.11.11 mask 255.255.255.255
R1(config-router)#exit



^^^ R2 ^^^

#########

R2(config)#int lo0

R2(config-if)#ip add 22.22.22.22 255.255.255.255

R2(config-if)#exit

R2(config)#int s0/0

R2(config-if)#ip add 12.12.12.2 255.255.255.0

R2(config-if)#no sh

R2(config-if)#exit

R2(config)#int s0/1

R2(config-if)#ip add 112.112.112.2 255.255.255.0

R2(config-if)#no sh

R2(config-if)#exit

R2(config)#router bgp 2

R2(config-router)#no au

R2(config-router)#no sync

R2(config-router)#nei 12.12.12.1 remote-as 1

R2(config-router)#net 22.22.22.22 mask 255.255.255.255

R2(config-router)#exit

===========================================

$$$ <- Verification -> $$$

####################

R1#sh ip bgp summ | b N 
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
12.12.12.2      4     2       8       8        3    0    0 00:01:08                                1


R2#sh ip bgp summary | b N
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
12.12.12.1      4     1       5       5        3    0    0 00:01:30                                 1


R1#ping 22.22.22.22 so lo0


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/11/20 ms

So far everything looks good. Our peering is up and we are able to exchange prefixes just fine.

===========================================

Now next step is to verify which side is server and which side is client and does being SERVER vs being CLIENT affects something.

From the RFC point of view, the side with higher RID will be "CLIENT" and router with lower RID (Router ID) will be chosen as "SERVER". It's going to be the CLIENT which will initiate connection towards SERVER from some random source port towards destination TCP port 179.

This is a very important piece of information in case there is any device in middle of two BGP speakers blocking traffic like firewall, proxy etc. In such case you know now in which direction you need to open which ports.

But as far real world is concerned :-)

things might behave little different. Actually the fact I explained above only comes into play when both BGP speaker start talking to each other at same time in first place. If one BGP speaker is already up and you bring another BGP speaker up in later, in such case things may be seen as opposite.

So It's important to figure out which side is SERVER & which one is CLIENT.

Ummm.... Actually it's simple. There are many IOS command to figure it out but one being my favorite one is " show tcp brief ". What are the other ones ? .... hehehe :-) go figure

R1#sh tcp brief   

TCB                Local Address                  Foreign Address              (state)

64AF469C      12.12.12.1.51473               12.12.12.2.179              ESTAB

R2#sh tcp brief

TCB                Local Address           Foreign Address        (state)

64AF406C      12.12.12.2.179          12.12.12.1.51473       ESTAB

So looking at the output for R1 you can see that R1 is initiating a TCP session with source IP as 12.12.12.1 with source port as 51473 with destination IP as 12.12.12.2 with destination port as 179.

This very much tells us that R1 is the CLIENT here and R2 is the SERVER. It also support the other fact I mentioned above that it's not always necessary that the device with higher RID will be client and initiator of the connection.

R1#sh ip bgp | i ID

BGP table version is 3, local router ID is 11.11.11.11

R2#sh ip bgp | i ID

BGP table version is 7, local router ID is 22.22.22.22

Also one more important piece of information I would like to mention here is that in BGP it's only the SERVER side which need to receive BGP connection from the valid source matching it's local NEIGHBOR statement. For CLIENT side it is not necessary.

Lets try to verify if this is true:

R1config)#no router bgp 1 

R1(config)#router bgp 1 

R1(config-router)#no au

R1(config-router)#no sync

R1(config-router)#nei 112.112.112.2 remote 2

R1(config-router)#nei 112.112.112.2 update s0/0

R1(config-router)#net 11.11.11.11 mask 255.255.255.255

R1(config-router)#exit

R2(config)#no router bgp 2

R2(config)#router bgp 2

R2(config-router)#nei 12.12.12.1 remote 1

R2(config-router)#no au

R2(config-router)#no sync

R2(config-router)#net 22.22.22.22 mask 255.255.255.255

R2(config-router)#exit

So though local neighbor statement has been changed, but R2 (Server) still sees the BGP communication coming out from valid source IP of 12.12.12.2 which is same as mentioned in it's local BGP communication. But that's not the case for R1 which has neighbor statement for 

112.112.112.112 though the BGP connection it sees is coming from 12.12.12.1 with update source address not modified over R2 for it.

*Mar  1 02:07:14.203: %BGP-5-ADJCHANGE: neighbor 12.12.12.1 Up 

R1#sh tcp brief

TCB                 Local Address           Foreign Address        (state)

64B379E4      12.12.12.1.58558        112.112.112.2.179      ESTAB

R1#sh ip bgp summ | b N

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

112.112.112.2   4     2       6       6        3    0    0 00:02:23                              1

R1#sh ip bgp | b N

   Network          Next Hop            Metric LocPrf Weight   Path

*> 11.11.11.11/32   0.0.0.0                  0              32768     i

*> 22.22.22.22/32   112.112.112.2            0             0      2 i

R1#ping 22.22.22.22 so lo0

Type escape sequence to abort.

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

Packet sent with a source address of 11.11.11.11 

!!!!!

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

HTH...
Deepak Arora
CCIE - 0::0/0 Null0

EIGRP Variance & Unequal Cost Load Balancing Demystified - With Little GNS Bug

It's been a month since I posted my EIGRP challenge lab:


http://deepakarora1984.blogspot.com/2010/10/eigrp-challenge-lab-1.html


So today it's time to show you how to do it. I won't be spending much time today in explaining theory behind all this as so many people have already written about it but of-course that doesn't mean they covered it from all aspects.


But still I'll provide some reference links in the end of this post to make sure you don't have any gaps regarding concepts.


So lets load the initial configurations which I provided in original post and lets get started :


Note: Click Images To Enlarge

so far we can see the route is in routing table of R4, but we don't see redundant path as yet because of it's higher cost.


Lets calculate variance to install redundant route in routing table:


For those who don't understand variance yet here is the link:


http://www.networkworld.com/community/node/29966


Lets first examine the difference between two metrics that belong to both links for same route:

Now to calculate the required variance use the equation: Higher FD / Lower FD, and result will be:

As variance can't be fractional, so we need to take higher value, which will be 4


Lets's use variance value 4 and take a look at routing table:

Looks like both routes now have made it to routing table. So first objective is achieved. Now lets take a look at Traffic Share Count for both links for same route:

so as you can see that current traffic share count is 21:80. Traffic share count is inversely proportional to metric difference between both links.


So next step is to somehow make it as 1:1 :-)


As you might be thinking that Mr. Garcia (Creator Of EIGRP) should be around :-)

so lets take a look at first how much difference is there between both metrics:

Now lets subtract the lower metric from higher metric: By Metric I mean FD AKA RD:

So the difference comes as - 30000128


Now in next step lets add this metric to link with lower metric using "offset-list".

Here offset List calling ACL "0" means matching all routes... just for your sake :-)


Lets check again different EIGRP tables and see if it works:

Duhhh....looks like GNS is creating pain in butt again.... tired of GNS bugs :-(

Actually to over come this issue I had to jump to real equipments with same configuration and here are the results:

Though IOS ver "15.x" was not liking somehow idea of offset-list 0, so I had to create a specific ACL for this route:

So all functional and we have traffic share count of 1:1 between both links though they have different bandwidth.


Some more interesting reads on EIGRP or I should say "Must" read documents on EIGRP Load Balancing:


http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094823.shtml

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094820.shtml

http://www.cisco.com/en/US/tech/tk827/tk831/technologies_white_paper09186a00800a62d9.shtml

http://www.cisco.com/en/US/products/hw/modules/ps2033/prod_technical_reference09186a00800afeb7.html/

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009437d.shtml

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c2d96.shtml

HTH...
Deepak Arora

Finding EIGRP Peer's AS Number & K Values - Who's behind the mask ?

Today I am gonna show you guys a mean trick which I learned during a class way back. It's about finding EIGRP Peer's AS Number & K Values in order to form neighbor-ship.


Lets first discuss the topology and load the initial configuration for this lab.

                                                             Click Image to enlarge


so here is the quick topology, We have two routers namely R1 & R2. Router R1 is configured inside some Mysterious EIGRP AS ( like some BB router in Lab with no mention of it's EIGRP AS number in diagram). Now we need to make R2 (to which we have access) to peer with R1.


But before that lets load the initials. From Initials you may see what's the EIGRP AS number for R1 :-) but just pretend you don't know anything :-)


Although it's one of those things which might be hard for someone Vs others 
:-)


=====================
           *** Initials ***
=====================



^^^ R1 ^^^
!
en
!
conf t
!
no ip domain-lo
!
ho R1
!
int l0
ip add 1.1.1.1 255.255.255.255
exit
!
int f0/0
ip add 12.0.0.1 255.255.255.0
no sh
exit
!
router eigrp 12
no au
net 1.1.1.1 0.0.0.0
net 12.0.0.1 0.0.0.0
end
!
-------------------------------

^^^ R2 ^^^
!
en
!
conf t
!
no ip domain-lo
!
ho R2
!
int l0
ip add 2.2.2.2 255.255.255.255
exit
!
int f0/0
ip add 12.0.0.2 255.255.255.0
no sh
end
!
-------------------------------

Now lets get started

Lets first verify basic reachability to R1

R2#ping 12.0.0.1

Type escape sequence to abort.

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

!!!!!

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

Hmmm....everything looks good so far.

Now lets create two ACLs to match EIGRP traffic coming from and going towards R1.

Source of this packet is although going to be 12.0.0.1 from R1's generated EIGRP packet with destination as 224.0.0.10 (Well Known All EIGRP Routers multicast address), but I am going a little less specific without any particular reason :-)

Same logic you can follow for R2

R2(config)#access-l 100 permit ip any ho 224.0.0.10 log 

Now lets move is to debug ip packet with dump keyword which is BTW a hidden keyword and basically gives you Hex Dump of packet which you can later analyze with any packet sniffer.

R2#debug ip pack detail 100 dump

IP packet debugging is on (detailed) (dump) for access list 100

Now next step is to listen to EIGRP packets and for that we gonna enable EIGRP on router with some dummy AS number for a moment.

R2(config)#router eigrp 1  

R2(config-router)#no au

R2(config-router)#net 2.2.2.2 0.0.0.0

R2(config-router)#net 12.0.0.2 0.0.0.0

R2(config-router)#end

As soon as we do this we start getting following debug messages on screen:

*Mar  1 00:18:13.323: IP: s=2.2.2.2 (local), d=224.0.0.10 (Loopback0), len 60, sending broad/multicast, proto=88

0C600850:                   45C0003C 00000000          E@.<....

0C600860: 0258D39C 02020202 E000000A 0205EECB  .XS.....`.....nK

0C600870: 00000000 00000000 00000000 00000001  ................

0C600880: 0001000C 01000100 0000000F 00040008  ................

0C600890: 0C040102                             ....            

*Mar  1 00:18:14.111: IP: s=12.0.0.1 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88

0C9CA8A0:                       0100 5E00000A            ..^...

0C9CA8B0: C2000607 00000800 45C0003C 00000000  B.......E@.<....

0C9CA8C0: 0158CC9F 0C000001 E000000A 0205EEC0  .XL.....`.....n@

0C9CA8D0: 00000000 00000000 00000000 0000000C  ................

0C9CA8E0: 0001000C 01000100 0000000F 00040008  ................

0C9CA8F0: 0C040102                             ....            

Okay...don't get scared right now :-)

Lets Analyze the debug output and see how we can find AS number in that.

All you have to do is that first of all find the following keyword in Hex dump - 

" E000000A" , now from there count 5 blocks of Hex characters which in first hex dump is going to be "00000001" & in second hex dump it's "0000000C", now next thing to watch out for is direction or more importantly source of packet. In first dump it's "2.2.2.2" which is loopback of local router on R2. So which means its locally generated packet. Now lets get back to 5th Hex block for this packet "00000001". Now as I said It's in Hex format. Now convert this back to Decimal and you will find value as "1". Which is telling us that local AS number configured is "1". So far so good...

Now lets take a look at 5th Hex block from next Hex dump which is "0000000C". Convert this back to Decimal using Windows calculator and you will find out the value comes as "12".

Now lets remove the old config and put EIGRP AS 12 on R2 and see if magically peering comes up.

R2#sh ip ro e

R2#             <- No Neighbor

R2(config)#no router eigrp 1

R2(config)#router eigrp 12  

R2(config-router)#no au

R2(config-router)#net 2.2.2.2 0.0.0.0

R2(config-router)#net 12.0.0.2 0.0.0.0

R2(config-router)#exit

R2(config)#

*Mar  1 00:21:43.627: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 12.0.0.1 (FastEthernet0/0) is up: new adjacency

Gr8...

R2#sh ip eigrp nei

IP-EIGRP neighbors for process 12

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   12.0.0.1                Fa0/0             13 00:00:25    9   200  0  3

R2#sh ip ro e     

     1.0.0.0/32 is subnetted, 1 subnets

D       1.1.1.1 [90/409600] via 12.0.0.1, 00:00:50, FastEthernet0/0

R2#ping 1.1.1.1

Type escape sequence to abort.

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

!!!!!

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

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

Now Next mean trick is to find K-Values of neighbor in order in-case we need to peer with Any EIGRP neighbor which has different K-Values instead of default one.

Let's Change Local K Values over R2 now and see if we can figure it out sitting over R1.

R2(config)#router eigrp 12

R2(config-router)#metric weights 0 0 0 1 0 0 

As soon as we run this command we see following messages over R2's console:

R2(config-router)#

*Mar  1 00:23:53.607: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 12.0.0.1 (FastEthernet0/0) is down: metric changed

*Mar  1 00:23:58.191: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 12.0.0.1 (FastEthernet0/0) is down: Interface Goodbye received

*Mar  1 00:24:21.139: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 12.0.0.1 (FastEthernet0/0) is down: K-value mismatch

Now Lets take a look at R1:

R1#

*Mar  1 00:24:02.983: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 12.0.0.2 (FastEthernet0/0) is down: K-value mismatch

*Mar  1 00:24:07.695: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 12.0.0.2 (FastEthernet0/0) is down: K-value mismatch

*Mar  1 00:24:12.339: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 12.0.0.2 (FastEthernet0/0) is down: Interface Goodbye received

Ok...

In order to do some debugs over R1 first of all I must turn this logging off to make life easier else I'll keep getting these messages all the time.

R1(config)#router eigrp 12

R1(config-router)#no eigrp log-neighbor-changes 

R1(config-router)#end

Now Lets create same kind of ACL we made earlier over R2 but being more specific this time :-)

R1(config)#access-l 100 per ip ho 12.0.0.2 ho 224.0.0.10 log

R1#debug ip pack detail 100 dump

IP packet debugging is on (detailed) (dump) for access list 100

R1#

*Mar  1 00:29:55.959: %SEC-6-IPACCESSLOGRP: list 100 permitted eigrp 12.0.0.2 -> 224.0.0.10, 1 packet 

*Mar  1 00:29:55.959: IP: s=12.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88

0C9CB7A0:                       0100 5E00000A            ..^...

0C9CB7B0: C2010607 00000800 45C0003C 00000000  B.......E@.<....

0C9CB7C0: 0158CC9E 0C000002 E000000A 0205EFC0  .XL.....`.....o@

0C9CB7D0: 00000000 00000000 00000000 0000000C  ................

0C9CB7E0: 0001000C 00000100 0000000F 00040008  ................

0C9CB7F0: 0C040102         

BTW... Did I tell you guys that EIGRP does have it's own transport protocol which is RTP and defined as IP Protocol number 88 ? :-)

Ok...Getting back to idea of finding K-Values.

In this hex dump we need to leave last two block of hex characters (from bottom side this time ) completely, from 3rd block we just need to use "two" most significant characters and need to pick entire "4th" block from bottom.

Now in this case each "two" digits in hex specifies one K value. let me break it further for significance of you guys.

00 -> 0 -> K1

00 -> 0 -> K2

01 -> 1 -> K3

00 -> 0 -> K4

00 -> 0 -> K5

So from this it's clear that all other K values are set to zero except K3 being as 1.

Lets configure these K-Values locally on R1 and see if magical peering comes up back.

R1(config)#router eigrp 12

R1(config-router)#eigrp log-neighbor-changes 

R1(config-router)#metric weights 0 0 0 1 0 0

R1(config-router)#

*Mar  1 00:34:13.259: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 12.0.0.2 (FastEthernet0/0) is up: new adjacency

R1#sh ip ei n    

IP-EIGRP neighbors for process 12

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

0   12.0.0.2                Fa0/0             14 00:00:23    8   200  0  15

R1#sh ip ro e

     2.0.0.0/32 is subnetted, 1 subnets

D       2.2.2.2 [90/153600] via 12.0.0.2, 00:00:34, FastEthernet0/0

R1#ping 2.2.2.2 r 3 so lo0

Type escape sequence to abort.

Sending 3, 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 (3/3), round-trip min/avg/max = 4/5/8 ms

HTH...

Deepak Arora