[c-nsp] EoMPLS from ME3750 to 7201 GigE sub-int

[Chris Phillips]

The MTU definitely needs to be the same, in my experience.  However, I 
am somewhat new to MPLS and am very much still in the learning process. 
  But, that would be the first thing that I would change.

Justin Shore wrote:
> I'm having trouble getting EoMPLS to work from a ME3750 to a 7201.  I 
> have some signaling but the VC just won't come up.  The basic layout is 
> a switchport on the ME3750; the xconnect is in the SVI associated with 
> that switchport on the ME3750.  The ME3750's P-facing interfaces are 
> MPLS enabled.  The 7600 core is MPLS enabled.  The 7201 dual-homes to 
> both core 7600s.  The 7201's interfaces are MPLS enabled.  I'm trying to 
> terminate the xconnect on a sub-int of an onboard interface that's 
> facing a 4948.  I have a laptop on the ME3750 and I'm mapping an access 
> int on the 4948 in the correct VLAN back across another network to my 
> office (so I don't have to sit in a noisy head-end).
> 
> Here's the ME3750's relevant config:
> 
> no mpls traffic-eng auto-bw timers frequency 0
> mpls label protocol ldp
> mpls ldp graceful-restart
> mpls ldp router-id Loopback0 force
> !
> vlan 130
>  name vlan0130.cox-ptp-EOMPLS
> !
> interface FastEthernet1/0/3
>  description TO Cox F.7 - 10Mbps Kan-Ed
>  switchport access vlan 130
>  switchport mode dot1q-tunnel
>  no keepalive
>  no cdp enable
>  spanning-tree portfast
>  spanning-tree bpdufilter enable
> !
> interface GigabitEthernet1/1/1
>  description TO 7613-1.clr Gi1/11
>  no switchport
>  ip address
>  ip router isis
>  mpls label protocol ldp
>  mpls ip
>  clns mtu 1496
>  isis circuit-type level-2-only
>  isis network point-to-point
>  isis metric 100
>  isis authentication mode md5
>  isis authentication key-chain ISIS-AUTH
>  isis bfd
> !
> interface Vlan130
>  description EoMPLS VC 130 to 7201-1.clr Gi0/2.130
>  no ip address
>  xconnect aaa.bbb.ccc.ddd 130 encapsulation mpls
> 
> 
> And here's the 7201's relevant config:
> 
> mpls label protocol ldp
> mpls ldp graceful-restart
> mpls ldp router-id Loopback0 force
> !
> interface GigabitEthernet0/2
>  description TO 4948-1.clr Gi1/45
>  mtu 9000
>  no ip address
>  duplex auto
>  speed auto
>  negotiation auto
> !
> interface GigabitEthernet0/2.130
>  description EoMPLS TO me3750-1.dc Vl130 (Fa1/0/3) - 10Mbps PtP
>  encapsulation dot1Q 130
>  xconnect 10.64.0.37 130 encapsulation mpls
> 
> 
> I'll skip the 4948 config but I'll say that vl130 is permitted on 
> Gi1/45, it has been created and it was assigned to my test access 
> interface.  None of the other VLANs served from sub-ints are having 
> trouble.
> 
> When I bring up the xconnect on the me3750 here's what it logs:
> 
> 000181: Jan 17 18:38:31.914 CST: AToM LDP [10.64.0.43]: Sending label 
> mapping msg
> 000182: Jan 17 18:38:31.914 CST: AToM LDP [10.64.0.43]: Sending label 
> mapping msg vc type 4, cbit 0, vc id 130, group id 0, vc label 231, 
> status 0x00000000/0x00000000, mtu 1500, peer vlan id 0   , vc handle 
> 0x18000001
> 
> Here's what I get on the 7201 when I unshut the sub-int:
> 
> 003629: Jan 17 18:39:26.401 CST: AToM LDP [10.64.0.37]: Sending label 
> mapping msg
> vc type 4, cbit 0, vc id 130, group id 0, vc label 223, status 0, mtu 
> 9000, peer vlan id 0
> 
> 
> Something just jumped out at me.  The MTUs are different.  Would that 
> cause an issue?  Gi0/2 on the 7201 is set to 9000 because hung off of 
> the 4948 is a set of backhaul radios that I will be doing MPLS across. 
> The customer-facing interface on the ME3750 is set to the default 1500. 
>  Do the MTUs have to match up?  I'm going to have to do some research.
> 
> Thanks
>  Justin
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
Chris Phillips