Messages

Hm, thought I did mention my May CCDE attempt here.. maybe not. However, results came a couple of days ago, and PASS!

20190008.

[Cisco Content Security Management Appliance (SMA)]

Everything on the Pending investigation list has been moved to not vulnerable, except for Cisco Content Security Management Appliance (SMA) and Cisco Cloud Object Storage.

Passed CCDE written a couple of days ago, gonna do a month of vacation before I decide what to do with it. If nothing else, renewed all other certs until 2021

Is there a lab for that one, as well?

It is. It's different compared to the CCIE though as it is held only 4 times a year at specific Pearson sites.

Passed CCDE written a couple of days ago, gonna do a month of vacation before I decide what to do with it. If nothing else, renewed all other certs until 2021

I'll be there

Link aggregation are common practice across vendors yes, they might have different names for it though. LACP would be the standardized protocol to speak to manage the aggregate. (yes, do use signaling for this)

Probably need

set level 2 authentication-type md5

inside router isis.

Not trying to be the devils advocate here, but what is the purpose of an SVI with no interfaces attached? Sounds to me like a job for a loopback interface.

Not 'no interfaces attached', but 'only trunks'.

[access]

There's no need for an access interface to be up, a trunk works as well. The initial configuration should work, given that the VLAN exists.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swint.html#wp2040589

SVI Autostate Exclude
The line state of an SVI with multiple ports on a VLAN is in the up state when it meets these conditions:

•The VLAN exists and is active in the VLAN database on the switch.

•The VLAN interface exists and is not administratively down.

•At least one Layer 2 (access or trunk) port exists, has a link in the up state on this VLAN, and is in the spanning-tree forwarding state on the VLAN.

Pretty sure I have the last (port that's up, VLAN as an allowed member of the trunk), but was only able to get the VLAN up with a weird sequence of "shut/no shut" and "status active" commands.  Perhaps the STP part?  The other side of the trunk is a ubiquiti wireless AP in bridge mode, and one of the clients of that AP has a Netonix switch hanging off of it where these VLANs are all de-encapsulated and presented on various access ports on that switch.  This all works from end to end - just had this issue today when swapping the 3750 in for a 3550.

As requested, the use case here is to have this switch handle layer 3 stuff and have another switch that's only got layer 2 capabilities present these vlans untagged to various customers.

Code Select Expand

--- 3750 ---- trunk port ----  AP ---  wireless --- CPE --- trunk port ---- Netonix switch ---- customer per port

So vlan 101 ends up on a port of the netonix, vlan 102 on another port, etc.  The netonix has no layer 3 capabilities, so that's why I'm having the 3750 handle that...  Does that make sense?

Sure, not that unsual scenario. I've had loads of 3750s just doing routing with only trunks. STP might've been a culprit, if you're not using rapid-pvst/MST or some fallback then it could take a while for the port to be forwarding.

[access]

There's no need for an access interface to be up, a trunk works as well. The initial configuration should work, given that the VLAN exists.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swint.html#wp2040589

SVI Autostate Exclude
The line state of an SVI with multiple ports on a VLAN is in the up state when it meets these conditions:

•The VLAN exists and is active in the VLAN database on the switch.

•The VLAN interface exists and is not administratively down.

•At least one Layer 2 (access or trunk) port exists, has a link in the up state on this VLAN, and is in the spanning-tree forwarding state on the VLAN.

None are attributes of the paths, they're only different local router decisions (addpath might be "local" as it depends on the neighbor having addpath capability to be used, but nothing is added to additional path(s) being sent)

As to the original post; yes, addpath can send multiple paths for the same prefix to a neighbor that would otherwise be only one due to BGP path selection. The receiving neighbor still needs the correct maximum-paths settings to do ECMP since normal BGP path selection applies there as well.

Cool, got the 15$ bundle

[hints]

The host sends request for an IP address, Router (L3 switch, Helper address on SVI) forwards request to DHCP server for IP, The hosts wants back direction on how to IP itself (M flag  0 or 1 , either by SLAAC, or an assigned IP address via the DHCP server  as in this case) along with an ip, default gateway and other goodies.

Not quite. It's more like this, chronologically;
1, IPv6 enabled host sits on its subnet. Not knowing there are any routers on the subnet it sends out an RS (Router Solicitation).
2. A router on the subnet will respond with an RA (Router Advertisement. These also comes unsolicited at configured times). The RA will include the prefix(or prefixes) on the link, along with some additional flags; of special interest are the M and O flags. With both set to 0, or unset, the host will automatically generate its IPv6 via the function called SLAAC. DHCPv6 is not necessarily (see 4 below) used here.
Here you have a fully functioning IPv6 host.

But this can also happen:
3. If the M and O flags are 1/set, this will hint to the host that there are a DHCPv6 server available for address assignment (M-flag) or other option assignment (O). (SLAAC are still performed, the host will end up with multiple IPv6s)

Depending on your OS, this can also happen:
4, The hosts OS is manually configured with DHCPv6, and will send a DHCPv6 SOLICIT regardless of the O/M-flags in the RA. The flags are only hints, they do not really enable or disable any behavior.



All this is for client/workstation assignment. The DHCPv6 server itself needs nothing of this and can be configured with a static IPv6 IP and GW as a IPv4 host. So the whole RA with this and that flag to the server is not needed.

In IOS the flags are configured under the interface:

Code Select Expand

ipv6 nd managed-config-flag
ipv6 nd other-config-flag

Have found that although as you say the M and O flags are just hints, you can enforce a DHCPv6-only environment by stopping the router advertising a prefix in its RA. The command "ipv6 nd prefix X:X:X:X::X/<0-128> no-advertise" will stop any SLAAC clients being able to autoconfigure an address, so only clients supporting DHCPv6 will get connectivity.

Yep, what that also does is provide no on link prefix information to the clients, so they cannot find eachother via ND, all their communication will go through the router. Sometimes this is the intended design.

There's also the option to send the prefix on link info without the A flag, that should prevent clients from using the prefix for SLAAC autoconfig but still allowing on link info. But then there's also of course the possibility of clients not honoring this and doing autoconfig regardless, since the info is there.

Sent from my E6653 using Tapatalk

When logged in I actually have a CCIE:SP badge, never got a mail about that. But it has the wrong expiry date, and my CCIE:RS badge are missing.

Hm got a bunch today.. no CCIE badges though.