- Community Home
- >
- Networking
- >
- Switching and Routing
- >
- Comware Based
- >
- VSR bridge interface MAC Address
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2016 03:44 PM
05-11-2016 03:44 PM
VSR bridge interface MAC Address
Hi, I'm seeing something which seems unusual when using the VSR ritual router,
When I have an interface in route mode and create a sub-interface - I see normal behaviour in that the MAC address used for packets leaving the interface is the MAC address assigned from the VMWare vNIC,
Expected behaviour config:
interface GigabitEthernet2/0
port link-mode route
interface GigabitEthernet2/0.2082
ip address 10.24.0.4 255.255.255.254
vlan-type dot1q vid 2082
If I have the interface in bridge mode and than add a tagged vlan to the interface, the mac address used seems to be a global system level mac address rather than the interface mac address:
Strange behaviour config:
interface GigabitEthernet1/0
port link-mode bridge
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 2081
The MAC address used for packets leaving the 1/0 interface can be seen using this command (there may be other ways to find this address)
dis lacp system-id
Actor System ID: 0x8000, cc3e-5f81-fa15
If I add a second interface in bridge mode - it also uses the same MAC adderess.
I'm tring to use a bridge / vlan so that I can control the VLAN using Openflow/SDN, I can't find a way to control a sub interface using SDN.
Does anyone know if,
A - This is expected behaviour?
B - Is there any way to change this behaviour?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-12-2016 06:06 AM
05-12-2016 06:06 AM
Re: VSR bridge interface MAC Address
Hey Demain1
I can't say with authority that it's expected, but all VLANs you create on the VSR1000 will use the system-ID.
Sub-interfaces on network and firewall devices will inherit the burnt-in MAC or vNIC MAC on most, if not all vendors.
You can change this by specifying the MAC address within the VLAN interface mac-address xxxx-xxxx-xxxx and I've noticed you can also spoof the inherited MAC on the vNIC. You do need to do this in certain scenarios, such as ESXi vDS with Forged Transmits set to "Reject". VMware recommend Forged Transmits to be set to reject to prevent MAC Spoofing of Ethernet frames, however, it does break Dot1Q packets when not using sub-interfaces (not just a HPE thing...). Changing Forged Transmits to "Accept" for the specific VM is acceptible, but admins will often miss this configuration when the environment changes or the VM is migrated, whereas the VSR1000 configuration is clearly visible in the current configuration.
I have to admit that I haven't tested this thoroughly, but I hope this helps.
Cheers
David Grocke