Cisco and Juniper – BGP MPLS L2VPN VPLS interoperability

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/

Sample IOSXR RPL for small ISP

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

 

ICMP

As far as I understand according to rfc by ietf, type 11 is ’time exceeded.’  And there are 2 codes with that type.  Here is a link for the RFC792:

http://tools.ietf.org/html/rfc792

 

ICMP TYPE NUMBERS

The Internet Control Message Protocol (ICMP) has many messages that
are identified by a "type" field.

Type	Name					Reference
----	-------------------------		---------
  0	Echo Reply				 [RFC792]
  1	Unassigned				    [JBP]
  2	Unassigned				    [JBP]
  3	Destination Unreachable			 [RFC792]
  4	Source Quench			 	 [RFC792]
  5	Redirect				 [RFC792]
  6	Alternate Host Address			    [JBP]
  7	Unassigned				    [JBP]
  8	Echo					 [RFC792]
  9	Router Advertisement			[RFC1256]
 10	Router Selection			[RFC1256]
 11	Time Exceeded				 [RFC792]
 12	Parameter Problem			 [RFC792]
 13	Timestamp				 [RFC792]
 14	Timestamp Reply				 [RFC792]
 15	Information Request			 [RFC792]
 16	Information Reply			 [RFC792]
 17	Address Mask Request                     [RFC950]
 18	Address Mask Reply			 [RFC950]
 19	Reserved (for Security)			   [Solo]
 20-29	Reserved (for Robustness Experiment)	    [ZSu]
 30	Traceroute				[RFC1393]
 31	Datagram Conversion Error		[RFC1475]
 32     Mobile Host Redirect              [David Johnson]
 33     IPv6 Where-Are-You                 [Bill Simpson]
 34     IPv6 I-Am-Here                     [Bill Simpson]
 35     Mobile Registration Request        [Bill Simpson]
 36     Mobile Registration Reply          [Bill Simpson]
 37     Domain Name Request                     [Simpson]
 38     Domain Name Reply                       [Simpson]
 39     SKIP                                    [Markson]
 40     Photuris                                [Simpson]
 41-255 Reserved				    [JBP]
Many of these ICMP types have a "code" field.  Here we list the types
again with their assigned code fields.

Type    Name                                    Reference
----    -------------------------               ---------
  0     Echo Reply                               [RFC792]

        Codes
            0  No Code

  1     Unassigned                                  [JBP]

  2     Unassigned                                  [JBP]

  3     Destination Unreachable                  [RFC792]

	Codes
	    0  Net Unreachable
	    1  Host Unreachable
            2  Protocol Unreachable
            3  Port Unreachable
            4  Fragmentation Needed and Don't Fragment was Set
            5  Source Route Failed
            6  Destination Network Unknown
            7  Destination Host Unknown
            8  Source Host Isolated
            9  Communication with Destination Network is
               Administratively Prohibited
           10  Communication with Destination Host is
               Administratively Prohibited
           11  Destination Network Unreachable for Type of Service
           12  Destination Host Unreachable for Type of Service
           13  Communication Administratively Prohibited      [RFC1812]
           14  Host Precedence Violation                      [RFC1812]
           15  Precedence cutoff in effect                    [RFC1812]


  4     Source Quench                            [RFC792]
        Codes
            0  No Code

  5     Redirect                                 [RFC792]

        Codes
            0  Redirect Datagram for the Network (or subnet)
            1  Redirect Datagram for the Host
            2  Redirect Datagram for the Type of Service and Network
            3  Redirect Datagram for the Type of Service and Host

  6     Alternate Host Address                      [JBP]

        Codes
            0  Alternate Address for Host

  7     Unassigned                                  [JBP]

  8     Echo                                     [RFC792]

        Codes
            0  No Code

  9     Router Advertisement                    [RFC1256]

        Codes
            0  No Code

 10     Router Selection                        [RFC1256]

        Codes
            0  No Code

 11     Time Exceeded                            [RFC792]

        Codes
            0  Time to Live exceeded in Transit
            1  Fragment Reassembly Time Exceeded

 12     Parameter Problem                        [RFC792]

        Codes
            0  Pointer indicates the error
            1  Missing a Required Option        [RFC1108]
            2  Bad Length


 13     Timestamp                                [RFC792]

        Codes
            0  No Code

 14     Timestamp Reply                          [RFC792]

        Codes
            0  No Code

 15     Information Request                      [RFC792]

        Codes
            0  No Code

 16     Information Reply                        [RFC792]

        Codes
            0  No Code

 17     Address Mask Request                     [RFC950]

        Codes
            0  No Code

 18     Address Mask Reply                       [RFC950]

        Codes
            0  No Code

 19     Reserved (for Security)                    [Solo]

 20-29  Reserved (for Robustness Experiment)        [ZSu]

 30     Traceroute                              [RFC1393]

 31     Datagram Conversion Error               [RFC1475]

 32     Mobile Host Redirect              [David Johnson]

 33     IPv6 Where-Are-You                 [Bill Simpson]

 34     IPv6 I-Am-Here                     [Bill Simpson]

 35     Mobile Registration Request        [Bill Simpson]

 36     Mobile Registration Reply          [Bill Simpson]

 39     SKIP                                    [Markson]

 40     Photuris                                [Simpson]

 

