cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
992
Views
0
Helpful
10
Replies

Inter AS Type B problem

jayanthan
Level 1
Level 1

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.

10 Replies 10

Harold Ritter
Cisco Employee
Cisco Employee

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

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.

Jaya,

This is obviously not the expected behaviour.

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

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

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

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.

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

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.

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

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hi,

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

Regards,

Chintan

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: