Inter AS Type B problem

Unanswered Question
Jun 3rd, 2008
User Badges:


I am jayanthan, new to this forum, seeking a solution for a problem on implementing a type B inter AS.

Two MPLS Autonomous Systems, AS1 and AS2 connected via ASBR1 and ASBR2. ASBR1 and PE1 belongs to AS1 and ASBR2 and PE2 belongs to AS2. There is a PE to CE Head office link running eigrp as PE-CE protocol in PE 1 and two branch offices in one in ASBR2 and another in PE2. Both use static route as PE-CE protocol.

I receice a default route and some networks via the Head Office Eigrp neighbour. They are propagated perfectly to ASBR2 and PE2 in AS2.

Problem is,

From ASBR2:

I can access all Head Office Blocks (Both Networks which are in the VRF routing table and via default route). I used the PE-CE interface IP as source.

From CE router connected to ASBR2:

I am unable to reach any IP Networks via the default route(which are not advertised to eigrp by customer). Customer likes to access these blocks via the default route. But I can reach the IP blocks advertised via eigrp and they exist in the VRF routing table of ASBR2.

I used PE-CE WAN interface IP as source.

Please consider i used source IPs from the PE-CE WAN block in both cases. once traceroute it stops in the gateway(ASBR2).

From PE2:

I can access all Head Office Blocks (Both Networks which are in the VRF routing table and via default route).

From CE router connected to PE2:

I can access all Head Office Blocks (Both Networks which are in the VRF routing table and via default route).

I believe there is a bug or fault in the concept. IS it possible to aggregate customers in ASBRs? if so are there any problem with using the vrf default route received form the neighbor ASBR to forward the traffic?

I believe u would be able get an idea about my problem.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Harold Ritter Tue, 06/03/2008 - 07:46
User Badges:
  • Cisco Employee,


If you can reach these destinations from the ASBR, you should also be able to reach them from a CE behind the ASBR. Can you verify whether the CE has the proper routes to destination.


jayanthan Tue, 06/03/2008 - 08:07
User Badges:


Thanks for your response. That's the unexpected behaviour. Once i traceroute from the CE connected to ASBR2, ASBR2 replies with the PE-CE WAN IP. But then no more reply from other hops.

And it is working for a non ASBR router in AS2. For PE2 it is working fine.

And for ASBR CE all BGP vrf routing entries are reachable other than the default route.



Harold Ritter Tue, 06/03/2008 - 10:02
User Badges:
  • Cisco Employee,


This is obviously not the expected behaviour.

Can you post the output of a "show ip cef vrf internal" from ASBR2.

Also, what level of code are you running on ASBR2?


jayanthan Tue, 06/03/2008 - 19:21
User Badges:

ASBR2#sh ip cef vrf DTL_IT_INFRA internal, version 262, epoch 0, cached adjacency (0x0A9CEA20)

0 packets, 0 bytes

tag information set, all rewrites owned

local tag: VPN route head

fast tag rewrite with Gi1/0/0,, tags imposed {1881}

via, 0 dependencies, recursive

next hop, GigabitEthernet1/0/0 via (Default)

valid cached adjacency (0x0A9CEA20)

tag rewrite with Gi1/0/0,, tags imposed {1881}

refcount 2057, directly covers other prefixes is the neighbour ASBR ebgp WAN IP. No 'next-hop-self' used for ASBR - RR IBGP.

I am sorry, not understand what you means by 'level of code'.

I've checked both VPN and Nexthop labels from ASBR2 to PE1. Seems to be OK.

Harold Ritter Wed, 06/04/2008 - 04:19
User Badges:
  • Cisco Employee,


The CEF entry for the default route looks good. Can you do a "show tag for tag 1881 det" on ASBR1.

What I meant by level of code was the IOS version.


jayanthan Wed, 06/04/2008 - 07:14
User Badges:


Thanks for your interest and support, also we have opened a TAC case;

P2 SR608774593 CE Pending

ASBR1#show mpls forwarding-table labels 1881 detail

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or VC or Tunnel Id Switched interface

1881 2748[V] 31652 Gi0/1

MAC/Encaps=14/22, MRU=1596, Label Stack{438 2748}

001192BF6940001E7955841B8847 001B600000ABC000

VPN route: MTN

No output feature configured

ASBR1#show ip cef vrf MTN de, epoch 0

local label info: other/1881

DefNet source:

recursive via label 2748

nexthop GigabitEthernet0/1 label 438

and the IOS versions of ASBR1 and ASBR2 are,

ASBR1: Version 12.2(31)SB10 - 7200 NPG1

ASBR2:Version 12.0(32)SY4 - GSR



jayanthan Fri, 06/06/2008 - 07:30
User Badges:

Hi hritter,

This case is still not resolved by the cisco TAC and they have forwarded this to a development team.

They expect some kind of forwarding issue in GSR engine 5 for the default route received via MP BGP.

Thanks a lot for your support. You may view the result using the above case ID o i would update you once the problem has been sorted out.

Thank you.



Harold Ritter Fri, 06/06/2008 - 07:48
User Badges:
  • Cisco Employee,


Thanks for the update. I will keep an eye on this case and will get in touch with TAC if I can help.


chintan-shah Wed, 07/09/2008 - 07:20
User Badges:


Just want to know if you have recevied any update from Cisco TAC on this issue.



jayanthan Wed, 07/09/2008 - 19:39
User Badges:


They found a BUG in the running code of GSR. But still i did not received any recommended action plan to solve the problem. Please find the root cause of the problem as updated from cisco.

"TCAM entries with default route entry is ahead of actual entry & pointing to null adjacency"

Therefore DE Engineer confirms that there is problem in line code software & they will be working on fix.

Still working.




This Discussion