AI, ML, Development + Cisco Learning Blog Learning about Machine Learning, Artificial Intelligence, related devlopment topics and formerly Routing and Switching, Datacenter, Security and other topics, CCIE #23664, Frank Wagner

15. August 2009

RIP authentication with IOS

Filed under: IGP Routing — ocsic @ 12:54

What i have seen with rip auth, is that it depends in what order you set the commands for rip auth.

  • First you have to enter the key chain „key chain RIP“ „…“
  • After you have to enter first on the interface „ip rip authentication key-chain RIP“
  • And then you can enter the encryption mode „ip rip authentication mode md5“

If you change any of this in order, it might not work and you have to re-apply your configs. Btw. not many are using RIP these days, but better to know for the lab, cause it’s still there.

Check always with „debug ip rip“, if authentication works!

23. Februar 2009

OSPF authentication types

Filed under: IGP Routing,OSPF — ocsic @ 13:50

Just for rememberance, but might be important to know the type of authentication in the lab. OSPF know three different kind of authentications. Well to be honest, there are more, but only the first three are defined:

Type Authentication RFC

0        No Authentication                          [RFC1583]
1        Simple Password Authentication             [RFC1583]
2        Cryptographic authentication               [RFC2328]
3-65535  Unassigned

Important, OSPF know key rollover only for encrypted keys. If you have several neighbors with different key, rollover works on one interface, but only for encrypted keys. Wit EIGRP this is not possible. You will need a new interface for more than one neighbor with a different key.

Example for two neighbors with different encrypted keys each (sync can last up to 20 minutes, you have to be patient!):
int s1/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 CISCO1
ip ospf message-digest-key 2 md5 CISCO2

To configure type „0“ authentication use:

s1/0

ip ospf authentiation null

Source:

http://www.iana.org/assignments/ospf-authentication-codes

4. November 2008

ip prefix-list

Filed under: IGP Routing,IP and IOS Features — ocsic @ 12:35

I had to look at prefix-lists again a bit more in detail and how matching is done.

There are several key words that need to be understood for mathing the right addresses.

At first the most simple match is the:

ip prefix-list PRE_20 permit 20.0.0.0/24

which does just match for the first 24 bit in the address and nothing else.

If in case you have to match more addresses, maybe a range from subnets with a specific prefix, you can match it with „ge“ or „le“.

„ge“ means greater or equal

„le“ means less or equal

So if you want to match the following subnets:

20.0.0.0/16

20.1.0.0/16

You could create an prefix list with the following match:

ip prefix-list PRE_20 permit 20.0.0.0/15 ge 16 le 16

This means, that first the matching is done one the subnet that is the same for all subnets: 20.0.0.0/15, that can include 20.0.0.0 and 20.1.0.0.

Here we already summarized the best match for both addresses. So this part is the same for all addresses. Then, since we don’t want to match the 20.0.0.0/15 or the 20.1.0.0/15, we have to tell the prefix list, how to extend the variable match for addresse, that should be included in the match.

Se we want specially matches greater or equal /16 and maximal /16.

That means:

ip prefix-list PRE_20 permit 20.0.0.0/15 ge 16 le 16

If we want to include for example only:

20.0.0.0/24

20.0.1.0/24

20.0.2.0/24

20.0.3.0/24

ip prefix-list PRE_22 permit 20.0.0.0/22 ge 24 le 24

Another example would be to match a range of subnets with „le“

ip prefix-list 20.0.0.0/16 le 18

Would match:

20.0.0.0/16

20.0.0.0/17

20.0.0.0/18

Where the 20.0. prefix must be in all network ranges at a minimum and every address with a maximum of /18 would match if 20.0. is in the prefix.

19. September 2008

ospf network definition for adding all interfaces / default route

Filed under: IGP Routing,OSPF — ocsic @ 14:30

What’s the difference?

router ospf 1

network 0.0.0.0 0.0.0.0 area 0

vs.

router ospf 1

network 0.0.0.0 255.255.255.255 area 0

Both add all existing interfaces into area 0 and all later added interfaces also. Both statements are valid.

For the default route it seems the same:

ip route 0.0.0.0 0.0.0.0 f1/1

vs.

ip route 0.0.0.0 255.255.255.255 f1/1

both work, sending traffic to the default gatewayf f1/1.

What IOS does not permit is a mixture for example.:

0.0.0.0 0.0.255.255

or

0.0.0.0 0.255.255.255

SW1(config)#ip route 0.0.0.0 0.0.255.255 f1/1
%Inconsistent address and mask

Both statements are the same. Since both have the same logical „AND“ing result for the host part, namely „0“.

0 0 0 0 0 0 0 0

1 1 1 1 1 1 1 1

———————-

0 0 0 0 0 0 0 0

vs.

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

———————-

0 0 0 0 0 0 0 0

