06-03-2008 12:17 AM
Hi,
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.
Regds,
jaya.
06-03-2008 07:46 AM
Jaya,
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.
Regards,
06-03-2008 08:07 AM
Hritter,
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.
regds,
jaya.
06-03-2008 10:02 AM
Jaya,
This is obviously not the expected behaviour.
Can you post the output of a "show ip cef vrf
Also, what level of code are you running on ASBR2?
Regards,
06-03-2008 07:21 PM
ASBR2#sh ip cef vrf DTL_IT_INFRA 0.0.0.0 0.0.0.0 internal
0.0.0.0/0, version 262, epoch 0, cached adjacency 10.25.2.253 (0x0A9CEA20)
0 packets, 0 bytes
tag information set, all rewrites owned
local tag: VPN route head
fast tag rewrite with Gi1/0/0, 10.25.2.253, tags imposed {1881}
via 10.25.2.253, 0 dependencies, recursive
next hop 10.25.2.253, GigabitEthernet1/0/0 via 10.25.2.253/32 (Default)
valid cached adjacency (0x0A9CEA20)
tag rewrite with Gi1/0/0, 10.25.2.253, tags imposed {1881}
refcount 2057, directly covers other prefixes
10.25.2.253 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.
06-04-2008 04:19 AM
Jaya,
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.
Regards,
06-04-2008 07:14 AM
hritter,
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 0.0.0.0/0[V] 31652 Gi0/1 10.151.21.2
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 0.0.0.0 0.0.0.0 de
0.0.0.0/0, epoch 0
local label info: other/1881
DefNet source: 0.0.0.0/0
recursive via 10.151.3.254 label 2748
nexthop 10.151.21.2 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
Rgds
jaya.
06-06-2008 07:30 AM
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.
Rgds,
jaya
06-06-2008 07:48 AM
Jaya,
Thanks for the update. I will keep an eye on this case and will get in touch with TAC if I can help.
Regards,
07-09-2008 07:20 AM
Hi,
Just want to know if you have recevied any update from Cisco TAC on this issue.
Regards,
Chintan
07-09-2008 07:39 PM
Hi,
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.
Rgds,
Jaya.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide