ASR920 – Rosen-VPN

Just to avoid the confusion regarding MVPN profiles in the future Cause NG-MVPN could be RSVP or mLDP based and there is Rosen in there as well So I suggest using descriptions:

 

Rosen-mGRE profiles (profiles- 0, 3,11)

Rosen-mLDP profiles (profiles- 1,9, 12, 13,17) mLDP profiles (profiles- 2,4,5,14,15) inband mLDP profiles (profiles- 6,7)

 

List of profiles:

Profile 0 Default MDT – GRE – PIM C-mcast Signaling Profile 1 Default MDT – MLDP  MP2MP  PIM C-mcast Signaling Profile 2 Partitioned MDT – MLDP MP2MP – PIM C-mcast Signaling Profile 3 Default MDT – GRE – BGP-AD – PIM C-mcast Signaling Profile 4 Partitioned MDT – MLDP MP2MP – BGP-AD – PIM C-mcast Signaling Profile 5 Partitioned MDT – MLDP P2MP – BGP-AD – PIM C-mcast Signaling Profile 6 VRF MLDP – In-Band Signaling Profile 7 Global MLDP In-band Signaling Profile 8 Global Static – P2MP-TE Profile 9 Default MDT – MLDP – MP2MP – BGP-AD – PIM C-mcast Signaling Profile 10 VRF Static – P2MP TE – BGP-AD Profile 11 Default MDT – GRE – BGP-AD – BGP C-mcast Signaling Profile 12 Default MDT –  MLDP – P2MP – BGP-AD – BGP C-mcast Signaling Profile 13 Default MDT – MLDP – MP2MP – BGP-AD – BGP C-mcast Signaling Profile 14 Partitioned MDT – MLDP P2MP – BGP-AD – BGP C-mast Signaling Profile 15 Partitioned MDT – MLDP MP2MP – BGP-AD – BGP C-mast Signaling Profile 16 Default MDT Static – P2MP TE – BGP-AD – BGP C-mcast Signaling Profile 17 Default MDT – MLDP – P2MP – BGP-AD – PIM C-mcast Signaling Profile 18 Default Static MDT – P2MP TE – BGP-AD – PIM C-mcast Signaling Profile 19 Default MDT – IR – BGP-AD – PIM C-mcast Signaling Profile 20 Default MDT – P2MP-TE – BGP-AD – PIM – C-mcast Signaling Profile 21 Default MDT – IR – BGP-AD – BGP – C-mcast Signaling Profile 22 Default MDT – P2MP-TE – BGP-AD BGP – C-mcast Signaling Profile 23 Partitioned MDT – IR – BGP-AD – PIM C-mcast Signaling Profile 24 Partitioned MDT – P2MP-TE – BGP-AD – PIM C-mcast Signaling Profile 25 Partitioned MDT –  IR – BGP-AD – BGP C-mcast Signaling Profile 26 Partitioned MDT – P2MP TE – BGP-AD – BGP C-mcast Signaling

 

For more info please refer to:

http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/multiprotocol-label-switching-vpns-mpls-vpns/118983-configure-mpls-00.html#anc48

as well as:

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-2/multicast/configuration/guide/b_mcast_cg42asr9k/b_mcast_cg42asr9k_chapter_01.html#concept_071C3FD3AAB24A57A9AA711FAE7BE78F

all the way down to:

Summary of Supported MVPN Profiles

 

draft rosen model, as stated here for IOS XE 3.17

http://www.cisco.com/c/en/us/td/docs/routers/asr920/release/notes/ASR920_rel_notes/new_features.html#pgfId-1085169

Cisco, Netwerk (C-NSP)

protected port

you could simply use the “protected port” feature.

Devices connected to a Protected port are not able to talk to each other, even if they are within the same vlan.

 

conf t

int gi 0/1

switchport mode access

switchport acess vlan x

switchport protected

spanning-tree portfast

 

The protected port feature only works local on a switch while private vlans could span over multiple switches. Much easier then configure private vlans and should work for your use case just fine

Cisco, Netwerk (C-NSP)

ASR1k Port-channel hash algo

Does the ASR1K not support layer-4 port # hash (src/dst IP + tcp ports) for port-channel load balancing?

All I can see that can be configured is src/dst IP:

 

asr1k(config)#port-channel load-balance-hash-algo ?

dst-ip       Destination IP

dst-mac      Destination MAC

src-dst-ip   Source XOR Destination IP Addr

src-dst-mac  Source XOR Destination MAC

src-ip       Source IP

src-mac      Source MAC

 

 

asr1k#sh etherchan load | in channel

Port-channel1                   :  flow-based (Source Destination IP)

 

Should be flow-based by default (just don’t configure anything else):

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/lanswitch/configuration/xe-3s/asr1000/lanswitch-xe-3s-asr1000-book/lnsw-flow-portchannel-load.html

 

Cisco, Netwerk (C-NSP)

Cisco netwerk overnames

Insieme is the skunkworks venture Cisco backed group they use for some new tech.   These guys operate outside Cisco and develop Product to eventually be bought / acquired.

 

Nx9k is the latest example.   I’m told the original catalyst and cat5k were similar.

No, the Catalysts were external acquisitions. Low end stuff like the 1900 came from Grand Junction, the 3K was Kalpana, and the 5K & 6K Crescendo.

>

> On Thu, Dec 31, 2015 at 04:17:07PM +0000, Justin Ream wrote:

>> As far as internal Cisco politics go: I’ve heard the situation has

>> changed with the new CEO. Nexus 7000/7700 sits in the same BU as

>> Cat6k. The Insieme/Nexus 9k guys operate in their own separate unit.

Cisco, Netwerk (C-NSP)

ASR920 – Service instance

 

This should be straigt forward.

Configure the trunk towards the 9k via Trunk EFP [1] and the port as per [2].

 

Config should look like this:

! slvans:

bridge-domain 1-5, 7, 9-12

!

interface gigabitethernet2/0/1

descr Trunk to ASR9k

service instance trunk 1 ethernet

encapsulation dot1q 1 – 5, 7, 9 – 12

rewrite ingress tag pop 1 symmetric

bridge-domain from-encapsulation

!

!

interface gigabitethernet2/0/2

descr Customer C-vlan range 100-200 in S-vlan 5  service instance 5 Ethernet

encapsulation dot1q 100-200

bridge-domain 5

 

[1] http://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/ce/b_ce_xe-313s-asr920-book/b_ce_xe-313s-asr920-book_chapter_00.html#GUID-FE6D829C-A814-46F3-A9E6-4AFC094AB066

[2] http://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/ce/b_ce_xe-313s-asr920-book/b_ce_xe-313s-asr920-book_chapter_01.html#ID-1384-00000345

 

Cisco, Netwerk (C-NSP)

IPv6 : Win7 vs Win8

Just an update: I eyeballed the “PrefixPolicies-Vista78.cmd” script from

https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies, concluded

that it was safe, and ran it. It apparently works, but I don’t have a

ULA setup to test it with.

jrey42 deserves kudos.

Regards

   Brian

On 21/12/2015 07:57, Brian E Carpenter wrote:

On 21/12/2015 03:28, Marc Luethi wrote:

Hi all

I suggest to investigate source address selection on the client side,

while closely following name resolution (assuming this is similar to

Windows 2012R2’s DA implementation, DNS64 is supposed to be at work, here)

and keeping an eye on the IPv6 routing table.

In your situation, I would presume that the end system ends up with an RFC

4193 address (from the /48 that was initially chosen when DA was set up) on

its *IP-over-HTTPS* tunneling interface (courtesy of the DA implementation)

and a global unicast address  the (W)LAN interface, based on the CPE’s RAs.

While things *should* be neat, my experience with Windows 7’s way of

picking source addresses was so bad (“longest match” seemed entirely

unheard-of), I eventually gave up using RFC 4193 addresses for my internal

network altogether.

I repeateadely observed Win7 using its global unicast address(es) to access

internal ressources, while stubbornly sticking to te RFC4193 source address

when attempting to talk to addresses on the global IPv6 internet.

Yes. Apparently Win8 is up to date in that respect (i.e. follows RFC6724 not

RFC3484). It would be possible to make Win8 misbehave by changing the default

preferences (https://tools.ietf.org/html/rfc6724#section-10.6).

Conversely, it’s possible to make Win7 behave correctly by changing its default

policies to conform to RFC6724. I just found the following site that offers a

script (YMMV, I haven’t checked it):

https://sites.google.com/site/jrey42/Home/ipv6/prefixpolicies

But if that is the cause of the original issue, maybe switching off the

ULA prefix would be easier, and nicer than switching off IPv6.

     Brian Carpenter

cheers

Marc

On 19 December 2015 at 22:37, Kurt Buff  wrote:

All,

I ran into an interesting situation some months ago which still

baffles me, and though I was able to work around it, I expect it will

happen again.

We implemented MSFT DirectAcess at our company quite some time ago

(using 2008R2 and Forefront 2010), and it works extremely well.

At least it worked well for everyone until one of the employees got

his Comcast connection upgraded, and then DirectAccess didn’t work for

that employee any more.

We proved that if he tethered to his cell phone, that would work, and

if he used an SSL VPN client while on his Comcast connect that would

work, but DirectAccess would not work at home.

Finally, I discovered that his Comcast-installed router was handing

our IPv6 addresses on his home LAN. Turning that off enabled

DirectAccess to work again.

We do not have an assigned IPv6 block from our ISP, though of course

MSFT OSes use it, and auto-assign themselves addresses, but for now

we’re ignoring it.

Has anyone run into this problem and solved it – not by turning off

iIPv6 address assignment for the home LAN, but really solved it? If

so, how did you do that?

Would getting and implementing an IPv6 assignment from our ISP cure

the problem, or make it worse?

I’ve found little guidance from MSFT about DirectAccess in an IPv6

environment, though I admit I haven’t been terribly diligent in my

searches.

Kurt

IPv6, Microsoft, Netwerk (C-NSP)

asr1000 nat logging

 

Show flow monitor exporter statistics

 

You need to use the show commands to see if the ASR thinks the traffic is leaving: What is the output of show flow exporter? I always find it’s something like “SE linux” on the collector, and this stops you from seeing it in tcpdump.

 

On my cisco asr1001x nat logging does not work.

I do not see traffic on collector with tcpdump.

I tryning soft:

System image file is “bootflash:/asr1001x-universalk9.03.12.01.S.154-2.S1-std.SPA.bin”

System image file is “bootflash:/asr1001x-universalk9.03.15.00.S.155-2.S-std.SPA.bin”

 

 

interface TenGigabitEthernet0/0/0

description Downlink-to-X670

ip address 10.254.253.18 255.255.255.252  no ip redirects  no ip unreachables  ip nat inside  ip flow monitor flow_v5 input  ip flow monitor flow_v5 output  service-policy type control CTRL-IPOE  ip subscriber routed

initiator unclassified ip-address

end

 

ip nat settings mode cgn

no ip nat settings support mapping outside ip nat settings pap limit 60 ip nat log translations flow-export v9 udp destination 10.0.0.122 9995 source TenGigabitEthernet0/0/0 ip nat log translations flow-export v9 vrf 0 on ip nat translation timeout 300 ip nat translation tcp-timeout 1800 ip nat translation pptp-timeout 1800 ip nat translation udp-timeout 60 ip nat translation finrst-timeout 10 ip nat translation syn-timeout 10 ip nat translation dns-timeout 10 ip nat translation icmp-timeout 10 ip nat translation port-timeout tcp 80 360 ip nat translation port-timeout tcp 8080 360 ip nat translation port-timeout tcp 1600 180 ip nat translation port-timeout tcp 110 180 ip nat translation port-timeout tcp 25 180 ip nat translation max-entries all-host 2000 ip nat pool NAT_POOL_18.19.142 18.19.142.0 18.19.142.254 netmask 255.255.255.0 ip nat inside source list ACL_NAT_18.19.142 pool NAT_POOL_18.19.142 overload

 

 

 

flow exporter carbon4_v5

destination 172.1.1.2

transport udp 9996

export-protocol netflow-v5

!

!

flow monitor flow_v5

exporter carbon4_v5

cache timeout inactive 10

cache timeout active 1000

record netflow-original

 

Cisco, Netwerk (C-NSP)

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/

Cisco, Netwerk (C-NSP)
1 … 6 7 8 9 10 … 21