PE-CE Connectivity: Integrated IS-IS

[amr mubarak]

Dears,

I am having a question when we use ISIS as CE-PE routing protocol.I will use below topology for illustrating.

R1(CE)--->ISIS_Level-1-->R2(PE)--->MPLS_CORE-->PE2-->ISIS_Level-2-->CE2

I am using ISIS as CE-PE routing protocols at customer site at both ends (R1 &CE2) but when i redistributed MPBGP routes into isis i was expecting to receive interarrea routes in R1 routing table since MPLS BB acts as ISIS_Level3 but i received L1 External Routes which shown in routring table as intraarea routes and not interarea routes so please advise if this is normal behvior and why the routes weren't interarea routes.

Also there  ATT BIT  wasn't set on ISIS database of R2 (PE router ) to generate default route although at one site is Level-1 while remote site is Level-2 with different area

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

Below Snapshoots from R1 &R2

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

R1#sh isis database  R2.00-00 detail

IS-IS Level-1 LSP R4.00-00

LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL

R4.00-00              0x00000015   0x7045        1192              0/0/0

  Area Address: 49.0146

  NLPID:        0xCC

  Hostname: R4

  IP Address:   172.16.46.4

  Metric: 10         IP 172.16.46.0 255.255.255.0

  Metric: 10         IS R4.01

  Metric: 0          IP-External 172.16.0.2 255.255.255.255   <<<<<<< external route and not interarea route

  Metric: 0          IP-External 172.16.0.3 255.255.255.255

  Metric: 0          IP-External 172.16.0.5 255.255.255.255

  Metric: 0          IP-External 172.16.0.7 255.255.255.255

  Metric: 0          IP-External 172.16.0.20 255.255.255.255

-----------------------

R1#sh ip route isis

Gateway of last resort is not set

      172.16.0.0/16 is variably subnetted, 10 subnets, 2 masks

i L1     172.16.0.2/32 [115/10] via 172.16.46.4, 00:00:36, FastEthernet0/0.46

i L1     172.16.0.3/32 [115/10] via 172.16.46.4, 00:00:27, FastEthernet0/0.46

i L1     172.16.0.5/32 [115/10] via 172.16.46.4, 00:00:36, FastEthernet0/0.46

i L1     172.16.0.7/32 [115/10] via 172.16.46.4, 00:00:36, FastEthernet0/0.46

i L1     172.16.0.20/32 [115/10] via 172.16.46.4, 00:00:36, FastEthernet0/0.46

------------------------------------------------------

R2#sh run | s router isis   <<<< ISIS configuration on PE

ip router isis

router isis

vrf TEST

net 49.0146.0000.0000.0004.00

redistribute bgp 1248 level-1

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

Thanks

[Peter Paluch]

Hello,

Your IS-IS configuration on R2 takes BGP-learned routes and injects them into IS-IS Level-1 database. At this moment, it does not matter where the BGP-learned routes really come from and what is their original type or level. On R2, these routes are first learned by BGP and afterwards injected into IS-IS Level-1 as requested by the redistribute command. Even if those routes originally come from a different IS-IS area and level, on R2, they are learned only by BGP as BGP routes. The original properties of these routes have been lost at the moment of their injection into BGP on PE2. In other words, R2 has no clue that the BGP-learned routes once were IS-IS routes. That explains why the routes are recognized as external in Level-1.

Also, this explains why the ATT bit is not set on R2's LSP (although you are showing us the R4's LSP, not R2's - but I assume these two routers are indentically configured). Even though R2 is doing BGP-to-ISIS redistribution, it does not have any Level-2 ISIS adjacency to a router in a different area - therefore the ATT bit is not set.

It is, to my best knowledge, not possible to redistribute a route from a different protocol into IS-IS so that it is considered an inter-area route. Regarding the ATT bit, you can either control it using the set-attached-bit command, or you can directly inject a default-route into IS-IS using the default-information originate command; you will need to use a route-map with set level level-1 to make sure the default route is injected into Level-1.

By the way, I strongly suggest using wide metrics. Your output suggests you are still using narrow metrics.

Best regards,

Peter

[amr mubarak]

Hi Peter,

Thanks for attention for my question

Whiile reading "MPLS and VPN Architecture Volume Two Cisco Press" with ISIS CE-PE section ,i found the following

"With the introduction of an MPLS VPN backbone between VPN sites, an additional Level of

routing hierarchy (referred to as Level 3) above Level 2 has been added (similar to OSPF). This

additional level is required so that VPN sites can run independent IS-IS processes and learn

routes from other VPN sites without maintaining a direct adjacency with those sites" .After that it provide similar example of mine P184 if u having the book which shows the router receive routes as interarea routes instead of external when he changed ISIS Level Type of local site from L2 to L1 while keeping remote as L2.