Catalyst 6500/7600 MPLS Exp bits

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.

ASR9k berichten

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

ASR-90x releasenotes

Release Notes for the Cisco ASR 900 Router

http://www.cisco.com/c/en/us/td/docs/routers/asr903/release/notes/asr903_3S_rel_notes.html

http://www.cisco.com/c/en/us/products/collateral/routers/asr-903-series-aggregation-services-routers/data_sheet_c78-715296.html


“Cisco IOS XE on Cisco ASR 920 Series Router (ASR-920-24SZ-IM) supports upgradeable firmware for field programmable hardware devices such as interface modules (IMs) and upgrades IM FPGA when ever there is an upgrade.”

http://www.cisco.com/c/en/us/td/docs/routers/asr920/hardware/chassis/guide/ASR920-Chassis-SW/SW_Install_Upgrade.html

 

ASR920 FPGA version support is explained a little more here; http://www.cisco.com/c/en/us/td/docs/routers/asr920/release/notes/ASR920_rel_notes/intro.html


show facility-alarm status

System Totals  Critical: 0  Major: 0  Minor: 0


 

> It seems quite scalable and seems to have a nice path to higher

> density ethernet with the RSP3 supporting (8) 10 gig, (2) 40 gig and

> (1) 100 gig

 

Yea, the 10G port density is pretty awesome with RSP3.  100Gig IMA requires CPAK though.

 

>

> What do y’all know about this 902,903,907 ?   I want it for my

> distribution/aggregation of L2 and L3, vpls (manual and bgp ad), vpnv4

> and future vpnv6.

 

Right now, we roll 903, 902 and 920s for simple L2 Metro-E backhaul, nothing fancy and it works really well for us.  We also use it for VPLS and no problem there either.

 

The only caveat we ran into is lack of hash options for LACP/port-channels.  Not really easy to load-balance if a subscriber has LACP’d bundle into one of these.  There is no support for 5-tuple hash, nor MPLS label hash like on Cat65/68k Sup2T or ASR 9k series on bundles; you only get src-dst IP/mac.

 

 

Lastly, (it’s not really ASR 90x problem) it uses IOS XE, which means if you are running 6PE and have ASR 90x in the label switching path, it will reply to IPv6 traceroute with FFFF::ipv4, instead of using IPv6 address you have configured in the transiting interfaces on the box.  We typically configure IPv6 interface on core interfaces, even if we’re running 6PE and have no IPv6 routing protocols in the core.

On IOS XR, NXOS and JUNOS, P routers in the path will always pick the configured interface IPv6 address to respond to v6 traceroute; IOS XE and Classic will always pick FFFF::ipv4 and it’s quite annoying as it breaks traceroute on several operating systems (i.e. FreeBSD) that conform to RFC which does not permit FFFF:: from the wire.

1 4 5 6 7 8 14