1. September 2008

eigrp and leak-map

Filed under: IGP Routing — ocsic @ 17:25

A quite new feature for eigrp is the possibility of a leak-map. It’s simmiliar to the unsupress-map in BGP. As there is different behavior for the route-map statement if missconfigured, there is a way to send the summary and also all routes included in the summary.

ip summary-address eigrp 1 10.0.0.0 255.0.0.0 leak-map RM_LEAK

route-map RM_LEAK

An empty route-map will send the summary and also all component routes.

If the route-map is missing completelyit has no effect and the summary is send.

This would be a way to send the summary and also all components with the summary.

ip summary-address eigrp 1 10.0.0.0 255.0.0.0 leak-map RM_LEAK

ip prefix-list PRE_150 seq 5 permit 150.1.2.0/24

route-map RM_LEAK

match ip address prefix-list PRE_150

Like this only the summary 150.1.0.0/16 and the 150.1.2.0/24 network will be send to the neighbor.

Source:

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gt_esflr.html

10. Juli 2008

ip default-network vs. ip default-gateway

Filed under: IGP Routing,IP and IOS Features — ocsic @ 12:58

Every time a come across these commands i wonder what is the difference. Now i have looked it up … 🙂

„ip route 0.0.0.0 0.0.0.0 x.x.x.x“ and „ip default-network x.x.x.x“ are the same. They are used when „ip routing“ is enabled. If not use „ip default-gateway x.x.x.x“.

If you add the ip default-network command in EIGRP, you will see the D* in your routing table, as the candidate default. Even if this is not a route to null, it will be used from all routers as it. Seems like a remaining, from the IGRP times, when no summary with 0.0.0.0 0.0.0.0 was possible.

Source:

http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a008012d8f7.shtml#qa7

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

21. Dezember 2006

Calculation EIGRP delay for load balancing

Filed under: IGP Routing — ocsic @ 12:44
The defaults for K1 to K5 you can see with "sh ip prot"
Three
Rack1R1#sh ip prot
Routing Protocol is "eigrp 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 EIGRP maximum hopcount 100 EIGRP maximum metric variance 5 Redistributing: eigrp 100 EIGRP NSF-aware route hold timer is 240s Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 150.1.1.1/32 164.1.12.1/32 164.1.13.1/32 164.1.18.1/32 Routing Information Sources: Gateway         Distance      Last Update 164.1.12.2            90      01:24:30 164.1.13.3            90      01:24:30 164.1.18.8            90      01:24:30 Distance: internal 90 external 170  As you can see as by default K1 and K3 are one and all other values are 0. So from the formular only (K1*Bandwidth + K3*Delay) will count.  The complete formular for calculating metrics is: (107/Bandwidth + Delay/10)*256
While Bandwith is in Kbps and Delay in ms.

So then you just look at:

Rack1R2#sh ip eigrp top 164.1.26.0/24
IP-EIGRP (AS 100): Topology entry for 164.1.26.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600
Routing Descriptor Blocks:
0.0.0.0 (Ethernet0/0), from Connected, Send flag is 0x0
Composite metric is (281600/0), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 1000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
164.1.12.1 (Serial0/0.12), from 164.1.12.1, Send flag is 0x0
Composite metric is (3561472/3049472), Route is Internal
Vector metric:
Minimum bandwidth is 1280 Kbit
Total delay is 61000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3

Rack1R1#sh ip eigrp topology 164.1.26.0/24
IP-EIGRP (AS 100): Topology entry for 164.1.26.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3049472
Routing Descriptor Blocks:
164.1.13.3 (Serial0/1), from 164.1.13.3, Send flag is 0x0
Composite metric is (3049472/2537472), Route is Internal
Vector metric:
Minimum bandwidth is 1280 Kbit
Total delay is 41000  microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
164.1.12.2 (Serial0/0), from 164.1.12.2, Send flag is 0x0
Composite metric is (15247360/281600), Route is Internal
Vector metric:
Minimum bandwidth is 256 Kbit
Total delay is 204980 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1

You can see here Bandwidth and Delay for the local interface and the advertised interface from the EIGRP neighbor.

The question is to make the path from R1 to R3 5 times more choosen than from R1 to R2. That means, the metrics from R1 to R2 has to be 5 times lower than from R1 to R3. Or in other words:
5*MetricR3 = MetricR2

Then you can calculate with the given formular. (Note, for me Delay from R1 to R3 is 41000 and not 40100 like in the example from the Solutionguide.)

5*(107/1280 + 41000/10)*256 = (107/256 + DelayToR2/10)*256

5*(107/1280 + 41000/10) = (107/256 + DelayToR2/10)
5*(7812,5 + 4100) = (39062,5 + DelayToR2/10)
5*(7812 + 4100) = (39062 + DelayToR2/10)
5*11912 = 39062 + DelayToR2/10
59560 = 39062 + DelayToR2/10
20498 = DelayToR2/10
204980 = DelayToR2