This means that the BB isn;t a seperate domain which causing the routes to appear as external which it acts a OSPF case as SuperBAckbone area

[Peter Paluch]

Hello,

I have tried to reproduce your scenario but just like  in your case, I was not successful. The book you are referring to must  be quite outdated. Several commands from the book do not exist in the  15.3XB IOS I was testing (such as router isis area-tag vrf vrf-name, redistribute metric transparent, debug isis vrf)  - some of them have changed the syntax, the others are just gone.  In  addition, the BGP does not add any additional attributes to the routes  retaken from IS-IS, so when redistributing the routes back from BGP into  IS-IS, there is no information that would help the PE to know how to  recreate the IS-IS routes (OSPF and EIGRP add such information as a set  of extended attributes).

So what we see in the book can  not be reproduced on current IOSes. Regarding the inter-area routes, I  simply do not see how they could be automatically generated without  explicitly configuring route-leaking.

Best regards,

Peter

[amr mubarak]

Thanks Peter  ,i agree with you as i can only see this infromation in this book which was on 2003.

what get me go with this point is ISIS loop prevention mechanism.As mentioned as well in the book that redistributing from MPLS to ISIS will set the down bit which will avoid redistributing the route again in MPLS BB when the site is multihoming since the PE will drop the route with U/D bit set like the case of L1 to L2 leaking but unfotunately when i tested this case i found that the update redistributed again from ISIS to MPLS BB which means that the U/D isn't set.

This means that IPBB isn't consider as L3 area which was confirmed in the previous example when the routes didn't appear as interarea routers.My question here doesn't ISIS have a loop avoidance mechanism for mutual redistribution with MPLS BB. I am expecting that  if old IOS is having ISIS loop avoidance mechanism so it is supposed that the recent IOS will have the same

Thanks again Peter

[Peter Paluch · Accepted solution]

Hello,

I am also confused how did the example get into the book. IS-IS is currently not considered a mainstream PE-CE protocol with the usual set of features already implemented in OSPF or EIGRP. Apparently, there have been talks in IETF to extend IS-IS/BGP interaction with a functionality similar to OSPF, and there is even an Internet Draft here:

http://tools.ietf.org/html/draft-sheng-isis-bgp-mpls-vpn-00

The draft did not move to any further revision, sadly, and from what I can tell, it does not appear to be implemented in IOSes I am using. When I configured a simple MPLS L3VPN with the IS-IS as the PE-CE protocol, there were absolutely no additional attributes added to the BGP VPNv4 routes as specified by the aforementioned draft.

redistributing from MPLS to ISIS will set the down bit

The Down bit should be set if redistributing from Level-2 to Level-1. Unfortunately, as there seems to be no enhancement to BGP/IS-IS interaction, when redistributing from BGP into IS-IS, the Down bit is most probably not set, which is what you see yourself.

My question here doesn't ISIS have a loop avoidance mechanism for mutual redistribution with MPLS BB.

It certainly does not seem that there is any automatic loop avoidance mechanism. What you could do is set a tag when redistributing from BGP into IS-IS, and avoid redistributing the routes with this tag back from IS-IS to BGP. It is not that fancy but I guess it could work.

I am expecting that  if old IOS is having ISIS loop avoidance mechanism so it is supposed that the recent IOS will have the same

To be completely honest, I would love to know what IOS version and platforms have the book authors used to create and implement that scenario. I do not think Cisco would be throwing out this mechanism once they had it implemented.

Best regards,

Peter

[Vasilii Mikhailovskii]

Hello, community.

I know it's not the best time to answer the questions, but I think it's worth to post this information for those, who could review the topic in the future.

ISIS is NOT  supported as CE-PE protocol.

ISIS is supported only in VRF-lite (on some platforms, so review release notes first).

[Peter Paluch]

Hi Vasilii,

Yeah, it certainly seems so. Anyway, don't you think that IS-IS should become supported? The more we optimize OSPF, the more we get IS-IS :-P

Best regards,
Peter

[muhamsid]

Cisco doesn't support ISIS as PE-CE but as per draft

https://tools.ietf.org/html/draft-sheng-isis-bgp-mpls-vpn-00

BGP support carries some of the critical ISIS information as part of BGP extended communities, which can be converted into ISIS LSP. For example, if the original router was received as Level-1 it will be reconverted into an ISIS Level-1 at the other end PE

[mowasif]

Hello Experts,

I am doing re-design my customer network, can someone tell me how many routers we can have per IS-IS process.

How many processes, instances, routes supported by routers (ASR9K, ASR 903, ASR902, ASR901, ASR 920).

RSPs (RSP3, RSP1A and RSP2B).

I will be very thankful.

Mohammad Wasif