POS interface not letting Labeled traffic pass through

Guys anyone seen this before, where "POS interface is not letting Labeled traffic pass through". 

 

I am testing in INE Lab with 3.9.1 IOS-XR Version on Full Scale Lab 4

 

Basic setup is: 

* R3-XR1-XR2, XR1-XR2 are in AS 1000 and R3 is in AS 3000

* R3 has eBGP + Label (send-label) with XR1, also XR1 has /32 static route to R3

* XR1 and XR2 are running IBGP + Label (labeled-unicast)

 

 

RP/0/3/CPU0:XR2#show mpls forwarding  | i PO

Fri Dec 13 20:32:31.995 UTC

16005  Pop         10.0.0.19/32       PO0/7/0/0.1920 10.19.20.19     2196       

       Pop         10.0.195.0/24      PO0/7/0/0.1920 10.19.20.19     0          

16009  16012       10.0.0.3/32        PO0/7/0/0.1920 10.19.20.19     1540       

       16013       10.0.0.4/32        PO0/7/0/0.1920 10.19.20.19     0          

RP/0/3/CPU0:XR2#

RP/0/3/CPU0:XR2#show run int pos0/7/0/0

Fri Dec 13 20:35:52.896 UTC

interface POS0/7/0/0

 encapsulation frame-relay

 frame-relay intf-type dce

!

 

RP/0/3/CPU0:XR2#show run int pos0/7/0/0.1920

Fri Dec 13 20:35:58.726 UTC

interface POS0/7/0/0.1920 point-to-point

 ipv4 address 10.19.20.20 255.255.255.0

 ipv6 address 2001:10:19:20::20/64

 pvc 1000

  encap cisco

 !

!

 

RP/0/3/CPU0:XR2#

 

RP/0/0/CPU0:XR1#show run int pos0/6/0/0.1920

Fri Dec 13 20:37:41.231 UTC

interface POS0/6/0/0.1920 point-to-point

 ipv4 address 10.19.20.19 255.255.255.0

 ipv6 address 2001:10:19:20::19/64

 pvc 1000

  encap cisco

 !

!

 

RP/0/0/CPU0:XR1#

 

RP/0/0/CPU0:XR1#debug mpls packet det location 0/6/CPU0

Fri Dec 13 20:39:22.006 UTC

RP/0/0/CPU0:XR1#

!! NO MPLS Packet coming in

 

RP/0/3/CPU0:XR2#ping 10.0.0.3 so 10.0.0.20 type 255 count 1000

Fri Dec 13 20:39:37.858 UTC

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:

..............

Success rate is 0 percent (0/14)

RP/0/3/CPU0:XR2#

 

! However, IP packets are allowed

RP/0/3/CPU0:XR2#ping 10.19.20.19

Fri Dec 13 20:40:33.163 UTC

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.19.20.19, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/15 ms

RP/0/3/CPU0:XR2#

RP/0/0/CPU0:XR1#debug icmp location 0/6/CPU0

Fri Dec 13 20:40:31.250 UTC

RP/0/0/CPU0:XR1#LC/0/6/CPU0:Dec 13 20:40:33.454 : ipv4_io[183]: Async msg code = <0>

LC/0/6/CPU0:Dec 13 20:40:33.457 : ipv4_io[183]: ip_icmp_lib_io:  pulse code 0 received

LC/0/6/CPU0:Dec 13 20:40:33.458 : ipv4_io[183]: ip_icmp_lib_ipv4_netio_input: code 0

LC/0/6/CPU0:Dec 13 20:40:33.458 : ipv4_io[183]: ip_icmp_lib_ipv4_receive: Receiving

LC/0/6/CPU0:Dec 13 20:40:33.459 : ipv4_io[183]: IPv4 ICMP: POS0/6/0/0.1920: Received echo request from 10.19.20.20

LC/0/6/CPU0:Dec 13 20:40:33.460 : ipv4_io[183]: IPv4 ICMP: POS0/6/0/0.1920: Sending echo reply to 10.19.20.20

LC/0/6/CPU0:Dec 13 20:40:33.461 : 

 

 

RP/0/0/CPU0:XR1(config)#int pos 0/6/0/0

RP/0/0/CPU0:XR1(config-if)#shut

RP/0/0/CPU0:XR1(config-if)#commit

LC/0/6/CPU0:Dec 13 20:41:10.679 : ifmgr[174]: %PKT_INFRA-LINK-5-CHANGED : Interface POS0/6/0/0, changed state to Administratively Down

RP/0/0/CPU0:Dec 13 20:41:11.846 : config[65750]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'xr1'. Use 'show configuration commit changes 1000006570' to view the changes.

RP/0/0/CPU0:XR1(config-if)#end

 

RP/0/3/CPU0:XR2#ping 10.0.0.3 so 10.0.0.20 type 255 count 1000

Fri Dec 13 20:41:19.122 UTC

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Comments

  • Just out of curiosity, do you have "next hop unchanged" between R4 and XR2's eBGP VPNV4 session? This was giving me a really weird issue similar to this in the data plane. 

  • I remember that. Yes, I had "next-hop unchanged" on XR2 (RR VPNv4). I could have tried removing it and then seeing the outcome (because I know for a fact that if you remove it, then somehow traffic originated by XR2 should be unlabeled)

     

  • Hi Abarick,

    the subinterface with F/R is just not supported. Check the F/R config for SONET interfaces and you will find that physical POS or bundles  are supported. In nowhere it is stated an explicit support to subinterfaces running F/R. If you try to modify the pos0/6/0/0.1920 to a ppp interface or a F/R physical interface you will see labels going through.

    You will get a similar impact in tasks regarding MPLS-TE

    Alessio

  • Good to know. Thanks for sharing the info. By the way, I am positive you can't configure frame-relay over phy POS int on XR. As in you can't configure "PVC" under phy POS int.

    RP/0/RSP0/CPU0:XR391(config)#int pos 0/0/0/0

    RP/0/RSP0/CPU0:XR391(config-if)#pv?

                                               ^

    % Invalid input detected at '^' marker.

    RP/0/RSP0/CPU0:XR391(config-if)#encapsulation frame-relay

    RP/0/RSP0/CPU0:XR391(config-if)#pv?

                                               ^

    % Invalid input detected at '^' marker.

Sign In or Register to comment.