Then for my i had to subtract the Delay from R2 (1000ms).

204980 - 1000 = 203980

Dividing it through 10 = 20398

delay for my int s0/0 from R1 to R2 is 20398. So if you see the metric from R1 to R2 and R3:

Rack1R1#sh ip eigrp topology 164.1.26.0/24
IP-EIGRP (AS 100): Topology entry for 164.1.26.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3049472
Routing Descriptor Blocks:
164.1.13.3 (Serial0/1), from 164.1.13.3, Send flag is 0x0
Composite metric is (3049472 /2537472), Route is Internal
Vector metric:
Minimum bandwidth is 1280 Kbit
Total delay is 41000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
164.1.12.2 (Serial0/0), from 164.1.12.2, Send flag is 0x0
Composite metric is (15247360/281600), Route is Internal
Vector metric:
Minimum bandwidth is 256 Kbit
Total delay is 204980 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1

3049472*5 = 15247360

That the feassible successor has a 5 times higher metric than the successor. With variance 5 you let this feassible successor also being installed as a valid path.

25. September 2006

EIGRP metrics calculation

Filed under: IGP Routing — ocsic @ 19:34

EIGRP is calculating metrics out of a summary of variables. Here is the formular for EIGRP metric calculation:

(K1*bandwidth+K2*bandwidth/256-load + K3*delay)

only if K4 and K5 are not zero the following operand is is also multiplied:

[k5/(reliability + k4)]

With the default setting on cisco routers the values K1=1 K2=0 K3=1 K4=0 K5=0. so metric is normaly calcuated out of K1*Bandwidth + K3*delay.

To calculate the metric use the following formular:

(10^7/bandwidth(Kbps) + delay(ms)/10)*256=metric

Use the sh ip eigrp topology [ROUTE-ENTRY] to see the setting for the route.

Source:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hirp_r/rte_eih.htm#wp1097416

http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hirp_r/rte_eih.htm#wp1099338

24. September 2006

Recursive routing problem

Filed under: IGP Routing — ocsic @ 06:39

This can happen, when the tunnel learns the destination of the tunnel through the tunnel itself.

You can save yourself by adding a static route or filter the route with a distribute-list for example.
*Mar 4 23:58:18.091: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
*Mar 4 23:58:18.163: %PIM-5-NBRCHG: neighbor 148.1.13.1 UP on interface Tunnel0 (vrf default)
Rack1R3#
*Mar 4 23:58:27.091: %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing
*Mar 4 23:58:28.091: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
*Mar 4 23:58:28.111: %PIM-5-NBRCHG: neighbor 148.1.13.1 DOWN on interface Tunnel0 (vrf default) non DR
Here is the setup of the scenario producing the error:

R1:

interface Tunnel0
ip address 148.1.13.1 255.255.255.0
tunnel source Loopback0
tunnel destination 150.1.3.3

R3:

interface Tunnel0
ip address 148.1.13.3 255.255.255.0
tunnel source Loopback0
tunnel destination 150.1.1.1

Both routers have learned through rip about the other destination interface. When the tunnel comes up, the also learn about the destination of the tunnel interface through rip.

To stop this, i have added on both sides the destination of the tunnel interface into a distribute list.

R1:

router rip
distribute-list 3 in Tunnel0
access-list 3 deny 150.1.3.0 0.0.0.255
access-list 3 permit any

R3:

router rip
distribute-list 1 in Tunnel0

access-list 1 deny 150.1.1.0 0.0.0.255
access-list 1 permit any

Source:

http://www.cisco.com/warp/public/105/gre_flap.html

18. September 2006

simple redistribution

Filed under: IGP Routing — ocsic @ 14:28

Redistribution is the technique to distribute one routing protocol into another. If you have two routing protocols, you can mutually distribute them into another to garanty reachability.

There are many possible scenarios for redistributiong one protocol into another one.

You could simple remember that there should be given a metric for the redistributed protocol. So if you want to redistribute rip into ospf for example, you must give a metric value when redistributing.

Redistributing from rip into ospf means, that on an ARB (area boarder router), where two routing protocols are running, you make the routes from each protocol usable to the other routing domain and vica versa.

router rip
redistribute ospf 1 metric 1

Here it means that you send all routes that are running under ospf process 1 to rip with a metric of 1.

So now the rip routing domain has all routes from the ospf domain also available.

To redistribute the other way:

router ospf 1
redistribute rip subnets metric 1

This will send all routes from the rip domain into the ospf domain under ospf process 1. It will also redistribute all routes with a metric of 1 and all subnets.

It’s very important to set the metric. If you don’t, you will not see any routes on the other side.

Older Posts »

Powered by WordPress