Sweet!  This guy had the answer I was looking for…

https://supportforums.cisco.com/discussion/11517026/inter-vpls

 

…an RFC4761 trick in IOS XR fixed the missing mtu on my ASR9k when trying to setup LSP’s to Juniper.

 

******** this is what fixed it************* l2vpn  autodiscovery bgp

signaling-protocol bgp

mtu mismatch ignore

***********************************

 

…now pw’s are up (and I can ping from BVI on asr9k to ce’s behind junipers

 

RP/0/RSP0/CPU0:eng-lab-9k-1#sh l2v br gr v100 Sat Dec  5 22:49:06.395 CST

Legend: pp = Partially Programmed.

Bridge group: v100, bridge-domain: v100, id: 11, state: up, ShgId: 0, MSTi:

0

Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog

Filter MAC addresses: 0

ACs: 1 (1 up), VFIs: 1, PWs: 3 (3 up), PBBs: 0 (0 up)

List of ACs:

BV100, state: up, BVI MAC addresses: 1

List of Access PWs:

List of VFIs:

VFI v100 (up)

Neighbor 10.101.12.245 pw-id 10100, state: up, Static MAC addresses: 0

Neighbor 10.101.12.248 pw-id 10100, state: up, Static MAC addresses: 0

Neighbor 10.101.12.250 pw-id 10100, state: up, Static MAC addresses: 0

 

 

…pw’s are up even though junipers don’t seem to be sending the asr9k their mtu size.

 

RP/0/RSP0/CPU0:eng-lab-9k-1#sh l2v br gr v100 de | in MTU Sat Dec  5 22:49:12.265 CST

Bridge MTU: 1500

MTU 1514; XC ID 0x80000015; interworking none

MTU          1500                           unknown

MTU          1500                           unknown

MTU          1500                           1500

 

 

 

_______________________________________________

cisco-nsp mailing list  cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp

archive at http://puck.nether.net/pipermail/cisco-nsp/

Setting up a pair of Cisco ASRs for an small ISP. Each ASR has a connection to an upstream ISP. The ASRs are also connected to downstream customers with BGP. Am looking for some sample route-policies. The route policies should prevent the ISP from becoming transit for the entire Internet, but still be transit for the downstream customers.

The syntax may not be exactly correct, but the below gives a rough outline of a relatively simple setup using communities. You can use a prefix-set or as-path-set with all the prefixes/asns you advertise to filter outbound to transit instead of communities (or in addition to), but communities will scale better in the long run. There may be better ways to do it but this should give a good start.

— Apply to customer(s) —

Route-policy fulltable-out

If destination in bogons then

Drop

elseif community matches-any ( “LOCALPREFIX”, “CUSTPREFIX”, “PEERPREFIX, “TRANSITPREFIX” ) then

Pass

Endif

End-policy

 

Route-policy asCUSTASN-in

If destination in asCUSTASN then

Set community CUSTPFX

Endif

End-policy

 

Prefix-set asCUSTASN

CUS.PFX.A.0/20 le 24,

CUS.PFX.B.0/24,

Etc…

End-set

 

— Apply to Transit —

 

Route-policy transit-in

If destination in bogons then

Drop

Else

Set community TRANSITPREFIX

endif

End-policy

 

Route-policy transit-out

If destination in bogons then

Drop

elseif community matches-any ( “LOCALPREFIX”, “CUSTPREFIX” ) then

Pass

endif

End-policy

 

prefix-set bogons

0.0.0.0/8 le 32,

10.0.0.0/8 le 32,

100.64.0.0/10 le 32,

127.0.0.0/8 le 32,

169.254.0.0/16 le 32,

172.16.0.0/12 le 32,

192.0.0.0/24 le 32,

192.0.2.0/24 le 32,

192.168.0.0/16 le 32,

198.18.0.0/15 le 32,

198.51.100.0/24 le 32,

203.0.113.0/24 le 32,

224.0.0.0/4 le 32,

240.0.0.0/4 le 32,

0.0.0.0/0 ge 25

end-set

 

AC and there is no command to see packet hit counters per queue to see how many packets are matching into each queue (the equivilent of “show policy-map interface x/x” on a device using HQF).

 

The best commands I found where:

 

show mls qos ip Gi2/17

show mls qos queuing int Gi2/17

show mls qos queuing interface Gi2/17 | b dropped show counters interface Gi2/17 remote command switch show qm port 2 17 show interfaces | i Ethernet|output drop

 

---

like below (on 7606-S)

 class-map match-all PLATINUM
  match mpls experimental topmost 5
 class-map match-all GOLD
  match mpls experimental topmost 3
 class-map match-all SILVER
  match mpls experimental topmost 1

 policy-map EXPMAP
  class PLATINUM
  class GOLD
  class SILVER
  class class-default

 interface vlan 1700
  service-policy output EXPMAP

To recap:

Traffic comes in via transit provider attached to 7600-PE1, label is

pushed, traffic is label switched over to 7600-PE2, PE2 PoPs label and

sends IP traffic to customer.

Packets are coming from the transit provider with a DSCP making and

being sent over to the customer with a DSCP marking. I’m was trying to

set the incoming packets to DSCP 0 on PE1 first, with a policy-map

with “set DSCP 0” which didn’t work. Then without a policy map the

port is by default in a state of un-trust as mls qos is enabled

gobally. Still this didn’t work.

By default the 7600/PFC is operating in short pipe mode:

http://www.cisco.com/c/en/us/td/docs/routers/7600/ios/15S/configuration/guide/7600_15_0s_book/mplsqos.html#pgfId-1405948

Switching to uniform mode work, using the global config command “mls

mpls qos input uniform-mode”.

Now PE1 will set DSCP 0 on the incoming transit packets however, even

in short pipe mode, if the port is untrusted I would have expected the

DSCP to be set to 0. It seems in short pipe mode no actions can be

made against the DSCP/ToS value at ingress only egress.

-=-=-=-=-=-=-

It shouldn’t be necessary in your situation, but I’m curious if adding
“platform ip features sequential” on the ingress interfaces where
marking is occurring would help. This should only be necessary if you
are marking on ingress and then taking action on the new marking in
the same box. It should have zero bearing on if the packet is actually
re-marked on egress, but it might be worth a shot for troubleshooting
purposes.

Interesting, I didn’t know that command so I’m reading about it now.

TAC have asked if I can add a policy with “set mpls experimental
imposition 0”, I guess there logic is something like:

Traffic comes in via transit provider attached to 7600-PE1, label is
pushed, label switched over to 7600-PE2. PE1 has pushed the label
before setting DSCP so the DSCP isn’t being removed (maybe the DSCP
removal actually happens on egrees of the incomming line card into the
crossbar or something like that, not as soon as the packet comes into
the port ASIC, but since this packet gets a label pushed maybe that
also happens before the packet egresses the line card into the
crossbar so the DSCP isn’t removed when the packet leaves the line
card becasue it’s now a labelled packet).

However they haven’t explained why I should do this, so I’ve thrown it
back at them to explain.

-=-=-=-=-=-

TAC have confirmed this is more or less a bug with the platform and

there is an internal bag case CSCuw80912 which the developers have

looked at. There is no intention to fix this though as it seems to be

some sort of limitation of the way the PFC hardware works.

It seems “mls mpls qos input uniform-mode” toggles uniform mode and

also performs some additional steps internally so that the PFC can set

re-write DSCP on ingress, to work around the issue.

http://www.warisinfo.com/my-presentations

split horizon groups, which is more clear.

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-1/lxvpn/configuration/guide/lesc51x/lesc51p2mps.html#68334

Setting up 802.q and switch ports in an ASR9000

http://www.brianraaen.com/2012/01/17/setting-up-802-q-and-switch-ports-in-an-asr9000/

Acl Based Forwarding

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r3-9-1/general/release/notes/rlse_a9k_392.html#wp433672

ASR900 Webinar

http://www.warisinfo.com/technology-tutorials