Thank you for the response. Its very detailed, and I am yet to understand it completely.
Following is the problem I am facing on Ericsson Routers.
(static route) Router1---------------------------------------------------------------------Router2 ip route 202.1.1.0/24 null0 cost 9
In this 2 router topology, I have imported a static route 202.1.1.0/24 with cost 9.
And I am giving the following redistribute command on Router1, and later observe show ip route command on Router2
PROTOCOL COMMAND (in Router1) COST (Router2) OBSERVATION
ISIS #redistribute static 10 default #redistribute static metric 7 mertic-type external 17 configured in redist + 10 #redistribute static metric 7 mertic-type internal 17 configured in redist + 10
What is observed is, it completely ignores the cost (9) that is configured with the static route. In case of OSPF, they consider cost 9 also. So, I have a doubt, whether ISIS RFC describes to ignore the route cost? Or it is just implementation dependent.
Regards, Savyasachi 7676077879
On Thu, Apr 21, 2011 at 2:14 PM, Vitkovsky, Adam <avitkovsky@emea.att.com>wrote:
Isis doesn't have type-1 and type-2 external routes It has something similar though Metric of a prefix can be marked as internal metric or external metric
These are my isis notes section regarding internal and external:
the metric type for ext(redistributed) routes can be set as int/ext -by default internal metric is asigned during redistribution if nothing is specified
ext metric has the I/E bit set -bit 7 => higher metric value +64 -------------------------------------- but cisto doesn't set bit 7 but bit 8 -when narrow metric is used bit 8 of the metric field is set by cisco => external metric than appears to be increased by 128 -------------------------------------- _____________________________________________________________________ Narrow metric: 8th bit is S-bit -support for qos metrics (only 0 is supported) 7th bit is the internal/external bit And the remaining 8 bits are for the metric
1b 1b 6bits => max 63 values 0 i/e default metric value 1 i/e delay metric value 1 i/e expense metric value 1 i/e error metric value -------neighbor ID--------
Internal is default on cisco If you set external the bit 7 is set -thus the metric appears to be +64 higher compared to the same route redistributed as internal
______________________________________________ TLV specified by ISO 10589 contain metric info: ES neighbor type 2 IS neigh tyep 3 prefix neigh type 5
______________________________________________ TLV specified by RFC 1195 contain metric info: ip internal reachability type 128 ip external reachability type 130
__________________________________________________________ ISIS metric extensions
extended IS reachability tlv type 22 extended ip reachability tlv type 135 and trafic engineering rotuer ID tlv type 134
-the borrowed the metric fields for delay, expense, error -as they are not used
-but the first S-bit and the I/E-bit remained So the same apply to the extended metric as well
These are my notes form the labs: _____________________________________________________________ R1 route-map static-routes permit 10 match ip address prefix-list static-routes ! router isis 1 redistribute static ip route-map static-routes metric-type external level-1
-everything explicitely set in the redistribute cmd _____________________________________________________________ R2 route-map static-routes permit 10 match interface Null0 set metric-type external set level level-1 ! router isis 1 redistribute static ip route-map static-routes
-everything set in the route-map used during the redistribution _____________________________________________________________
R7#sh isis dat ver
IS-IS Level-1 Link State Database: LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL R1.00-00 0x00000007 0x23CA 642 1/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: R1 IP Address: 1.1.1.1 Metric: 10 IP 13.0.0.0 255.255.255.0 Metric: 10 IP 17.0.0.0 255.255.255.0 Metric: 0 IP 1.1.1.1 255.255.255.255 Metric: 10 IS R7.00 Metric: 0 IP-External 200.10.0.0 255.255.255.0 Metric: 0 IP-External 200.20.0.0 255.255.255.0 Metric: 0 IP-External 200.30.0.0 255.255.255.0 R2.00-00 0x00000015 0x5DA2 1049 1/0/0 Area Address: 49.0001 NLPID: 0xCC Hostname: R2 IP Address: 2.2.2.2 Metric: 10 IP 24.0.0.0 255.255.255.0 Metric: 10 IP 27.0.0.0 255.255.255.0 Metric: 0 IP 2.2.2.2 255.255.255.255 Metric: 10 IS R7.00 Metric: 64 IP-External 200.10.0.0 255.255.255.0 Metric: 64 IP-External 200.20.0.0 255.255.255.0 Metric: 64 IP-External 200.30.0.0 255.255.255.0
-so definition of external metric in redistribution cmd did not touch the metric -not sure how come it's still marked as ext -as the bit 7 or 8 should have been set
-and definition of external metric in route-map did set the bit 7 of the metric -thus we see increase in metric of 64
-but none of the cmds have set the bit 8 as stated in the book :)
adam
-----Original Message----- From: Savyasachi Choudhary [mailto:savyasachi.choudhary@gmail.com] Sent: Thursday, April 21, 2011 8:56 AM To: nanog@nanog.org Subject: Doubt in ISIS
I have a doubt in ISIS. While redistributing routes from other protocols, how the metric is decided? OSPF has deccribed this in RFC 2328 Section 16.4 :
'4) Let X be the cost specified by the preferred routing table
entry for the ASBR/forwarding address, and Y the cost specified in the LSA. X is in terms of the link state metric, and Y is a type 1 or 2 external metric.
(5) Look up the routing table entry for the destination N. If no entry exists for N, install the AS external path to N, with next hop equal to the list of next hops to the forwarding address, and advertising router equal to ASBR. If the external metric type is 1, then the path-type is set to type 1 external and the cost is equal to X+Y. If the external metric type is 2, the path-type is set to type 2 external, the link state component of the route's cost is X,
and the type 2 cost is Y.'
What is the behavior in ISIS? Regards, Savyasachi 7676077879